Guido van Rossum <guido(a)python.org> writes:
> I'd like to make None a keyword. This prevents dumb users from
> assigning to it and screwing themselves, and can cause a slight
> speedup because using None avoids two dict lookups.
You are going to make this issue a warning in 2.3, right?
There are two ways of constructing a software design: one way is to
make it so simple that there are obviously no deficiencies and the
other way is to make it so complicated that there are no obvious
deficiencies. -- C. A. R. Hoare
>>> Guido van Rossum wrote
> > 2. Since this is marked new in 2.3: Is it planned to backport
> > this stuff into the 2.2.x series?
> > Requiring Python 2.3 for my stuff seems a but harsh currently...
> I don't plan to backport this to 2.2 unless there's an overwhelming
I'd suggest that this _isn't_ the sort of thing that should be going
into 2.2. Aside from the amount of work - I'm guessing it'd be a bit -
the notion of adding stuff like this to a maintenance/bugfix release
seems, to me, to be stretching the meaning of the term maintenance
Anthony Baxter <anthony(a)interlink.com.au>
It's never too late to have a happy childhood.
Hi. My name is Ian Kjos. I am a professional software developer by trade, but much of the challenge has gone out of it. Some time ago, I decided to learn the Python language. Now I believe I have something to contribute.
Barry(a)zope.com and I have had a short discussion, and it seems a good time to raise the following issue on python-dev:
I've been working on multithreading in python, and I have some proposals that I would like to talk over with some knowledgable people. I aim to donate some code to the standard library, but only if it meets the community standards and is consistent with the goals of Python.
Please read this:
It contains smoke-tested code, documentation, design notes, and some food for thought. I will not claim perfect style at the moment, but I volunteer to clean up those issues as needed.
For the impatient:
Easy Thread-Local storage support.
I'm also thinking about building a metaclass for monitors (in the data-processing sense of the word). An alternative might be a synchronized method builder a'la classmethod and staticmethod.
Lastly, before this goes standard I'll make it safe for "from X import *".
I wanted to get some feedback and direction from other developers before continuing too far. For reference, I have already checked python resources, and this effort seems orthogonal to other projects I could find.
/me ponders making the profiler work with threads...
The devel-docs tell me about METH_CLASS:
The method will be passed the type object as the first parameter
rather than an instance of the type. This is used to create class
methods, similar to what is created when using the classmethod()
built-in function. New in version 2.3.
1. This seems wrong. The first parameter the function receives
is NULL, the type object goes together with the remaining arguments
in the second parameter (which is a tuple).
Is the documentation wrong, or is the code wrong (I didn't find
any use of METH_CLASS in the CVS sources)?
[I must say that I'm not really sure how this relates to the
calling convention flags. Have tried METH_O and METH_VARARGS
2. Since this is marked new in 2.3: Is it planned to backport
this stuff into the 2.2.x series?
Requiring Python 2.3 for my stuff seems a but harsh currently...
3. While we're at it, although I could try to find out myself:
How would one create a classmethod in Python 2.2?
There's a bug report on SF that notes there is a difference between:
x = x
x = 1
x = x
The latter works because the class namespace uses LOAD_NAME and finds
a global binding for x. The fact that x is also a local is invisible
The former fails because x is none of locals, globals, or builtins,
although it is bound in an enclosing scope. LOAD_NAME knows nothing
about free variables, however, so it just blows up.
Do we want to do anything about this apparent inconsistency?
LOAD_NAME is obviously necessary to make stuff like exec work at all,
and after a recent bug fix, it evens works as documented for nested
scopes. But the docs for a class namespace (there aren't any, right?)
don't suggest there is anything special going on.
I imagine it would be possible to stop using LOAD_NAME for classes,
but I'm not sure if that's a good thing. It could presumably break
code that relies on LOAD_NAME's old fashioned search. It also seems
like a non trivial amount of work because we'd need a new LOAD/STORE
combo that only searched a locals dict. (Maybe that's not so hard.)
I think module namespaces also use LOAD_NAME, but it's not clear why.
Isn't a module's locals the same as its globals? If so, LOAD_GLOBAL
could be used for all names.
Any opinion on whether this is worth fixing? And is it a bug fix or a
I'm not sure my vote counts for much (I mainly just lurk here), but I prefer
The one thing that no-one's mentioned yet, but which will probably cause
trouble, is that itemize() could be spelled itemise(), depending on where
you're from. People can get used to this sort of thing (heck, I even type
"color" without stopping to wonder what I did wrong these days :-) but it's
an unnecessary annoyance.
So I'm +1 for enumerate.
I'm sorry - I can't think of a new name to suggest. Does this disqualify me
There's one nagging issue that I'd like to revisit. I think I still
like the name itemize() better than enumerate(), even though itemize()
reminds some people of items(). Somehow that doesn't strike me as a
strong argument: the words look pretty different to me. I like
itemize() better because (a) it's shorter, and (b) the LaTeX command
"\itemize" can produce numbered lists (it can also produce bulleted
lists). I'm ready to open this one for a vote. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)
I defined both in the interactive interpreter and typed (and then looked
at) each one ten times. "enumerate" was annoying to type and didn't looked
that great either. "itemize" seemed fine.
+1 on "itemize"
/me attempts to avoid HTML-mail.
+1 for numer() in the short run, but I don't know if I get a vote yet.
I don't know if it's too late yet, but what PEP 279 really seems to want is
iterator comprehensions. I have wanted those myself for a bit of a while. If
nobody minds, how about these classes:
Counter -> iterator over unbounded arithmetic sequence, with specified start
and optional arbitrary step.
IterComp -> convert a transform function, a list of iterators and an
optional selection function into a new lazy iterator, using
comprehension-type semantics. Expect frequent use of lambdas.
Wait! Isn't this just like programming with streams? Is there room in the
python model for an explicit stream type? (Yes, it's called a generator.
Perhaps we should just use those wisely.)
Guido van Rossum wrote:
> (Sigh. I was only asking for guidance on whether to choose enumerate
> or itemize for the name, not reopening the whole subject of this PEP.)
Let the language decide:
>>> choice(['enumerate', 'itemize'])