PEP 3107 and stronger typing (note: probably a newbie question)

Michael Hoffman cam.ac.uk at mh391.invalid
Sat Jun 23 13:52:16 CEST 2007


Eduardo "EdCrypt" O. Padoan wrote:
> On 6/22/07, John Nagle <nagle at animats.com> wrote:
>> Paul Boddie wrote:
>> > P.S. I agree with the sentiment that the annotations feature of Python
>> > 3000 seems like a lot of baggage. Aside from some benefits around
>> > writing C/C++/Java wrappers, it's the lowest common denominator type
>> > annotation dialect that dare not be known as such, resulting from a
>> > lack of consensus about what such a dialect should really do, haunted
>> > by a justified fear of restrictive side-effects imposed by a more
>> > ambitious dialect (eg. stuff you get in functional languages) on
>> > dynamically-typed code. I don't think the language should be modified
>> > in ways that only provide partial, speculative answers to certain
>> > problems when there's plenty of related activity going on elsewhere
>> > that's likely to provide more complete, proven answers to those
>> > problems.
>>
>>      I agree.  It's a wierd addition to the language.  It looks like
>> a compromise between the "no declarations" position and the "make
>> the language strongly typed" position.  But it's so ill-defined that
>> it's not helpful, and worse than either extreme.  The whole
>> approach is antithetical to the "only one way to do it" concept.
>> This could lead to misery when different libraries use
>> incompatible type annotation systems, which is not going to be fun.
>>
>>      Python made it this far without declarations, and programmers
>> seem to like that.  We need to get Python performance up, and
>> the ShedSkin/Psyco restrictions seem to be enough to allow that.
>> Type annotations don't seem to solve any problem that really needs
>> to be solved.
>>
>>      The main advantage of strongly typed systems is that more errors
>> are detected at compile time.  You pay for this in additional language
>> baggage.  PEP 3107 adds the excess baggage without providing the benefit
>> of compile time checks.
> 
> Remember that pure CPython has no different "compile time" and
> runtiime.

Yes, it does.
-- 
Michael Hoffman



More information about the Python-list mailing list