[Python-Dev] PEP 329: Treating Builtins as Constants in the Standard Library

Guido van Rossum guido at python.org
Mon Apr 19 11:36:53 EDT 2004


[Samuele]
> he's proposing an hack that would speed up CPython and slow down Jython
> (because it would result in a no-op but OTOH he would like to remove the code
> when some globals are bound to locals for speed reason. Of course that's 
> not nice too
> but replacing a hack with another is just sort of a win. Honestly there are 
> probably
> very convoluted ways to make this, in this form, a non no-op on Jython too, 
> not that I would like to
> implement them or that Raymond cared).
> 
> if he has an elegant proposal that works for all of Python that would be a 
> proposal, this
> seems just a hack.
> 
> [Not that I particularly like this kind of semi-overt mud slinging] Other 
> people do not completely share Raymond's design taste, so to say, in fact 
> they have politely responded to single proposals, OTOH although it was a 
> bit over-rudely formulated, I think it was the case to bring to the day-light
> that that is creating some real tension.

While Samuele's words were inappropriately rude, I'm glad this was
brought up (and even to some extent I'm glad about some of the words
that Raymond used).  Raymond *does* seem to have a "speed obsession",
and while I'm sure he has Python's best interests at heart, I'm not
sure that accepting everything he proposes will actually be good for
Python.

I am happy with tweaking of existing internals (like speeding up
append) and the addition of new interfaces built on iterators (I don't
quite share Armin's views of "iterators considered harmful") but I'm
worried that e.g. replacing heapq.py with C code is not useful (raise
your hand if you have used heapq.py -- now raise your hand if it was
too slow for your purpose -- I expect to see very few hands) and
introducing speed-up hacks that will invite many people with less
judgement to use them all the time and hence reduce the code quality
of Python code samples available to the world with useless
encrustations.

> PS: I'm starting to be really annoyed by the fact that Jython is
> often cited good PR but a 2nd class citizen for all the rest. I'm
> aware of the practical circumstances of why that's the case in some
> occassions, OTOH we are mostly all investing our free time on Python
> activities, it would be nice if we showed respect beyond just the
> forms and politeness. I'm back from the ACCU which was fun but
> tiring and also an occasion of some related heat taking. All I was
> looking forward is restarting to finish the new-style class work
> (started in December and January) in Jython,after the stop because
> of working on the negotations for the PyPy EU proposal together with
> the others PyPy people, which we hope will conclude positively for
> the people working on it and looking forward to restart making PyPy
> a real concrete contribution to Python future.

I hope you don't think *everybody* sees Jython as a 2nd class citizen.
I personally see it as very important.  Certainly the PSF is
considering funding it, whether via the general grants committee (just
formed) or via a special grant.

--Guido van Rossum (home page: http://www.python.org/~guido/)



More information about the Python-Dev mailing list