[Python-ideas] Optional static typing -- the crossroads

[Petr Viktorin]

On Fri, Aug 15, 2014 at 7:36 PM, Guido van Rossum <guido at python.org> wrote:
> On Fri, Aug 15, 2014 at 10:19 AM, Petr Viktorin <encukou at gmail.com> wrote:
>>
>> On Fri, Aug 15, 2014 at 7:00 PM, Guido van Rossum <guido at python.org>
>> wrote:
>> > On Fri, Aug 15, 2014 at 9:48 AM, Petr Viktorin <encukou at gmail.com>
>> > wrote:
>> >>
>> >> On Fri, Aug 15, 2014 at 5:55 PM, Guido van Rossum <guido at python.org>
>> >> wrote:
>> >> ...
>> >> >> Also... Does None magically mean NoneType in type definitions?
>> >> >
>> >> > Yes.
>> >>
>> >> This would mean either that `(None | None) is None`, or that (x |
>> >> None) is not always "optional x".
>> >> And if type objects grow any other common functionality, None will
>> >> have to support that as well.
>> >
>> >
>> > Perhaps None itself should not implement any of this, and the __ror__
>> > method
>> > on ABCs should implement it. That way, None|Mapping and Mapping|None
>> > would
>> > both work, yet None|None would still be the TypeError it is today.
>>
>> ... and that (x|None) does not always mean "optional x".
>> Is this case special enough?
>
>
> I'm not following. The proposal seems to be to add __or__ and __ror__
> methods to type itself requiring the other argument to be also a type, or
> the special case None (which is a value, not a type).

My concern is that if someone does programmatic type declaration
manipulation/generation, there's now a special case to keep in mind.
Instead of

    def optional(t):
        return t | None

it's now:

    def optional(t):
        if t is None:
            return t
        else:
            return t | None

because unlike other type declarations, None doesn't have __or__, or
any other operation that types will gain in the future as this
proposal matures.

But maybe this is will never be a valid use case?