Breakdown of approaches to PEP318

John Roth newsgroups at jhrothjr.com
Sun Mar 28 17:20:35 EST 2004


"Sean Ross" <sross at connectmail.carleton.ca> wrote in message
news:7vD9c.318$1A6.114130 at news20.bellglobal.com...
> Here's a breakdown of most of the syntax discussed re: PEP318 using an
> example from python-dev. There are probably several more (I've added
[10]).
> The example applies both function decoration and annotation.
>
>
>
> Personally, I find all of this very off-putting. I find none of these
> proposals clean, clear, and/or readable, except perhaps [11] (which
started
> the whole mess in the first place). I tend to agree with the following,
> somewhat out of context, remark:

What makes them unreadable is the attempt to put parameters
into the decorators. This shoves the entire enterprise out over
a number of lines. The mixture of all upper case with the rest
of the syntax lends touch of impenetrability to them.

As far as I can tell, Python has hit an architectural limit on
the design of the function/code block. Some things are simply not
extendable without making compromises, and I think that the design
of the 'def' statement, combined with the indentation rules, is one
of them.

John Roth


>
>
> """
> If only we could learn from others' mistakes:
>
> Finally, in designing Self, we have learned one lesson by making mistakes:
> examples can persuade the designer to include additional features which
> later turn out to produce incomprehensible behavior in unforeseen
> circumstances. This might be called the language designer's trap.
> Minimalism, simplicity and consistency are better guides. They benefit
every
> programmer, not just the ones who need advanced features. We suspect that
> many of today's object-oriented languages could profit by dropping
features.
>
> Programming as an Experience: The Inspiration for Self
> """
> Isaac Gouy, http://lambda.weblogs.com/discuss/msgReader$11653
>
>





More information about the Python-list mailing list