[Python-Dev] Re: Feature bloat in Python (was some PEP thing!)
Sun, 23 Jul 2000 17:08:56 +1000
> > > 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
> 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
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
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
> > 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
> 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
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
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
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
> I can't even believe that something like
> 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
> 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:
> for k in a:
> if k%2:
> j.append( k*2 )
> k=map(None, array1, array2 )
Better. Replace map with a loop, and it goes back to worse.
> for name,val in k:
> 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