[Python-Dev] Re: Feature bloat in Python (was some PEP thing!)

[Fredrik Lundh]

tim wrote:
> > obviously, things with fancy names and existing patches are on
> > the top of that list :-(
>
> And, in most cases, not only fancy names and patches, but also years of
> favorable preceding discussion.  In particular, none of the things you
> mentioned (list comprehensions, augumented assignments, range literals) is
> in any sense new, or has escaped being debated to death multiple times.

yeah, but what concerns me here is that we're talking about a
release within 4-6 weeks, but we don't even have all the PEPs
in place...

:::

I cannot really comment on the list comprehension syntax since
the PEP isn't there yet, but if I remember the syntax correctly,
maybe "list confusions" is a better name than "list comprehensions".
I surely don't understand them...

"execute a piece of code and do something magic with the result
of the last expression"?  The lambda syntax is bad enough (it should
really support an optional "return"), and I'd rather not see more of
that...  makes me think of nasty C bugs (and Perl, but that's another
story).

I'm somewhere between -1 and -0 on this one; I would very much
prefer if we left that one out for 2.1, and considered adding real
blocks instead.

:::

The augumented assignment proposal is okay. I've never seen this
as a real problem -- if I find myself writing:

    somethingverylong = somethingverylong + 1

there's probably a design flaw somewhere.

But they're easy to read and grok -- even if you haven't used
C or Java before, it's pretty clear from context what they're
doing.

I'm +0 on this one.

:::

The range literal syntax is questionable; the proposal claims that the
advantages are:

    "clarity of purpose" -- really?  I'd say it's far from clear that slices
    really are the same thing as integer lists.  They're also somewhat
    hard to read...

    "efficiency" -- sorry, but this a bogus argument. it's perfectly
    possible to do this optimization in the interpreter (a method
    caching interpreter could for example treat for/in/range as a
    method of the local namespace)

    "consistency" -- this is basically the first argument once again,
    claiming that it's "logical" that ranges and slices are the same
    thing.  I'm not so sure...

I'm -0 on this one.  Changing it to require a "subject" for the slicing
(e.g. int[0:10]) would make me +0.

:::

I'm also beginning to like Barry's ">> file" proposal.  It's like the
augumented assignment syntax -- it's easy to understand what it's
doing when you see it in context.

(it really should be "print #file", of course ;-)

:::

finally, based on the title along, I'm totally +1 on PEP-209.

</F>