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

[Mark Hammond]

[Paul]
> I think that this class vague complaints are a little unfair.

That is why we have these lists - so people _can_ disagree.

> We've had
> a wide range of proposals from extra functions to minor new syntax to
> new magical methods to radically new control flow features.

Yep - and I still lump them _all_ in the same category.  I don't believe I
have seen a _single_ PEP I would support (except maybe the "batteries
included" one, as it doesn't change the language, just the distribution.)

Is that specific enough?

> It isn't helpful to lump them altogether and condemn them because Barry
> broke the cardinal rule of never using an at-symbol in a feature syntax.

Why do you believe I did?  Where on earth did you get the impression this
has anything to do with the "@" symbol?  You seem to be the only one
constantly raising this.  Even when Barry says it is a red-herring, you
wont let it die.

I apologize to Barry for picking on his mail; this was not a reflection on
the proposal as such, it was just the unfortunate straw that broke the
serpent's back.  I have changed the subject line to reflect this.

> List which proposed features you like and don't
> like and why! That's the only way your concerns could really be
> addressed.

Please re-read my original mail.  I said "cool-but-not-really-necessary"
features; other people have followed up and clearly understood that I was
talking about code-bloat, and not that the features themselves necessarily
suck.  Each feature, in isolation, could possibly be bashed into something
I support.  When these are all combined I start having serious
reservations.  An example of the sum of the parts being significantly
greater than the value added to the whole.

> I think it is also worthwhile to recognize "conventions" that could be
> made clearer with first-class syntax. List comprehensions replace the
> map/lambda convention (and would IMHO, allow map/filter, at-least, to be
> deprecated). Range literals replace the for i in range(...) convention
> and so forth.

Hrm - but in a later mail, you state:
> Common Lisp and Linux are victims of feature creep. Perl and Sendmail
> just suck.

If we ignore the obvious bigotry in your statement (Perl and Sendmail "just
suck" ??  Tell that to the orders of magnitude more people who use them
than Python!) you have just addressed my concerns fairly succinctly.  Maybe
if you had made them in the same email you could have seen the conundrum?

> Those of us who have already internalized the conventions are more
> likely to see new syntax as an intrusion rather than as a long-term
> clarification.

Agreed - hence this debate is useful.  However, I will state that the
reason I skipped Perl and went for Python all those years ago was that the
intent of Python code, even before I knew the language, was clear.  This is
a key feature of Python, and a selling point I always in my own advocacy
efforts.

Most of these proposals are watering that down, IMO.  But I happily admit
that neither you or I are able to make meaningful statements about that -
we are too close it.

> things in a straightforward way. I strongly feel that map/lambda and in
> fact most uses of map fall into this category. The concept is fine but
> the syntax sucks.

Agreed.  So when someone presents a solution that is obvious to the readers
of this list, we will be well on our way.  This hasn't happened yet.  If
you can't quickly and quietly win this friendly audience over, IMO the
proposal has failed.  If any proposal causes even a small thread on this
forum that boils down to "but its not clear to me what this should do",
then I would have thought it self-evident that the proposal sucks.
Convincing us that it _should_ be obvious if only we were all a little
brighter and more willing to accept change for changes sake doesn't help
anyone, least of all the person making these statements.  (Let me be clear
that this last statement is not directed personally at Paul!)

Standing-by-everything-I-said-ly,

Mark.