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

[Mark Hammond]

> > > 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?

> It was a joke.

 What exactly was the joke?  You sound quite serious to me!

> Obviously all of your concern does not stem from one
> character. On the other hand, I don't think that it is a coincidence
> that you jumped on the

Sorry, but I don't think you are in a position to make statements about my
thought processes.

> It's ugly so its an easy target.

You should notice that I have not made a single specific comment about this
proposal.  You have no clue as to my feelings on Barry's proposal.

> I don't see how a fundamental element of the proposed syntax can be a
> red-herring!

I thought your comments on this were a joke?

> So your opinion is that no new syntax should be added to Python unless
> it offers massive new functionality. But any syntax that offers massive
> new functionality (e.g. static type declarations, multimethods,
> meta-object-protocol) is going to be considered too severe of a change
> and/or un-Pythonic.

Where have I made comment on "too severe" or "too un-Pythonic"?

I do agree that changes to Python should offer significant benefits, as
another contributor to this thread has already stated.

> > If we ignore the obvious bigotry in your statement (Perl and
> > Sendmail "just suck" ??

> Are we now in a society where it is inappropriate to criticize
> technologies?

Are we now in a society where "just suck" is a learned and reasonable
critisism of a technology?  Or one where bigotry, in any form, is
acceptable?

> > Tell that to the orders of magnitude more people who use them
> > than Python!)
>
> I do and have.

*sigh*  Telling people their preferred tools "just suck" is unlikely to be
effective advocacy.

> Agreed. And do you see code with heavy map/filter/reduce usage as clear?

Nope.  Proposals to clean this up are clearly good.  I have avoided making
specific comments about specific proposals in these diatribes.  However,
the existing proposals to "solve" this, IMO, don't.

> How about code with long getattr functions, doing a dozen tricks at
> once?

I have never seen a getattr function doing many tricks.  Many attributes
for sure, but almost always using the same trick.

> My attribute access function proposal (to take one at random :) )
> could significantly clarify the code generated by makepy, which I often
> use as "template code" for COM programming.

I dont think this is a good example.  makepy generated code is not meant to
be readable.  The fact it often is (and that I often recommend it be read)
is a necessity caused by lack of reasonable documentation or alternative
tools.

I agree your proposal could make makepy generated code more readable; but
as the point of makepy generated code is functional, I would probably keep
it just as it is!  makepy is, IMO, a perfect example of where getattr would
still be preferred over your proposal.  This is not to say I dont see merit
in your proposal; I just don't think makepy is a good example.

> > 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.

> If we can't make meaningful statements about usability, Python is
> doomed.

Im confused.  You asserted that we are probably too familiar with Python to
make meaningful statements about how newbies will find these syntax
changes.  I simply agreed, but pointed out that you are also in no position
to make the counter claim.  Now you are asserting we can make such
statements?

> I can't even believe that something like
>
> a=[2:30]
>
> is comparable to the various complexities *already in the language*. If
> Python were half as big as it is today (e.g. no classes, no exception
> handling), we would be having a big debate about whether to add the
> missing features.

I respectfully disagree.  To me:

a = range(2,30)

is just as good, and much clearer.  To compare this syntactic sugar to the
language having no classes or exceptions is absurd.

> I don't know what you are talking about. Which of these proposals
> require you to be a little brighter?

Neil has already answered.  But I must concede - I am not bright enough for
many of these.

> a=[1:50]  # Range literals

I admit I _could_ guess at this.

> a+=[51:60] # Augmented assignment

IMO, a poor example.  a+=1 _is_ obvious.  a+=[51:60] is, IMO, clearly not.
a += range(51,60) is better.

> j=[for k in a: if k%2: k*2] # list comprehensions
Yep - I admit it - I'm not bright enough.

> k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration

Ditto - I have "winzip", and even zip.exe.  I fully understand that the
only zips I have encountered on the computer relate to compression.  So
presumably this is something related to list compression?

> d = dict( k ) # new builtin function

NFI about this?  Is this a copy operation?  What is the type of "k" in this
example?

> Which proposals require too much intelligence?

Fortunately, I'm not insecure about my intelligence.  [OTOH, I'm also not
delusional about it ;-]  I suggest most of them.

> And how do they really compare (for sight-reading) to
> the contemporary equivalents:

> a=range(1,50)
Worse.
> a=a+range(51,60)
Worse.
> j=[]
> for k in a:
> 	if k%2:
> 		j.append( k*2 )
Worse.
>
> array1=[1,2,3,4]
> array2=[5,6,7,8]
> k=[]
> k=map(None, array1, array2 )

Better.  Replace map with a loop, and it goes back to worse.

> d={}
> for name,val in k:
> 	d[name]=val

Worse.

> Is this latter code really clearer and easier to read -- even for a
> newbie -- than the former?

IMO, yes.  But as you earlier asserted, to which I agreed, but you then
recanted, I dont believe either of us can speak for newbies.

Anyway, I believe we have both made our points, and in the interests of
preventing this from becoming a real flame-fest, I will refrain from
further comments in this vein, and simply place my faith in the benevolent
dictator.

Thanking-God-Python-isnt-being-designed-by-this-committee-ly

Mark.