Mailman 3 September 2006 - Python-Dev

Py_BuildValue and decref
by Mihai Ibanescu 12 Sep '06

12 Sep '06

Hi, Looking at: http://docs.python.org/api/arg-parsing.html The description for "O" is: "O" (object) [PyObject *] Store a Python object (without any conversion) in a C object pointer. The C program thus receives the actual object that was passed. The object's reference count is not increased. The pointer stored is not NULL. There is no description of what happens when Py_BuildValue fails. Will it decref the python object passed in? Will it not? Looking at tupleobject.h: /* Another generally useful object type is a tuple of object pointers. For Python, this is an immutable type. C code can change the tuple items (but not their number), and even use tuples are general-purpose arrays of object references, but in general only brand new tuples should be mutated, not ones that might already have been exposed to Python code. *** WARNING *** PyTuple_SetItem does not increment the new item's reference count, but does decrement the reference count of the item it replaces, if not nil. It does *decrement* the reference count if it is *not* ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ inserted in the tuple. Similarly, PyTuple_GetItem does not increment the returned item's reference count. */ So, if the call to PyTuple_SetItem fails, the value passed in is lost. Should I expect the same thing with Py_BuildValue? Looking at how other modules deal with this, I picked typeobject.c: result = Py_BuildValue("[O]", (PyObject *)type); if (result == NULL) { Py_DECREF(to_merge); return NULL; } so no attempt to DECREF type in the error case. Further down... if (n) { state = Py_BuildValue("(NO)", state, slots); if (state == NULL) goto end; } and further down: end: Py_XDECREF(cls); Py_XDECREF(args); Py_XDECREF(args2); Py_XDECREF(slots); Py_XDECREF(state); Py_XDECREF(names); Py_XDECREF(listitems); Py_XDECREF(dictitems); Py_XDECREF(copy_reg); Py_XDECREF(newobj); return res; so it will attempt to DECREF the (non-NULL) slots in the error case. It's probably not a big issue since if Py_BuildValue fails, you have bigger issues than memory leaks, but it seems inconsistent to me. Can someone that knows the internal implementation clarify one way over the other? Thanks! Misa

3 5

BRANCH FREEZE: release25-maint, 00:00UTC 12 September 2006
by Anthony Baxter 11 Sep '06

11 Sep '06

Ok, I haven't heard back from Martin, but I'm going to hope he's OK with tomorrow as a release date for 2.5rc2. If he's not, we'll try for the day after. In any case, I'm going to declare the release25-maint branch FROZEN as at 00:00 UTC on the 12th. That's about 12 hours from now. This is for 2.5rc2. Once this is out, I'd like to see as close to zero changes as possible for the next week or so until 2.5 final is released. My god, it's getting so close... Anthony -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

_PyGILState_NoteThreadState should be static or not?
by Neal Norwitz 11 Sep '06

11 Sep '06

Michael, In Python/pystate.c, you made this checkin: """ r39044 | mwh | 2005-06-20 12:52:57 -0400 (Mon, 20 Jun 2005) | 8 lines Fix bug: [ 1163563 ] Sub threads execute in restricted mode basically by fixing bug 1010677 in a non-broken way. """ _PyGILState_NoteThreadState is declared as static on line 54, but the definition on line 508 is not static. (HP's cc is complaining.) I don't see this referenced in any header file, it seems like this should be static? $ grep _PyGILState_NoteThreadState */*.ch] Python/pystate.c:static void _PyGILState_NoteThreadState(PyThreadState* tstate); Python/pystate.c: _PyGILState_NoteThreadState(tstate); Python/pystate.c: _PyGILState_NoteThreadState(t); Python/pystate.c:_PyGILState_NoteThreadState(PyThreadState* tstate) n

2 1

2.5c2
by Neal Norwitz 11 Sep '06

11 Sep '06

PEP 356 http://www.python.org/dev/peps/pep-0356/ has 2.5c2 scheduled for Sept 12. I checked in a fix for the last blocking 2.5 issue (revert sgml infinite loop bug). There are no blocking issues that I know of (the PEP is up to date). I expect Anthony will call for a freeze real soon now. It would be awesome if there were no more changes from now until for 2.5 final! (Changing the trunk or 2.4 branches are fine, updating doc for 2.5 is also fine). I will be running valgrind over 2.5, but don't expect anything to show up since the last run was pretty recent. Coverity has no outstanding issues and Klocwork results are pretty clean. It's not clear if the remaining warnings from Klocwork are real issues or not. Keep doing a bunch of testing so we don't have any surprises in 2.5. n PS Scary as it sounds, I hope to have an HP-UX buildbot up and running real soon now. After 2.5 is out, I will fix the issues with the cygwin bot (ie, upgrade cygwin) and get the HP-UX bot running.

1 0

Community buildbots (was Re: User's complaints)
by glyph＠divmod.com 10 Sep '06

10 Sep '06

On Wed, 12 Jul 2006 10:30:17 +1000, Michael Ellerman <michael(a)ellerman.id.au> wrote: >Well here's one I stumbled across the other day. I don't know if it's >legit, but it's still bad PR: > >http://www.gbch.net/gjb/blog/software/discuss/python-sucks.html Having been exhorted (or maybe I mean "excoriated") by your friendly release manager earlier this week to post my comments and criticisms about Python here rather than vent in random IRC chatter, I feel morally compelled to comment. I see some responses to that post which indicate that the specific bug will be fixed, and that's good, but there is definitely a pattern he's talking about here, not just one issue. I think there is a general pattern of small, difficult to detect breakages in Python. Twisted (and the various other Divmod projects that I maintain) are thoroughly unit-tested, but there are still significant issues in each Python release that require changes. Unlike the jerk who posted that "python sucks" rant, I'm not leaving Python because one function changed in a major release; I do expect to have to maintain my projects myself, and major releases are "major" for a reason. I only wish that upgrading all my other dependencies were as easy as upgrading Python! I do see that the developers are working with some caution to avoid breaking code, and attempting to consider the cost of each change. However, although I've seen lots of discussions of what "average" code might break when exposed to new versions of Python, these discussions tend to be entirely hypothetical. Do the core Python developers typically run the test suites of major Python applications when considering major changes, such as Zope, Plone, TurboGears, and of course Twisted? Not that breakages would be considered unacceptable -- some gain is surely worth the cost -- but to establish some empirical level of burden on the community? I would like to propose, although I certainly don't have time to implement, a program by which Python-using projects could contribute buildslaves which would run their projects' tests with the latest Python trunk. This would provide two useful incentives: Python code would gain a reputation as generally well-tested (since there is a direct incentive to write tests for your project: get notified when core python changes might break it), and the core developers would have instant feedback when a "small" change breaks more code than it was expected to. I can see that certain Python developers expect that some of this work is the responsibility of the user community, and to some extent that's true, but at least half of the work needs to be done _before_ the changes are made. If some Python change breaks half of Twisted, I would like to know about it in time to complain about the implementation, rather than flailing around once the Python feature-freeze has set in and hoping that it's nothing too serious. For example, did anyone here know that the new-style exceptions stuff in 2.5 caused hundreds of unit-test failures in Twisted? I am glad the change was made, and one of our users did catch it, so the process isn't fatally broken, but it is still worrying. Another problem is simply that the Python developers don't have the same very public voice that other language developers do. It doesn't necessarily have to be a blog, but python-dev is fast-paced and intimidating, and a vehicle for discussion among those in the know, rather than dissimenation to the community at large. It's a constant source of anxiety to me that I might miss some key feature addition to Python which breaks or distorts some key bit of Twisted functionality (as the new-style exceptions, or recent ImportWarning almost did) because I don't have enough time to follow all the threads here. I really appreciate the work that Steve Bethard et. al. are doing on the python-dev summaries, but they're still pretty dry and low level. While the new python.org is very nice, I do note that there's no "blogs" entry on the front page, something which has become a fixture on almost every other website I visit regularly. The news page is not very personal, mainly a listing of releases and events. There's no forum for getting the community _excited_ about new features (especially new features which are explicitly enabled by potential breakages), and selling them on the cool uses. Who knows, maybe I'll even start using decorators syntax all over the place if I see them presented somewhere by someone who is very excited about the feature and thinks it's worthwhile, rather than as a defense on a mailing list against a criticism, or a simple announcement of the feature's existence. I've seen the other side of this problem as well, so I can appreciate that it is quite difficult to get this kind of thing right: lots of applications using Twisted break when we change broken or deprecated APIs. Twisted is lucky though; it has numerous subprojects, and I maintain a half-dozen unrelated projects in a different repository. Twisted itself is a fairly representative "application using Twisted", so when something breaks "average" Twisted code, I know about it right away. Python is less an application using Python: the standard library is rather passive (there is no "end-to-end" application path to test, only individual functions and classes), and the test coverage of included Python modules is rather spotty. I hope someone finds some of these suggestions helpful. I only wish I had the time and energy to act on some of them.

29 85

Unicode Imports
by Kristján V. Jónsson 10 Sep '06

10 Sep '06

Hello All. I just added patch 1552880 to sourceforge. It is a patch for 2.6 (and 2.5) which allows unicode paths in sys.path and uses the unicode file api on windows. This is tried and tested on 2.5, and backported to 2.3 and is currently running on clients in china and esewhere. It is minimally intrusive to the inporting mechanism, at the cost of some string conversion overhead (to utf8 and then back to unicode). Cheers, Kristján

11 29

Interest in a Python 2.3.6?
by Barry Warsaw 09 Sep '06

09 Sep '06

I am considering producing a Python 2.3.6 release, which would of course only be a bug fix maintenance release. The primary reason is that not all OS distributions have upgraded to Python 2.4 and I think it's worthwhile for us to bless a release that fixes known critical bugs. I'm willing to be the release manager for 2.3.6, but I'm hoping you all will be able to help identify the most important bugs that need fixing. First, is there interest in getting a 2.3.6 release out? I'd propose keeping things simple, by picking a date and releasing what we've got at that date (assuming of course all the unit tests pass). It's probably a good idea to add a wiki page tracking the fixes we want to get in there. 2.5 final is slated for 12-Sep-2006 and I know that Anthony is planning for a 2.4.4 soon after that. I'm thinking that we'd try to do a 2.3.6 a couple of weeks after 2.4.4 so that people who care about it aren't stacked up with fixing too many branches at once. My first thought was to shoot for Monday October 9th. What are the potential 2.3.6 fixes? Nothing on this page: http://www.python.org/download/releases/2.3.5/bugs/ seems critical to me. I know that I've added some important email package fixes that are already in Subversion. There are tons of bugs and patches reported against 2.3 in SF (lament: why won't SF just / tell/ me how many there are?), but I have no idea atm which, if any, are important enough to go into a 2.3.6. I haven't yet done an svn diff to see what changes are already in there. I don't have the cycles to fix things myself, so it would be up to everyone to help commit fixes. I'll ride herd a bit if necessary. Thoughts? I don't want to waste my time if nobody thinks a 2.3.6 would be useful, but I'm happy to do it if there's community support. I'll also need the usual help with Windows installers and documentation updates. Cheers, -Barry

4 6

2.5 status
by Neal Norwitz 09 Sep '06

09 Sep '06

There are 3 bugs currently listed in PEP 356 as blocking: http://python.org/sf/1551432 - __unicode__ breaks on exception classes http://python.org/sf/1550938 - improper exception w/relative import http://python.org/sf/1541697 - sgmllib regexp bug causes hang Does anyone want to fix the sgmlib issue? If not, we should revert this week before c2 is cut. I'm hoping that we will have *no changes* in 2.5 final from c2. Should there be any bugs/patches added to or removed from the list? The buildbots are currently humming along, but I believe all 3 versions (2.4, 2.5, and 2.6) are fine. Test out 2.5c1+ and report all bugs! n

5 10

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser 09 Sep '06

09 Sep '06

Patch / Bug Summary ___________________ Patches : 413 open ( +1) / 3407 closed (+10) / 3820 total (+11) Bugs : 897 open ( -3) / 6167 closed (+18) / 7064 total (+15) RFE : 234 open ( +1) / 238 closed ( +2) / 472 total ( +3) New / Reopened Patches ______________________ Fix decimal context management for 2.5 (2006-09-02) CLOSED http://python.org/sf/1550886 opened by Nick Coghlan Fix for rpartition() end-case (2006-09-03) CLOSED http://python.org/sf/1551339 opened by Raymond Hettinger Updated spec file for 2.5 release. (2006-09-03) CLOSED http://python.org/sf/1551340 opened by Sean Reifschneider unparse.py decorator support (2006-09-04) http://python.org/sf/1552024 opened by Adal Chiriliuc eval docstring typo (2006-09-04) CLOSED http://python.org/sf/1552093 opened by Ori Avtalion Fix error checks and leaks in setobject.c (2006-09-05) CLOSED http://python.org/sf/1552731 reopened by gbrandl Fix error checks and leaks in setobject.c (2006-09-05) CLOSED http://python.org/sf/1552731 opened by Raymond Hettinger Unicode Imports (2006-09-05) http://python.org/sf/1552880 opened by Kristján Valur Fix inspect.py 2.5 slowdown (2006-09-06) CLOSED http://python.org/sf/1553314 opened by Nick Coghlan locale.getdefaultlocale() bug when _locale is missing (2006-09-06) http://python.org/sf/1553427 opened by STINNER Victor UserDict New Style (2006-09-09) http://python.org/sf/1555097 opened by Indy Performance enhancements. (2006-09-09) http://python.org/sf/1555098 opened by Indy Patches Closed ______________ Fix decimal context management for 2.5 (2006-09-02) http://python.org/sf/1550886 closed by ncoghlan Fix for rpartition() end-case (2006-09-02) http://python.org/sf/1551339 closed by nnorwitz Updated spec file for 2.5 release. (2006-09-02) http://python.org/sf/1551340 closed by nnorwitz eval docstring typo (2006-09-04) http://python.org/sf/1552093 closed by nnorwitz crash in dict_equal (2006-08-24) http://python.org/sf/1546288 closed by nnorwitz Patches for OpenBSD 4.0 (2006-08-15) http://python.org/sf/1540470 closed by nnorwitz Fix error checks and leaks in setobject.c (2006-09-05) http://python.org/sf/1552731 closed by rhettinger Fix error checks and leaks in setobject.c (2006-09-05) http://python.org/sf/1552731 closed by gbrandl make exec a function (2006-09-01) http://python.org/sf/1550800 closed by gbrandl Ellipsis literal "..." (2006-09-01) http://python.org/sf/1550786 closed by gbrandl Fix inspect.py 2.5 slowdown (2006-09-06) http://python.org/sf/1553314 closed by ncoghlan New / Reopened Bugs ___________________ from . import bug (2006-09-02) CLOSED http://python.org/sf/1550938 opened by ganges master random.choice(setinstance) fails (2006-09-02) CLOSED http://python.org/sf/1551113 opened by Alan Build of 2.4.3 on fedora core 5 fails to find asm/msr.h (2006-09-02) http://python.org/sf/1551238 opened by George R. Goffe tiny bug in win32_urandom (2006-09-03) CLOSED http://python.org/sf/1551427 opened by Rocco Matano __unicode__ breaks for exception class objects (2006-09-03) http://python.org/sf/1551432 opened by Marcin 'Qrczak' Kowalczyk Wrong link to unicode database (2006-09-03) CLOSED http://python.org/sf/1551669 opened by Yevgen Muntyan unpack list of singleton tuples not unpacking (2006-07-11) CLOSED http://python.org/sf/1520864 reopened by gbrandl UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R (2006-09-04) CLOSED http://python.org/sf/1552304 opened by TFKyle PEP 290 <-> normal docu... (2006-09-05) CLOSED http://python.org/sf/1552618 opened by Jens Diemer Python polls unecessarily every 0.1 when interactive (2006-09-05) http://python.org/sf/1552726 opened by Richard Boulton Python polls unnecessarily every 0.1 second when interactive (2006-09-05) http://python.org/sf/1552726 reopened by akuchling subprocess.Popen(cmd, stdout=sys.stdout) fails (2006-07-31) CLOSED http://python.org/sf/1531862 reopened by nnorwitz ConfigParser converts option names to lower case on set() (2006-09-05) CLOSED http://python.org/sf/1552892 opened by daniel Pythonw doesn't get rebuilt if version number changes (2006-09-05) http://python.org/sf/1552935 opened by Jack Jansen python 2.5 install can't find tcl/tk in /usr/lib64 (2006-09-06) http://python.org/sf/1553166 opened by David Strozzi logging.handlers.RotatingFileHandler - inconsistent mode (2006-09-06) http://python.org/sf/1553496 opened by Walker Hale datetime.datetime.now() mangles tzinfo (2006-09-06) http://python.org/sf/1553577 opened by Skip Montanaro Class instance apparently not destructed when expected (2006-09-06) http://python.org/sf/1553819 opened by Peter Donis PyOS_InputHook() and related API funcs. not documented (2006-09-07) http://python.org/sf/1554133 opened by A.M. Kuchling Bugs Closed ___________ itertools.tee raises SystemError (2006-09-01) http://python.org/sf/1550714 closed by nnorwitz Typo in Language Reference Section 3.2 Class Instances (2006-08-28) http://python.org/sf/1547931 closed by nnorwitz from . import bug (2006-09-02) http://python.org/sf/1550938 closed by gbrandl tiny bug in win32_urandom (2006-09-03) http://python.org/sf/1551427 closed by gbrandl sgmllib.sgmlparser is not thread safe (2006-08-29) http://python.org/sf/1548288 closed by gbrandl test_anydbm segmentation fault (2006-08-21) http://python.org/sf/1544106 closed by greg Wrong link to unicode database (2006-09-03) http://python.org/sf/1551669 closed by gbrandl unpack list of singleton tuples not unpacking (2006-07-11) http://python.org/sf/1520864 closed by nnorwitz UnixCCompiler runtime_library_dir uses -R instead of -Wl,-R (2006-09-04) http://python.org/sf/1552304 closed by tfkyle gcc trunk (4.2) exposes a signed integer overflows (2006-08-23) http://python.org/sf/1545668 closed by nnorwitz Exceptions don't call _PyObject_GC_UNTRACK(self) (2006-08-17) http://python.org/sf/1542051 closed by gbrandl PEP 290 <-> normal docu... (2006-09-05) http://python.org/sf/1552618 closed by gbrandl SimpleXMLRpcServer still uses sys.exc_value and sys.exc_type (2006-07-19) http://python.org/sf/1525469 closed by akuchling unbalanced parentheses from command line crash pdb (2006-07-22) http://python.org/sf/1526834 closed by akuchling Python polls unnecessarily every 0.1 second when interactive (2006-09-05) http://python.org/sf/1552726 closed by akuchling subprocess.Popen(cmd, stdout=sys.stdout) fails (2006-07-31) http://python.org/sf/1531862 closed by niemeyer subprocess.Popen(cmd, stdout=sys.stdout) fails (2006-07-31) http://python.org/sf/1531862 closed by niemeyer ConfigParser converts option names to lower case on set() (2006-09-05) http://python.org/sf/1552892 closed by gbrandl SWIG wrappers incompatible with 2.5c1 (2006-09-01) http://python.org/sf/1550559 closed by gbrandl Building Python 2.4.3 on Solaris 9/10 with Sun Studio 11 (2006-05-28) http://python.org/sf/1496561 closed by andyfloe Curses module doesn't install on Solaris 2.8 (2005-10-12) http://python.org/sf/1324799 closed by akuchling New / Reopened RFE __________________ Add traceback.print_full_exception() (2006-09-06) http://python.org/sf/1553375 opened by Michael Hoffman Print full exceptions as they occur in logging (2006-09-06) http://python.org/sf/1553380 opened by Michael Hoffman RFE Closed __________ random.choice(setinstance) fails (2006-09-02) http://python.org/sf/1551113 closed by rhettinger Add 'find' method to sequence types (2006-08-28) http://python.org/sf/1548178 closed by gbrandl

1 0

What windows tool chain do I need for python 2.5 extensions?
by Barry Scott 08 Sep '06

08 Sep '06

I have the tool chains to build extensions against your binary python 2.2, 2.3 and 2.4 on windows. What are the tool chain requirements for building extensions against python 2.5 on windows? Barry

2 1