[Tutor] changes in Python 2.2

[Scot W. Stevenson]

Hello -=20

> But now having read A.M Kuchling's excellent "What's New in Python 2.2"=
,
> a few of the PEPs like 252, 253  that deal with new type of class and
> those dealing with the new iterators and generators --PEPs 234 and 255,
> Python is looking to me more and more like --well--,  another language.

I would like to second this (again). This is going to be somewhat of a=20
rant, but I remember complaining a few months ago about Python's rate of=20
change, and tho I have made lots of progress with the language since then=
=20
(with a lot of help from this list), switching to 2.2 does make me feel=20
like the road I was following has dwindled from a four-lane highway (or=20
rather /Autobahn/ in my case) to a packed-earth path thru the forest. I a=
m=20
not sure if the real computer people here realize how disorientating thes=
e=20
changes are for people who are struggling with the basic concepts.=20

Part of this is that Python has almost completely left behind the printed=
,=20
book-form documentation: Lutz' "Programming Python" is a fantastic book,=20
but it is becoming more and more useless, and frankly I couldn't recommen=
d=20
the "Python Standard Library" by Lundh to anybody anymore. I had emailed=20
O'Reilly about a new version of "Programming Python" and their response=20
was "not in the next few months", without the "but we're working on it" I=
=20
had hoped for. I can't blame them - at this rate of change, why would=20
anybody want to write a book that will be outdated before it is even set,=
=20
let alone printed?=20

Obviously this was a problem even with "Programming Python", as GvR says=20
himself in the foreward:

    Every time I add a feature to Python, another patch of Mark's hair
    turns grey -- there goes another chapter out of date!

It doesn't look like this trend is going to stop anytime soon, either. In=
=20
PEP 279 (http://www.python.org/peps/pep-0279.html) we find these ominous=20
words from GvR:=20

    "[F]ilter and map should die and be subsumed into list comprehensions=
,
     not grow more variants."

Which is a really motivating thing to read if you have just understood=20
filters by working thru examples. List comprehensions are, as we have=20
discussed here before, very intuitive if you have a background in set=20
theory (so I'm told), but for the rest of us, they are not exactly easy o=
n=20
the eyes, and I still think the syntax looks very un-Pythonic. They are=20
not exactly the simplicity that Python has been famous for, and certainly=
=20
not "executable pseudocode".

Kuchling does address some of these complaints:=20
   =20
    Some users have voiced concern about all these changes. Sure, they sa=
y,
    the new features are neat and lend themselves to all sorts of tricks
    that weren't possible in previous versions of Python, but they also
    make the language more complicated. Some people have said that they'v=
e
    always recommended Python for its simplicity, and feel that its
    simplicity is being lost.=20

Which are my feelings exactly. He answers:

    Many of the new features are quite esoteric, and you can write a lot =
of
    Python code without ever needed to be aware of them. Writing a simple
    class is no more difficult than it ever was, so you don't need to
    bother learning or teaching them unless they're actually needed.=20

I don't agree with this for a couple of reasons.=20

First, division is about as basic as you can get, and at this rate of=20
change, we're going to hit Python 3.0 before anybody gets around to=20
writing those new books. Take a look at how many division examples that i=
s=20
going to break - starting on page 33 of "Learning Python", which is about=
=20
as close to the start of learning the language as you can get. This is=20
going to really get the next generation of newbies.

Second, I might not have to /write/ the new forms, but I have to understa=
nd=20
them to be able to /read/ Python code. Which means that if I want to=20
continue, say, to use the module code as a learning example, I'm going to=
=20
have to figure out how "yield" works, or (soon enough) what "enumerate"=20
does, since PEP 279 tells me: "The response to the enumerate() proposal=20
has been close to 100% favorable. Almost everyone loves the idea." That=20
sounds like a lot of important people are going to be using it all over=20
the place.

Third, I was under the impression that one of the ideas behind Python was=
=20
to create an easy to learn, easy to use, easy to maintain programming=20
language that avoids "esoteric" features in the first place. So what is=20
Kuchling telling me here about the Python philosophy? Or, to rephrase=20
that: If these features are "esoteric", why were they included at all?

Fourth, when you add new keywords (like "yield"), it isn't esoteric=20
anymore. GvR tells us the following about "enumerate" (note this is not i=
n=20
2.2 that Kuchling is talking about):=20

    Like zip(), it is expected to become a commonly used looping idiom.

In other words, after Python 2.3, he expects lots of code to use enumerat=
e.=20
These are core changes and affect the way the language is used at a basic=
=20
level. And PEP 283 tells me that Python 2.3 is due to be out before the=20
end of the year...and I bet 2.4 is planned for Summer 2003...and 2.5 for=20
the end of 2003...

Again, I am not opposed to the changes as such. Having "real" division=20
instead of C-like computer science division is a great idea and in my min=
d=20
will be a great plus for Python. Enumerate, if I understood the PEP=20
correctly, is a cool idea, and "yield" seems to be nice, too. And yes,=20
universal newline support should have be included in from the start, and =
I=20
agree that major changes should be made sooner rather than later. There i=
s=20
no question that these changes make Python a better language.=20

The problem is that the rate of change has far outstripped the ability (o=
r=20
interest) of the people writing documentation to keep up, especially=20
documentation in book form. This is obviously not a problem for people wh=
o=20
have lots of time to play around with the new features and/or have such a=
=20
firm computer science background that they can just say "oh yeah, this is=
=20
just like Icon" and carry on. For the rest of us, learning Python 2.2=20
means piecing together bits from outdated books (like "Programming=20
Python"), short online texts (like "What's new in Python 2.2.?", which, a=
s=20
Thomas pointed out, is not aimed at newbies), and comments from more=20
advanced users (like the Python Tutor list here).=20

This is not fun, and learning Python used to be, first of all, fun.

Also, there is no end in sight. Things would be different if we all knew=20
that there was going to be a lot of hectic change for a while before=20
"Python 3000" comes out with a "keyword freeze" or whatever you call it.=20
But reading thru the PEP proposals, you get the feeling that Python has a=
=20
sort of computer scientist feeding frenzy on its hands, were everybody ha=
s=20
a pet cool idea for a computer language and sees a chance of getting it i=
n=20
Python - with good reason.=20

(Say - wouldn't it be easier for all involved just to freeze Python at, f=
or=20
example, 3.0, and then have all of these people with these great new idea=
s=20
sit down and design a new language from scratch, one that has all their=20
cool features, is stackless, doesn't have a global interpreter lock, is=20
great for numeric computation, etc. pp.? And leave the rest of us with a=20
stable language that doesn't take a step forwards every time you try to=20
throw your saddle on its back.)

As much as I have gotten to love Python, I am beginning to ask myself why=
 I=20
don't just quit the language for a while until the mutation rate has=20
dropped to an acceptable level. Say, for about two or three years, then=20
buy a book and start all over again. For all their disadvantages, Java an=
d=20
C don't see major changes every few months and the paper documentation=20
doesn't depreciate the way Python's does...like, I could actually sit dow=
n=20
with the Second Edition of Kernighan and Richie, 1988, and get to the=20
point where I can at least read the C of the Linux Kernel.=20

Y, Scot
Who does feel a lot better now, thank you...

--=20
  Scot W. Stevenson -- scot@possum.in-berlin.de -- Zepernick, Germany