> Is 0.9.4 ready and available yet ?
Good question. I could either release what I currently have as
"0.9.4" or stick to it a little longer. My main reason for not
releasing it is that I still (sigh) haven't found the time to update
all the documentation. However a new release since 0.9.2beta is long
overdue so maybe I'll release it *without* up-to-date documentation.
I will post an announcement with a summary of changes on the list when
it's ready. People who have a strong opinion about releasing or not
releasing should send mail to me privately so I can just tally the
> Re: '==' replacing '=' for comparison
> Yes. That was on my list of minor complaints. I don't think comparison
> and assignment should have the same symbol. If changing also makes
> the grammar/parser easier, then go ahead! '==' for equality is
> probably better that ':=' for assignment, as assignment is probably
> the more frequent operation.
I agree, reluctantly (because of all the lines of library and example
code I will have to change), that this change should be made; but it
won't be in 0.9.4 if I release that soon. Note that this still won't
give you assignments in expressions as side effects; I am against such
a feature even though it occasionally saves a line of code -- one of
Python's strong points is that it is usually very easy (and pretty!)
to read, and I feel that assignments in expressions would have a
strong negative effect on readability (and prettiness!).
> What is needed is to merge some of the points discussed here into the
> users guide - a prominent part of the intro should explain what is
> different about python - with a more in depth treatment in the Lang.
> Reference Manual.
The current "tutorial" tries to keep object-oriented features out of
sight for as long as possible, in order to explain other pertinent
features like the syntax and the high-level data types and operations
(list slicing etc.). Do people think this characteristic of the
tutorial should be changed in favor of a more agressive explanation of
OO features? (I have heard people say that the tutorial is a
"read-once" document -- perhaps a real user's guide is needed, at a
level between the tutorial and the reference?)
(Here starts Steve's next mail):
>Actually, while writing this note, I have been swapping between
>emacs & python to try examples, and I finally figured out how to
>do what I want ( But I will go ahead and send this, instead of
>just saying "Nevermind", for discussion sake. ):
You can do that in private e-mail, but perhaps you should edit your
messages to the list a little more carefully. BTW, have you read the
document misc/CLASSES which comes with the Python distribution? That
should have made several points you are slowly discovering here clear
from the start (if not, please point out where it fails to be clear).
>I *still* think it would be nice if there was a way to MAKE classes
>become initialized when created as part of their definition,
>rather that by explicitly calling an init() function. ( Is there
>a way that I'm missing ? ) But I can probably live with the above
Class initialization in Python does not have the greatest syntax.
This is one point where I was experimenting with language design.
Perhaps I could adopt the Modula-3 way (after all I stole enough from
M3 already): a built-in function new() with as its first argument a
class name and as further arguments the arguments to class's init
code. We also need a way for the user to specify the init code; a
function with a standard name ("init" comes to mind :-) seems fine to
Note that the statements executed in the class definition cannot be
used for this purpose -- these statements are executed *once*, when
the class is defined, and their main purpose is to execute the method
definitions (since a 'def' statement must have been executed in Python
before it takes effect).
Finally, on the issue of the disappearing Pythons:
is indeed tha latest official release and identical to those that once
were on wuarchive. I think I cannot blame the archive keepers for
deleting old files every once in a while.
--Guido van Rossum, CWI, Amsterdam <email@example.com>
"I could be arguing in my spare time."