Mailman 3 April 2006 - Python-Dev

How to determine if char is signed or unsigned?
by Thomas Heller April 6, 2006

April 6, 2006

Is there are #define symbol which allows to determine if 'char' is signed or unsigned? __CHAR_UNSIGNED__, maybe? I guess the buildbot failures on the ppc debian box are caused by ctypes using signed chars always. Thanks, Thomas

2 1

PY_SSIZE_T_MIN?
by Ralf W. Grosse-Kunstleve April 6, 2006

April 6, 2006

Congratulations to the Python 2.5a1 release! I started adjusting Boost.Python to work with this new release and it is going very well. I noticed this #define in pyport.h: #define PY_SSIZE_T_MAX ((Py_ssize_t)(((size_t)-1)>>1)) However, I couldn't find a corresponding PY_SSIZE_T_MIN which would come in handy to adjust old code using INT_MIN (from limits.h). Are there arguments against defining PY_SSIZE_T_MIN? Or is this just an oversight? Objects/longobject.c uses: return -… [View More]

2 1

Suggestion: Please login to wiki when you make changes
by skip＠pobox.com April 5, 2006

April 5, 2006

I know it's a minor point, but for those of us who monitor changes to the wiki I think it would make our task a bit easier if people within the Python developer community were logged in when they made changes. That way, instead of seeing a mail subject like [PythonInfo Wiki] Update of "BuildBot" by 24.6.150.200 I would see a person or login I recognize, like [PythonInfo Wiki] Update of "BuildBot" by SkipMontanaro Seeing a recognized name, I could just delete the mail without … [View More]

1 0

TRUNK is UNFROZEN
by Anthony Baxter April 5, 2006

April 5, 2006

Python 2.5a1 is done. Please feel free to checkin to the trunk again. I should note here - the ubuntu dapper x86 buildbot is now running with a compiler of "icc -Wp64". This is Intel's C compiler, with warnings about potential 64 bit issues turned on. I tried with -Wall, but the icc compiler's -Wall mode is unbelievably picky and whiny, and the output was less than useful. www.python.org/dev/buildbot/all, and select one of the compile logs from the "ubuntu dapper x86 (icc)" column. Be … [View More]

1 1

RELEASED Python 2.5 (alpha 1)
by Anthony Baxter April 5, 2006

April 5, 2006

On behalf of the Python development team and the Python community, I'm happy to announce the first alpha release of Python 2.5. This is an *alpha* release of Python 2.5, and is the *first* alpha release. As such, it is not suitable for a production environment. It is being released to solicit feedback and hopefully discover bugs, as well as allowing you to determine how changes in 2.5 might impact you. If you find things broken or incorrect, please log a bug on Sourceforge. In particular, … [View More]

2 2

reference leaks, __del__, and annotations
by Jim Jewett April 5, 2006

April 5, 2006

The checkins list has been struggling with generator reference leaks; the latest conclusion was that some are unavoidable because of __del__ cycles. That sort of defeats the purpose of resource managers. (Yes, it can be worked around on a case-by-case basis.) As I see it, part of the problem is that (1) When there is a cycle, python refuses to guess. (2) There is no way for a __del__ method to hint at ordering constraints. (3) There is no lightweight version of __del__ to say "I don't … [View More]

13 33

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
by Tim Peters April 5, 2006

April 5, 2006

> Author: walter.doerwald > Date: Sat Apr 1 22:40:23 2006 > New Revision: 43545 > > Modified: > python/trunk/Doc/lib/libcalendar.tex > python/trunk/Lib/calendar.py > Log: > Make firstweekday a simple attribute instead > of hiding it behind a setter and a getter. Walter, what's the purpose of this patch? The first weekday is still an attribute, but instead of being settable and gettable via methods, looks like it's now settable and gettable via module-… [View More]

5 11

Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
by Anthony Baxter April 5, 2006

April 5, 2006

Just a reminder - the trunk is currently frozen for 2.5a1. Please don't check anything into it until the release is done. I'll send an update when this is good. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

2 1

The "Need for Speed" Sprint, Reykjavik, Iceland, May 21-28, 2006
by Steve Holden April 5, 2006

April 5, 2006

EWT LLC and CCP h.f., having specific commercial interests in doing so, have decided to sponsor a sprint on the Python programming language with specific short- and medium-term acceleration goals. The sprint is also intended to stimulate broad consideration of the future of Python, and specifically to try and identify the most promising routes to improved performance. Selected members of the Python developer community will receive direct invitations, and their attendance will be sponsored, … [View More]

1 0

Re: [Python-Dev] reference leaks, __del__, and annotations
by Phillip J. Eby April 5, 2006

April 5, 2006

At 08:14 AM 3/31/2006, Tim Peters wrote: >[Phillip J. Eby] > > ... > > As Tim suggested, it'd be better to have the code be generator-specific, at > > least for now. That had actually been my original plan, to make it > > generator-specific, but I was afraid of breaking encapsulation in the > > garbage collector by having it know about generators. > >It sucks in a way, but so would adding yet another new slot just for >(at present, and possibly forever)… [View More] making gc and generators play nicer >together. "Practicality beats purity" here. I'm trying to figure out how to implement this now, and running into a bit of a snag. It's easy enough for gcmodule.c to check if an object is a generator, but I'm not sure how safe the dynamic check actually is, since it depends on the generator's state. In principle, running other finalizers could cause the generator's state to change from a finalizer being required to not being required, or vice versa. Could this mess up the GC process? It seems to me that it's safe for a generator to say, "yes, I need finalization", because if it later turns out not to, it's just a waste. But if the generator says, "no, I don't need finalization", and then later turns out to need it, doesn't that leave an opportunity to screw things up if the GC does anything other than immediately clear the generator? As best I can tell, the only things that could cause arbitrary Python code to run, that could possibly result in generator state changes, are structure traversal and weakref callback handling. It's probably not sane for anybody to have structure traversal run arbitrary Python code, so I'm going to ignore that for the sake of my own sanity. :) Weakref callbacks are tougher, though; it seems possible that you could have one of those cause a generator to be advanced to a point where it now needs finalization. OTOH, if such a generator could be advanced by the callback, then wouldn't that mean the generator is reachable, and ergo, not garbage? That is, since only reachable weakref callbacks are run, they must by definition be unable to access any generator that declared itself finalizer-free. It does seem possible you could end up with a situation where an object with a finalizer is called after a generator it references is torn down, but that circumstance can occur in earlier versions of Python anyway, and in fact this behavior would be consistent. Okay, I *think* I've convinced myself that a dynamic state check is OK, but I'm hoping somebody with more GC experience can check my reasoning here for holes. [View Less]

4 5