Mailman 3 July 2001 - Python-Dev

[development doc updates]
by Fred L. Drake 10 Jul '01

10 Jul '01

The development version of the documentation has been updated: http://python.sourceforge.net/devel-docs/ Updated to reflect the recent checkins for the Python/C API manual, which cover a number of the object creation and initialization functions.

1 0

Re: [Python-checkins] CVS: python/dist/src/Include rangeobject.h,2.16,2.17
by Thomas Wouters 09 Jul '01

09 Jul '01

On Thu, Jul 05, 2001 at 06:24:46AM -0700, Guido van Rossum wrote: > Update of /cvsroot/python/python/dist/src/Include > In directory usw-pr-cvs1:/tmp/cvs-serv8011 > > Modified Files: > rangeobject.h > Log Message: > Rip out the fancy behaviors of xrange that nobody uses: repeat, slice, > contains, tolist(), and the start/stop/step attributes. This includes > removing the 4th ('repeat') argument to PyRange_New(). Eek... What do we have the fucking warning framework and deprecation warnings for, anyway ?! It may sound overly conservative, but I *really* don't like ripping things out just because you don't like them, without even as much as a release with a warning (and no, 2.1.1 can't have the warning; PEP 6 won't allow it.) You're basically telling people "You didn't use it the way I thought people would use it but never documented anywhere, so if you used them the way they are documented, you're screwed." Defense offers exhibit A: the standard library reference: http://www.python.org/doc/current/lib/typesseq-xrange.htm: "XRange objects behave like tuples, and offer a single method" (Not to mention http://www.python.org/doc/current/lib/typesseq.html which *strongly* suggests all the operations in the table apply to range-objects as well as to strings, unicode strings, lists, tuples and buffers.) The API change also means binary and source level breakages... Is it really that much trouble to, just for *one* release, keep the functionality and just generate a warning when the 4th argument is something other than '1' ? I can live (though not agree with, sorry ;P) the removal of xrange advanced features... just not from supported to *gone* in a single step. Wishing-I-hadn't-mentioned-xrange-in-the-other-thread-ly y'rs, ;) -- Thomas Wouters <thomas(a)xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

9 24

Re: [Python-checkins] CVS: python/dist/src/Include rangeobject.h,2.16,2.17
by Greg Ball 09 Jul '01

09 Jul '01

> but I don't see a problem with that. I also left out the 'contains' > implementation. > Still-not-understanding-*why*-<wink>-ly y'rs, In the fine tradition of xrange, that 'contains' implementation is slightly broken. It doesn't have proper object equality semantics. Python 2.1 (#1, Jul 4 2001, 14:48:37) [GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-81)] on linux2 Type "copyright", "credits" or "license" for more information. >>> r, xr = range(10), xrange(10) >>> 1.1 in r 0 >>> 1.1 in xr 1 >>> 1+0j in r 1 >>> 1+0j in xr Traceback (most recent call last): File "<stdin>", line 1, in ? TypeError: can't convert complex to int; use e.g. int(abs(z)) --Greg Ball

1 0

Re: [Python-Dev] Python and e-art
by Samuele Pedroni 09 Jul '01

09 Jul '01

[Tim Peters] > all's-fair-in-war-and-art-ly y'rs - tim and commerce] No I was not much positively impressed by biennale.py, e.g. as a Program is not a work of art. I think something more along the line of perl (my bad) poetry, would be better than a self-replicating juxtaposition of body soul and fornicate etc (as identifiers) <wink>. It's a poor representation of "sex" ...

1 0

Python and e-art
by Samuele Pedroni 09 Jul '01

09 Jul '01

Hi. For the curious I just discovered this (maybe someone knew that already). Isn't python incredible <wink>. A group of e-artists has presented an e-art "virus" biennale.py written in python: http://www.0100101110101101.org/home/biennale_py/ at the Biennale, the famous international contemporary art exposition and gathering in Venezia. It seems a t-shirt with the source code is available too. Samuele Pedroni.

2 1

Re: [Python-Dev] Re: [Python-checkins] CVS: python/dist/src/Include rangeobject.h,2.16,2.17
by Jack Jansen 07 Jul '01

07 Jul '01

Recently, Guido van Rossum <guido(a)digicool.com> said: > Sobering thought: It's possible, given all the other changes that I'm > thinking about, that it just won't be possible to make Python 2.2 > fully backwards compatible. Should we rename it to 3.0? Forget about > the changes? Label it as experimental and encourage ISPs to install > it as an "alternative" version, only available by using "python2.2"? In this respect you should also think of the people Embedding/extending Python. From the checkin messages I get the impression that all the new inheritance stuff could well break things there, and if you're going to break, say, pyapache or somesuch then a major version jump may well be called for... -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Re: Comment on PEP-0238
by Skip Montanaro 07 Jul '01

07 Jul '01

Guido> "Emile van Sebille" <emile(a)fenx.com> writes: >> If you're going to add keywords, why not add precision and allow >> those who want non-integer division to set it to the level of >> precision they require. That breaks no more code (presumably) than >> adding div or yield does. Guido> I'm not sure what you're asking about. If you're serious, please Guido> submit a PEP! This is the time to do it. Posting to the Guido> newsgroup is *not* sufficient to let an idea be heard by me -- Guido> you *have* to mail it to me directly or to python-dev. (While I Guido> like to read c.l.py sometimes, I cannot guarantee that I see Guido> every post.) Isn't this similar to Paul DuBois' floating point ideas? Skip

1 0

from future import yield
by Martin von Loewis 07 Jul '01

07 Jul '01

> Regarding the yield statement: I'd love to require a future statement, > but the current support for future statements doesn't support > modifying the parser based on the presence of future statements, and I > don't know how to resolve that, short of totally rewriting the parser > or scanning ahead looking for a future statement with some regular > expression. The "directive" patch manages to conditionally introduce a new keyword, namely directive. The trick is to introduce it into the grammar, but only recognize it as a keyword if a flag is set. That approach could be used for future imports also, although I'd much prefer to spell it directive transitional yield Regards, Martin

1 0

Re: Comment on PEP-0238
by Skip Montanaro 07 Jul '01

07 Jul '01

Guido> (Hm. For various reasons I'm very tempted to introduce 'yield' Guido> as a new keyword without warnings or future statements in Python Guido> 2.2, so maybe I should bite the bullet and add 'div' as well...) C//> If one is going to add keywords to a language, I suggest that a C//> list of possible future keywords -- even ones that aren't planned C//> on being supported any time soon -- be reserved at the same time. And that warnings be issued for their use for at least one version. -- Skip Montanaro (skip(a)pobox.com) (847)971-7098

1 0

"Becoming", rev. 2
by Andrew Kuchling 07 Jul '01

07 Jul '01

Another update: http://www.amk.ca/python/writing/python-dev.html Added a section on design principles, mostly so I can quote Tim's 19 theses, a conclusion and acks sections, and the previously posted descriptions of Stackless, Jython, and Python.NET. At this point I'm ready to go more public with it, and will send off notes to the usual places to announce it. Don't hesitate to send more comments, before or after any announcements go out. Now I have to go sleepy-dodos or I shall be all cross in the morning. --amk

1 0