Mark Hammond wrote:
>
> [Paul]
> > I think that this class vague complaints are a little unfair.
>
> That is why we have these lists - so people _can_ disagree.
I didn't mean to say otherwise.
>
> > 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. 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 one recent proposal with a syntax that adds a
character to the Python repertoire. It's ugly so its an easy target. Or
to put it another way, it was *likely* to be the straw that broke the
camel's back because it could change the look of Python most radically.
> 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 don't see how a fundamental element of the proposed syntax can be a
red-herring! You might as well claim that the new matrix operators are a
red herring in the discussion of new matrix operators. If Barry has
proposed another syntax I haven't seen it.
> 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.
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.
> > 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" ??
Are we now in a society where it is inappropriate to criticize
technologies?
> Tell that to the orders of magnitude more people who use them
> than Python!)
I do and have.
> you have just addressed my concerns fairly succinctly. Maybe
> if you had made them in the same email you could have seen the conundrum?
Not at all. There are lots of cool technologies that have grown far
beyond their original incarnations:
* Unix/Linux
* Apache
* Zope
* EMACS
* Common Lisp
The important thing isn't the size of the system but the consistency and
quality of its design. I was not attracted to Python because it was
small but because it was self-consistent. The requirement that every new
feature be consistent with the others *makes* it small.
TCL is pretty small too, but I have no interest in using it. Scheme is
extremely small and I had to give up on it despite my initial
attraction.
> 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.
Agreed. And do you see code with heavy map/filter/reduce usage as clear?
How about code with long getattr functions, doing a dozen tricks at
once? 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.
You talk about clarity and minimalism as if they were the same thing. It
is *exactly my point* that sometimes you *trade* clarity for minimalism.
On the one end of the spectrum is Common Lisp and on the other is the
lambda calculus. I agree that we want to stay close to the middle.
> 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.
> 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.
There is no construct in the Python programming language that is
self-evident *in its entirety* including all corner cases.
There are a few which you can "feel around" based on knowledge from
other programming languages but even those have many Pythonic twists
that you can only learn by reading the documentation. Even the "for"
statement would have taken a long, complicated, intricate debate on
python-dev to work out the current semantics, including IndexError,
else:, and mutability. The try statement is even more complex.
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.
In other words, you have raised the bar on adding features to Python so
high that it can never be met. Nothing non-trivial is ever intuitively
obvious, including every edge condition and interaction. It just doesn't
happen.
> 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.
I don't know what you are talking about. Which of these proposals
require you to be a little brighter?
a=[1:50] # Range literals
a+=[51:60] # Augmented assignment
j=[for k in a: if k%2: k*2] # list comprehensions
k=zip( [1,2,3,4], [5,6,7,8] ) # parallel iteration
d = dict( k ) # new builtin function
Which proposals require too much intelligence? Which ones would you not
be able to "sight read" coming from Java or Perl? And how do they really
compare (for sight-reading) to the contemporary equivalents:
a=range(1,50)
a=a+range(51,60)
j=[]
for k in a:
if k%2:
j.append( k*2 )
array1=[1,2,3,4]
array2=[5,6,7,8]
k=[]
k=map(None, array1, array2 )
d={}
for name,val in k:
d[name]=val
Is this latter code really clearer and easier to read -- even for a
newbie -- than the former?
Okay, Pep 207, 208, 209 and 213 are likely to be more complex. That's
because they are cleaning up parts of the language that are already
relatively complex. They aren't adding significant new functionality nor
syntax.
--
Paul Prescod - Not encumbered by corporate consensus
New from Computer Associates: "Software that can 'think', sold by
marketers who choose not to."
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