Mailman 3 June 2004 - Python-Dev

Re: [Python-Dev] Comparing heterogeneous types
by Jeff Epler 03 Jun '04

03 Jun '04

On Wed, Jun 02, 2004 at 08:36:47PM -0400, Tim Peters wrote: > [Jeff Epler] > > Oh -- there are some floats f for which > > float(long(f)) > > raises an OverflowError in float()? > > No, at least not unless the machine has very strange arithmetic. For an > IEEE box, [...] Thanks. I re-read the message I was replying to, and now I see the problem with the code I proposed. I just didn't get it the first time. Jeff

1 0

Re: Re: Stackless Python
by Gordon McMillan 03 Jun '04

03 Jun '04

Terry Reedy wrote: [trying Stackless] > Among other things, I looked to see if there were currently a free trial > period for Eve, as there sometines is for online games. If I were to try > it, and it ran smoothly for some time without lags and crashes (which I > have experience of), then that would suggest that the tools (including > Stackless) and use thereof were adequate to the task. If not, that > something (though not necessarily Stackless) would be shown lacking. Let me pop my head up for a second. You won't see Stackless do anything (from a user's perspective) that can't be done without Stackless[1]. Stackless (like generators) just makes some things much easier. Basically, any state machine(s) with complex internal state (and relatively simple events) will be much more straightforward to write in Stackless. Put another way (if you don't think in terms of "state machines"), if you've got callbacks onSomething(...) where a lot of the code is concerned with where you are in a complex interchange, it will be much easier in Stackless. I can't speak to the new Stackless, but in 2000 I did a proprietary, commercial app for Avid that used Stackless (and lots of C extensions). It went through Avid's QA, so it would not have been released if it crashed. The Mac OS8/9 port was difficult, but not because of Stackless. -- Gordon [1] Though perhaps you can do more / quicker, because of more efficient memory usage than an implementation using threads.

2 1

RE: [Python-Dev] Python bug day?
by Batista, Facundo 02 Jun '04

02 Jun '04

[A.M. Kuchling] #- I'd like to get an announcement written and posted today. No one has #- objected to Saturday, so that's the date I'll use. This Saturday? I liked to don't put this on #python. #python-bugday seems a good name. . Facundo

1 0

RE: [Python-Dev] Dropping decorator syntax for 2.4?
by Chermside, Michael 02 Jun '04

02 Jun '04

Guido writes: > I still hate > the most popular proposal (def foo(args) [decorators]: body) and my > own proposal is unpopular. Just one voice here, but I was initially opposed to your proposal, and favored the above-mentioned popular proposal. But as I played around with your proposed syntax, it grew on me, and I'm now a supporter your approach. > I just want to suggest that we put > this off and get 2.4 on the road without any decorator syntax at all. > What do people think of that? It's fine with me if we put it off. Obviously others have already posted saying that they'd rather have the feature (at least FUNCTION decorators... other decorators seem to be less in demand), regardless of the syntax. As for me, I'd rather prefer to get the syntax "right" even if it means delaying another release... but that's because I don't have a project that is in desperate need of decorators. I like the *idea* of releasing one syntax and reserving the right to change syntax later (via warnings or something). But I don't believe it is possible in the real world. -- Michael Chermside This email may contain confidential or privileged information. If you believe you have received the message in error, please notify the sender and delete the message without copying or disclosing it.

1 0

Removing pcre module
by A.M. Kuchling 02 Jun '04

02 Jun '04

I've removed the pcre module, unused since Python 1.6, from CVS HEAD. Should I try to edit the various build files in PC/ and PCbuild/ to remove it, or should that be left to the Windows-based developers (Tim, Thomas Heller, Martin)? --amk

4 3

Re: [Python-checkins] python/dist/src/Include unicodeobject.h, 2.42, 2.43
by Skip Montanaro 02 Jun '04

02 Jun '04

perky> - SF #962502: Add two more methods for unicode type; width() and perky> iswide() for east asian width manipulation. Should strings grow these methods as well for symmetry? Skip

3 4

functions decorators in 2.4?
by Thomas Heller 02 Jun '04

02 Jun '04

PEP 318 is marked as Python 2.4. Will functions decorators make it in 2.4a1? Is there anything I can do to make it happen? Thomas

1 0

Python bug day?
by A.M. Kuchling 02 Jun '04

02 Jun '04

For the impending 2.4alpha1 release, a coordinated effort to reduce the bug backlog would be good. Several other projects (Zope, GNOME, Mozilla) have "bug days" in which people meet on IRC and go through the bug database, closing irrelevant or incorrect reports, writing small test cases for vague reports, etc. Holding a Python bug day seems worth a try. I've written up a Wiki page, http://www.python.org/cgi-bin/moinmoin/PythonBugDay, to begin planning a bug day and to figure out what tools (if any) are required. Please comment, particularly if you've participated in bug days for Zope or other projects. Do we need transcripts of the IRC channel? Should we use #python or a new channel? If the details can get sorted out in time, perhaps we can have a bug day as soon as this weekend. Is a weekend day better than a weekday for people who are interested in participating? --amk

9 14

pre-announce: Python 2.4a1 is about a month away
by Anthony Baxter 02 Jun '04

02 Jun '04

This is a pre-announcement that the first alpha of Python 2.4 is about a month away. The purpose of this notice is to give people a heads up - if you have a bug that you want to see fixed for 2.4, start looking at it now. Fixes are welcome through the release cycle, although after the first beta fixes that result in a change to behaviour will be much less likely to be accepted. So, if you have a bug you want to see fixed, what should you do? - If it's not logged on SF, log it. - If it's logged, consider adding a patch that fixes the problem, or at least a simple test case that demonstrates the bug. - If someone else has supplied a fix, see if this fix works for you, and post your results to the bug. - If there's a working fix, feel free to add a note asking for the fix to go into CVS. The SF bug tracker for Python has a _lot_ of bugs in it, and it's easy for bugs to be overlooked. If you're just interested in what's coming up in 2.4, see the current development version of the "What's New in 2.4" document at http://www.python.org/dev/doc/devel/whatsnew/whatsnew24.html On behalf of the python-dev team, thanks! Anthony [This form of pre-announcement will hopefully become a part of the release process for all future releases of Python, both major and bugfix releases, to give people a chance to get their bugfix-of-choice submitted in time. Any feedback on this process, please feel free to email me] -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

RE: Comparing heterogeneous types
by Robert Brewer 02 Jun '04

02 Jun '04

Aahz wrote: > On Mon, May 31, 2004, Robert Brewer wrote: > > > > Quite similar to my current "pet peeve": > > > > >>> None > 3 > > False > > >>> None > 'hoopy' > > False > > >>> None > True > > False > > >>> None > datetime.date(2004, 5, 31) > > Traceback (most recent call last): > > File "<interactive input>", line 1, in ? > > TypeError: can't compare datetime.date to NoneType > > > > ...writing an O-R mapper, this particular hobgoblin bites > me rather often ;) > > Time for you to bite the bullet. Guido has all-but-decreed that the > future of comparisons is that TypeError will be raised for > all operators > other than == and <> for types that have no appropriate relationship > system. ...which is fine. I'll end up either disallowing None as a legal value, or making a NO_VALUE singleton for which I can customize comparisons. Either is a better design choice IMO; I just haven't been forced into the choice yet. ;) Robert Brewer MIS Amor Ministries fumanchu(a)amor.org

1 0