[Python-Dev] Please reject or postpone PEP 526

Nick Coghlan ncoghlan at gmail.com
Mon Sep 5 06:04:07 EDT 2016


On 5 September 2016 at 18:19, Koos Zevenhoven <k7hoven at gmail.com> wrote:
> On Mon, Sep 5, 2016 at 5:21 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> On 5 September 2016 at 04:40, Koos Zevenhoven <k7hoven at gmail.com> wrote:
>>> On Sun, Sep 4, 2016 at 9:13 PM, Ivan Levkivskyi <levkivskyi at gmail.com> wrote:
>>>> On 4 September 2016 at 19:59, Nick Coghlan <ncoghlan at gmail.com> wrote:
>>> [...]
>>>>>
>>>>> Similarly, it would be reasonable to say that these three snippets
>>>>> should all be equivalent from a typechecking perspective:
>>>>>
>>>>>     x = None # type: Optional[T]
>>>>>
>>>>>     x: Optional[T] = None
>>>>>
>>>>>     x: Optional[T]
>>>>>     x = None
>>>>
>>>>
>>>> Nice idea, explicit is better than implicit.
>>>
>>> How is it going to help that these are equivalent within one checker,
>>> if the meaning may differ across checkers?
>>
>> For typechecker developers, it provides absolute clarity that the
>> semantics of the new annotations should match the behaviour of
>> existing type comments when there's an initialiser present,
>
> I understood that, but what's the benefit? I hope there will be a type
> checker that breaks this "rule".

Such a typechecker means you're not writing Python anymore, you're
writing Java/C++/C# in a language that isn't designed to be used that
way.

Fortunately, none of the current typecheckers have made that mistake,
nor does anyone appear to be promoting this mindset outside this
particular discussion.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia


More information about the Python-Dev mailing list