Mailman 3 April 2006 - Python-Dev

How to determine if char is signed or unsigned?
by Thomas Heller 05 Apr '06

05 Apr '06

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 05 Apr '06

05 Apr '06

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 -PY_SSIZE_T_MAX-1; To maximize consistency this would seem ideal to me: pyport.h: #define PY_SSIZE_T_MIN (-PY_SSIZE_T_MAX-1) longobject.c: return PY_SSIZE_T_MIN; Cheers, Ralf __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com

2 1

Suggestion: Please login to wiki when you make changes
by skip＠pobox.com 05 Apr '06

05 Apr '06

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 considering if it was wiki spam. It's a small point, but when you get hundreds of emails a day, speed is everything... Thx, Skip

1 0

TRUNK is UNFROZEN
by Anthony Baxter 05 Apr '06

05 Apr '06

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 aware that this is an old 500MHz box I had lying around that's found a new use as a buildslave, so it's not the fastest box in the world... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 1

RELEASED Python 2.5 (alpha 1)
by Anthony Baxter 05 Apr '06

05 Apr '06

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, note that changes to improve Python's support of 64 bit systems might require authors of C extensions to change their code. More information (as well as source distributions and Windows installers) are available from the 2.5 website: http://www.python.org/2.5/ The plan from here is for a number of additional alpha releases, followed by one or more beta releases and moving to a 2.5 final release around August. PEP 356 includes the schedule and will be updated as the schedule evolves. The new features in Python 2.5 are described in Andrew Kuchling's What's New In Python 2.5. It's available from the 2.5 web page. Amongst the language features added include conditional expressions, the with statement, the merge of try/except and try/finally into try/except/finally, enhancements to generators to produce a coroutine kind of functionality, and a brand new AST-based compiler implementation. New major modules added include hashlib, ElementTree, sqlite3 and ctypes. In addition, a new profiling module cProfile was added. A large number of bugs, regressions and reference leaks have been fixed since Python 2.4. See the release notes for more. Enjoy this new (alpha!) release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

2 2

reference leaks, __del__, and annotations
by Jim Jewett 05 Apr '06

05 Apr '06

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 care about ordering constraints." How about using an (optional) annotation on __del__ methods, to indicate how cycles should be broken? As a strawman proposal: deletes = [obj for obj in cycle if hasattr(obj, "cycle")] deletes.sort() for obj in deletes: obj.__del__() Lightweight __del__ methods (such as most resource managers) could set the cycle attribute to True, and thereby ensure that they don't cause unbreakable cycles. Fancier object frameworks could use different values for the cycle attribute. Any object whose __del__ is not annotated will still be at least as likely to get finalized as it is today. -jJ

13 33

Re: [Python-Dev] [Python-checkins] r43545 - in python/trunk: Doc/lib/libcalendar.tex Lib/calendar.py
by Tim Peters 05 Apr '06

05 Apr '06

> 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-global functions, and only for the single default instance of Calendar created by the module. If so, then (a) the functionality of the Calendar class is weaker now, and in a backward-incompatible way; and, (b) the new module-global firstweekday() and setfirstweekday() functions are a more obscure way to restore the lost functionality for just one specific instance of a Calendar subclass. I don't see the attraction to any part of this. > --- python/trunk/Lib/calendar.py (original) > +++ python/trunk/Lib/calendar.py Sat Apr 1 22:40:23 2006 > @@ -128,25 +128,14 @@ > """ > > def __init__(self, firstweekday=0): > - self._firstweekday = firstweekday # 0 = Monday, 6 = Sunday > - > - def firstweekday(self): > - return self._firstweekday > - > - def setfirstweekday(self, weekday): > - """ > - Set weekday (Monday=0, Sunday=6) to start each week. > - """ > - if not MONDAY <= weekday <= SUNDAY: > - raise IllegalWeekdayError(weekday) > - self._firstweekday = weekday > + self.firstweekday = firstweekday # 0 = Monday, 6 = Sunday Removing those Calendar methods is backward-incompatible, ... > -firstweekday = c.firstweekday > -setfirstweekday = c.setfirstweekday > +def firstweekday(): > + return c.firstweekday > + > +def setfirstweekday(firstweekday): > + if not MONDAY <= firstweekday <= SUNDAY: > + raise IllegalWeekdayError(firstweekday) > + c.firstweekday = firstweekday > + > monthcalendar = c.monthdayscalendar > prweek = c.prweek And here they're obscurely added back again, but work only for the module-global default instance `c` of the TextCalendar subclass.

5 11

Reminder: TRUNK FREEZE. 2.5a1, 00:00 UTC, Wednesday 5th of April.
by Anthony Baxter 05 Apr '06

05 Apr '06

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 05 Apr '06

05 Apr '06

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, to try to ensure the most effective possible result. In the spirit of open source events the sprint is open to all. The venue is the Grand Hotel, Reykjavik, http://www.grand.is/. The following objectives are of interest to the sponsors. * Improving the decimal module by implementing portions in C * Investigate whether RPython offers sufficient speedup over the regular CPython interpreter to replace tailored C and C++ code in MMP gaming applications * Implement an ordered dictionary in both C and Python * Implement data-structure-specific algorithms, which rely heavily on certain data structures, as RPython * Adding an iterator interface (similar to re.finditer) to the struct module * Further refine the PyPy LLVM back end to improve general execution speeds * Offer the PyPy team a sprint venue to continue their development work on Python implementations written in Python * Create a string subtype that provides lazy slicing without copying Sprinters are, as always, free to choose the aspects of Python they choose to work on. Flights should be booked to and from Keflavik airport (KEF). There will be a mid-week “let your hair down” social event to which all sprint participants are cordially invited. In order to ensure that sufficient meeting space is available, please notify Steve Holden of your intention to attend by emailing steve(a)holdenweb.com. regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd www.holdenweb.com Love me, love my blog holdenweb.blogspot.com

1 0

Re: [Python-Dev] reference leaks, __del__, and annotations
by Phillip J. Eby 05 Apr '06

05 Apr '06

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) 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.

4 5