PEP scepticism

[Tim Peters]

[Bernhard Reiter]
>>> This might reduce the main advantage of Python to be clear and easy
>>> and mostly have one good formulation on how to express what you want
>>> to program in a structured way.

[Tim]
>> While I expect everyone would agree those are advantages of
>> Python, I doubt there's consensus that those 4 advantages are "the
>> main" <wink> advantage.  Language design is more complex than that.

[Bernhard Reiter]
> Rethinking this I still think this are _the main_ advantages
> compared to other languages.

You're allowed to use Python for any reason that suits you <wink>.

> What do you think the main advantages are? :)

Python minimizes my unproductive programming time, and that's an *empirical*
observation over years of using Python along with many other languages.  I'm
really not sure how it accomplishes it, but that's its main advantage to me
(and, BTW, that's the core problem with Second System Syndrome too:  I'm not
sure Guido understands exactly how Python does it either).

Part of it is expressivity coupled with lack of tricks; as a
counter-example, APL is highly expressive provided you buy into the core
trick that "everything's an array".  Python lets (more, encourages) me to
treat different things differently, yet is still highly expressive across
many different kinds of things.

Now when we get to:

>>> Examples are:
>>> 	- augmented Assigments
>>> 	- Lists comprehensions
>>> 	- Simple Generators

my reaction to all is the same:  they increase expressivity, each
significantly reducing the gap between how I think of a problem and what I
have to type to get the machine to think the same way I do.  They *increase*
"clear and easy" for me, so in that sense I'm a "clear and easy" fan too --
but people won't agree on what "clear and easy" mean.  I've even been told
that some people find Perl clear and easy <wink>.

> ...
> However not having augmented assignment made me think about it and
> the clarity you gain when writing it more explicitly.

We won't agree on that, so good thing for me that I think more like Guido
here <wink>.  I *think* "add y to x", or "bump x by y", not "add x and y and
then replace x with the sum so obtained", so

    x += y

is much clearer to me than

    x = x + y

and I really mean "much".  Faced with the latter, I always have to *deduce*
"ah, OK, it's adding y to x", and that's a drag on my time.  I hated that in
Fortran and Pascal, and in Python too before augmented assignment was added.
In Lisp it was easy to write macros, but then too easy to write so many
macros that you can't make head or tail of the mess a few months later.
Etc.  Whenever Python changes to let me say what I intend more directly, I
like it.

I confess I don't care at all whether something is obvious at first glance.
The ABC language tried that as far as humanly possible, and while it may
have been great for teaching, it was a PITA for getting real work done.
Part of Guido's genius was in extracting the pieces of ABC "that worked" on
all levels (for both newbies and experts), tossing the parts that didn't,
and incorporting new gimmicks akin to the parts of ABC that worked best.

The acid test for me isn't whether a newcomer understands a gimmick at first
sight, but whether (a) they can be taught it, and (b) whether, once learned,
it's hard to *forget*.  Picturing array indices as pointing *between*
elements is the canonical example of that:  it makes no sense at all to many
newcomers, yet once learned it's compelling and endlessly fruitful.  I'm all
in favor of Python adding thousands <wink> of new gimmicks like that, but--
alas --the supply of comparably jewel-like ideas appears severely limited.

>> Not even Scheme stayed *braindead* austere forever, you know <wink>.

> That's why fresh, small languages are designed sometimes... <wink>

And always will be. "Everything is an X" appeals to young language designers
(you can't get "small" without that), and whether X is macros, strings,
arrays, lists, classes, lambdas or combinators doesn't really matter:  they
get a spare but trick-laden language in the end, and expressivity sucks
unless you share the delusion that everything's an X.  Python's only nod in
this direction was "everything's an object", but the semantics shared by all
objects is so tiny (you can apply id() and repr() and str() and type() to
anything) it doesn't get in the way.  Part of the danger in PEPs 252-254 is
in trying to expand this commonality.

> ...
> Maybe my subject of the original was suboptimal, but there is
> some connection and I had to start expression what my concern is
> somewhere.

Here's something else to consider:  as with the examples above, almost all
changes to Python have been debated for years, and the backlog of old ideas
with a strong constituency decreased rapidly over the last year (as old
ideas finally got implemented or rejected).  Changes that pop up out of thin
air (i.e., without a long history) are much rarer, and rarely significant in
the overall scheme of things.  The strongest counter-example I can think of
is the addition of Unicode strings, which popped out of nowhere (wrt the
original language design and the initial year of "feature requests"), but
were added in such a way that most American users still have no idea Python
has them <0.7 wink>.

So I expect the pace of language (but not library) change to slow, simply
because we're running out of strong backed-up ideas for the core.

but-then-most-debates-are-about-yesterday's-problems<wink>-ly y'rs  - tim