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

[Sunjay Varma]

Hi all,
Has the syntax for specifying type been fully decided on already?

Using brackets may confuse new Python programmers. Since specifying type in
Python is fairly new anyway, what do you all think of introducing angle
brackets into Python instead? Other languages use angle brackets to specify
types. It provides a good separation between type specification and list
indexing.

I'm also worried that using square brackets will cause confusion as that
notation is generally associated with array declarations in other
languages. Even in Python, MyClass[int] may be confused with getting a key
called int from some MyClass.

dict<str, int> seems to tell me more explicitly that I'm dealing with a
declaration of an expected type. dict[str, int] looks very much like I'm
getting an item (str, int) from some class.

The angle bracket (or any other suggestions you have in mind) provides a
more concrete separation between when we are performing item indexing and
when we're specifying a type to validate.

Sunjay
On Aug 15, 2014 1:55 PM, "Guido van Rossum" <guido at python.org> wrote:

> Doesn't seem a big deal. The only place where you'd see an implementation
> of optional() would be in typing.py, and optional(None) is redundant anyway.
>
>
> On Fri, Aug 15, 2014 at 10:51 AM, Petr Viktorin <encukou at gmail.com> wrote:
>
>> 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?
>>
>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140815/a0d065c0/attachment.html>