> > > 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4