Typing: Crazy idea: rename Optional to Option?

[gvanrossum]

I just learned that Scala has an Option[A] type that serves the same purpose as our Optional[A]. I wonder if some of the objections against Optional as a name (mostly that people mistake it to refer to an optional argument or an optional key in a dict) wouldn't be weakened by this small linguistic trick: an optional thing can refer to the other meaning of optional, while an Option refers to a value that can be either None or A.

[ilevkivskyi]

I like this option, but the only question is isn't it too late now? Despite the fact that PEP 484 is still provisional, we will probably need to keep Optional as an alias for Option and have a deprecation period.

[ilevkivskyi]

Also I have a (very generic) off-topic question about the link you posted: do we need pattern matching in Python?

[gvanrossum]

We should probably take that offline. I t might be a nice addition in a few
years, once static types are common.

On Jul 21, 2017 4:43 PM, "Ivan Levkivskyi" [e-mail] wrote:

Also I have a (very generic) off-topic question about the link you posted:
do we need pattern matching in Python?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/python/typing/issues/452#issuecomment-317136107, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ACwrMu9y2RPacDuqvA98XrzvOY1DYLU3ks5sQTekgaJpZM4Of_QD
.

[ethanhs]

From a linguistic standpoint, optional is an adjective and thus describes the variable. Option is a noun, and thus does not have the same flow. Reading "Option int" is not as intuitive (at least to me) as "Optional int" when reading code. Furthermore "Option" according to wiktionary is "One of a set of choices that can be made", which doesn't exactly convey the idea of Option[a] meaning it is either a or None, more that a is a possibility, and other possible values exist (which can be confusing. What are the other options?). Optional on the otherhand means "Not compulsory", which to me makes more more sense as meaning the value can be None.

[refi64]

FWIW I strongly agree with @ethanhs on this. IMO Option[Type] reads really oddly just to save two characters.

Also, C++17 uses std::optional.

[gvanrossum]

I'm not trying to save two characters but address complaints we've had about Optional being ambiguous. (There are other proposals to save more than two characters, primarily ?int or int?, but I'm not so keen.) But I agree it doesn't read super nice and it's probably too late.

OT: When following another language's patterns, Scala's type declaration syntax is a lot closer to PEP 484 than C++. E.g. in Scala you write

val greeting: Option[String] = None

which looks quite similar to Python's

greeting: Optional[str] = None

[OOPMan]

As a Scala user I would love it if Optional became Option :-)

One of the reasons I enjoy Scala is because there is a pretty nice resemblance between typed Python 3 code and Scala :-)

[OOPMan]

@ilevkivskyi With regards to Scala-tyle Pattern-matching in Python, it's something you could actually implement using meta-programming I suspect.

In Scala, pattern matching works primarily on Case Classes which capture their constructor parameters for later inspection. This would probably be simple enough to do in Python, the tricky part would be language-level syntax to handle the matching side of things.

Pattern-matching is definitely one of my favourite features in Scala although it's worth noting that a lot of the utility of it also comes down to the various short-hand forms Scala allows (E.g. a pattern-match function literal which tends to be useful for recursive functions)

[ilevkivskyi]

In Scala, pattern matching works primarily on Case Classes

There is a PEP being discussed for dataclasses in Python 3.7 https://github.com/ericvsmith/dataclasses, the idea is that they could be well accompanied by pattern matching (i.e. with dedicated syntax).

[OOPMan]

@ilevkivskyi That is pretty sweet, will take a look now :-)

[bagrat]

I always liked the Nullable term, which is straight-forward, and whenever I learnt about typing.Optional the first thing I thought was:

why not Nullable?

But given we have None in Python, maybe Nonable vs Optional will play better and be clearer?

[OOPMan]

@bagrat You used the word Null! 50 demerits! ;-)

[mjr129]

Since Optional is so very common, C# does have the rather more succinct int? = Nullable<int> (this would require a big change for something that doesn't really go beyond the IDE at the moment though!).

[smarie]

I also feel that Nonable would be less ambiguous. #275 also suggests the alternate Noneable. As a non-native english speaker my opinion should not count here, but I still prefer Nonable, the missing 'e' character does not seem to impair the meaning

[srittau]

I'd also suggest to change Optional to Nullable or Nonable. In many bug reports and pull requests of typing I have seen confusion about this, and from time to time I stumble across this, even though I know better by now.

This could follow the normal deprecation process, as Optional is broadly used by now. But better start changing it now than even later.

[gvanrossum]

It's too late.