Mailman 3 March 2005 - Python-Dev

Re: [Python-checkins] python/dist/src/Modules readline.c, 2.82, 2.83
by Michael Hudson 30 Mar '05

30 Mar '05

mwh(a)users.sourceforge.net writes: > Update of /cvsroot/python/python/dist/src/Modules > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv10274 > > Modified Files: > readline.c > Log Message: > Fixes for > > [ 1166660 ] The readline module can cause python to segfault > > It seems to me that the code I'm rewriting here attempted to call any > user-supplied hook functions using the thread state of the thread that > called the hook-setting function, as opposed to that of the thread > that is currently executing. This doesn't work, in general. > > Fix this by using the PyGILState API (It wouldn't be that hard to > define a dummy version of said API when #ifndef WITH_THREAD, would > it?). > > Also, check the conversion to integer of the return value of a hook > function for errors (this problem was mentioned in the ipython bug > report linked to in the above bug). Oh, and I forgot to say: this should go into realease24-maint when that opens again. Cheers, mwh -- You're going to have to remember that I still think of Twisted as a big multiplayer game, and all this HTTP stuff is just kind of a grotty way to display room descriptions. -- Glyph Lefkowitz

1 0

Re: [Python-Dev] Re: webbrowser.py
by Rodrigo Dias Arruda Senra 30 Mar '05

30 Mar '05

| > On Thu, Mar 24, 2005 at 11:36:41AM -0300, Rodrigo Dias Arruda Senra wrote: | > > Edit libwebbrowser.tex as you see fit, then send it to me | > > and I'll TeXify it back to you. <wink> | > | > Uploaded to http://python.org/sf/754022 . I am not a native English | > speaker, and this is the first time I've edited a TeX file. Please | > correct my grammar, spelling, TeX, whatever... Outstanding work Oleg. I read it through and wouldn't change a bit. I have revised: libwebbrowser.tex.patch and webbrowser.py.patch. They are Ok regarding grammar, TeX and ... whatever <wink>. I recommend to apply both files. However, I would withdraw the third file -- webbrowser wrapper script, since the same functionality can be accomplished with: python -m webbrowser http://www.python.org best regards, Senra -- ,_ | ) Rodrigo Senra <rsenra |at| acm.org> |(______ ----------------------------------------------- _( (|__|] GPr Sistemas http://www.gpr.com.br _ | (|___|] IC - Unicamp http://www.ic.unicamp.br/~921234 ___ (|__|] L___(|_|] -----------------------------------------------

3 4

RELEASED Python 2.4.1 (final)
by Anthony Baxter 30 Mar '05

30 Mar '05

On behalf of the Python development team and the Python community, I'm happy to announce the release of Python 2.4.1 (final). Python 2.4.1 is a bug-fix release. See the release notes at the website (also available as Misc/NEWS in the source distribution) for details of the bugs squished in this release. Python 2.4.1 should be a completely painless upgrade from Python 2.4 - no new features have been added. For more information on Python 2.4.1, including download links for various platforms, release notes, and known issues, please see: http://www.python.org/2.4.1/ Highlights of this new release include: - Bug fixes. According to the release notes, several dozen bugs have been fixed, including a fix for the SimpleXMLRPCServer security issue (PSF-2005-001). Highlights of the previous major Python release (2.4) are available from the Python 2.4 page, at http://www.python.org/2.4/highlights.html Enjoy the new release, Anthony Anthony Baxter anthony(a)python.org Python Release Manager (on behalf of the entire python-dev team)

2 1

Re: [maintenance doc updates]
by Wolfgang Langner 30 Mar '05

30 Mar '05

Hello, Fred L. Drake wrote: > The maintenance version of the documentation has been updated: > > http://www.python.org/dev/doc/maint24/ Very good. The download links under http://docs.python.org/download.html doesn't work any more. (packages not there) But 2.4.1 is not yet released, so I will only remind this not criticise. bye by Wolfgang

1 0

Re: comprehension abbreviation (was: Adding any() and all())
by Jim Jewett 30 Mar '05

30 Mar '05

Gareth McCaughan wrote: > Some bit of my brain is convinced that [x in stuff if condition] > is the Right Syntax and keeps making me type it even though > I know it doesn't work. (and I agree with Gareth) On Monday 2005-03-14 12:42, Eric Nieuwland wrote: > The full syntax is: > [ f(x) for x in seq if pred(x) ] > being allowed to write 'x' instead of 'identity(x)' is already a > shortcut, just as dropping the conditional part. I think this is the heart of the disagreement. Mentally, I'm not collecting some function of x (which happens to be identity). I am filtering an existing set. Being able to collect f(x) instead is just a useful but hackish shortcut. Gareth again: > and in fact no set theorist would be at all troubled by seeing > { x in S : predicate(x) } > which is the nearest equivalent in mathematical notation > for the abbreviated comprehension expressions being discussed. Again, I agree. I think that is what I am unconsciously writing, by translating the ":" into "if" -jJ

6 5

using SCons to build Python
by Adam MacBeth 29 Mar '05

29 Mar '05

Has anyone ever considered using SCons to build Python? SCons is a great build tool written in Python that provides some Autoconf-like functionality (http://www.scons.org). It seems like this type of self-hosting would be a great testament to the power of Python as well as helping to reinforce the strength of SCons as a next generation build tool. Thanks, Adam

5 4

64-bit sequence and buffer protocol
by Travis Oliphant 29 Mar '05

29 Mar '05

I'm posting to this list to again generate open discussion on the problem in current Python that an int is used in both the Python sequence protocol and the Python buffer protocol. The problem is that a C-int is typically only 4 bytes long while there are many applications (mmap for example), that would like to access sequences much larger than can be addressed with 32 bits. There are two aspects to this problem: 1) Some 64-bit systems still define an C-int as 4 bytes long (so even in-memory sequence objects could not be addressed using the sequence protocol). 2) Even 32-bit systems have occasion to sequence a more abstract object (perhaps it is not all in memory) which requires more than 32 bits to address. These are the solutions I've seen: 1) Convert all C-ints to Py_LONG_LONG in the sequence and buffer protocols. 2) Add new C-API's that mirror the current ones which use Py_LONG_LONG instead of the current int. 3) Change Python to use the mapping protocol first (even for slicing) when both the mapping and sequence protocols are defined. 4) Tell writers of such large objects to not use the sequence and/or buffer protocols and instead use the mapping protocol and a different "bytes" object (that currently they would have to implement themselves and ignore the buffer protocol C-API). What is the opinion of people on this list about how to fix the problem. I believe Martin was looking at the problem and had told Perry Greenfield he was "fixing it." Apparently at the recent PyCon, Perry and he talked and Martin said the problem is harder than he had initially thought. It would be good to document what some of this problems are so that the community can assist in fixing this problem. -Travis O.

2 1

Re: [Python-checkins] python/dist/src/Python thread_pthread.h, 2.53, 2.53.4.1
by Andrew MacIntyre 29 Mar '05

29 Mar '05

anthonybaxter(a)users.sourceforge.net wrote: >Update of /cvsroot/python/python/dist/src/Python >In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv25872 > >Modified Files: > Tag: release24-maint > thread_pthread.h >Log Message: >Patch #1163249 - Correctly handle _POSIX_SEMAPHORES == -1 to mean no >support for posix semaphores. > > >Index: thread_pthread.h >=================================================================== >RCS file: /cvsroot/python/python/dist/src/Python/thread_pthread.h,v >retrieving revision 2.53 >retrieving revision 2.53.4.1 >diff -u -d -r2.53 -r2.53.4.1 >--- thread_pthread.h 7 Jul 2004 17:44:12 -0000 2.53 >+++ thread_pthread.h 16 Mar 2005 04:13:29 -0000 2.53.4.1 >@@ -16,9 +16,13 @@ > family of functions must indicate this by defining > _POSIX_SEMAPHORES. */ > #ifdef _POSIX_SEMAPHORES >+#if _POSIX_SEMAPHORES == -1 >+#define HAVE_BROKEN_POSIX_SEMAPHORES >+#else > #include <semaphore.h> > #include <errno.h> > #endif >+#endif > > #if !defined(pthread_attr_default) > # define pthread_attr_default ((pthread_attr_t *)NULL) > >_______________________________________________ >Python-checkins mailing list >Python-checkins(a)python.org >http://mail.python.org/mailman/listinfo/python-checkins > > This change has broken the build on FreeBSD 4.x for me: gcc -pthread -c -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes - I. -I./Include -DPy_BUILD_CORE -o Python/thread.o Python/thread.c In file included from Python/thread.c:101: Python/thread_pthread.h:19: syntax error *** Error code 1 Backing it out allows the build to proceed & there are no unexpected test failures. Compiler is gcc 2.95.4. Regards, Andrew. ------------------------------------------------------------------------- Andrew I MacIntyre "These thoughts are mine alone..." E-mail: andymac(a)bullseye.apana.org.au (pref) | Snail: PO Box 370 andymac(a)pcug.org.au (alt) | Belconnen ACT 2616 Web: http://www.andymac.org/ | Australia

2 2

BRANCH FREEZE for 2.4.1 final, 2005-03-30 00:00 UTC
by Anthony Baxter 29 Mar '05

29 Mar '05

The release24-maint branch is FROZEN from 00:00 UTC, 2005-03-30 (in about 11 hours from now). As usual, unless you're in the set (Anthony, MvL, Fred), please hold off on checkins to the branch until I send a message unfreezing it. Once we've had the appropriate brown-paper-bag time delay, the branch will be unfrozen for 2.4.2 in about 6 months time. -- Anthony Baxter <anthony(a)interlink.com.au> It's never too late to have a happy childhood.

1 0

@decoration of classes
by Jim Jewett 29 Mar '05

29 Mar '05

Josiah Carlson: > I just noticed that decoration of classes was not included with the > @decoration syntax that made it into Python 2.4. ... > Is the fact that it didn't make it into 2.4 due to a pronouncement Yes, but it wasn't a permanent decision, and I don't think he used the magic word "pronounce". Adding class decoration later is not difficult. Retracting class decoration later would have been impossible. Therefore Guido decided for version 2.4, but left the question open for the unspecified future. Changing it would take arguments stronger than symmetry or "why not?", so it probably won't change for 2.5, but if you have a compelling use case ... (Mine have all been using an object as a callable -- basically replacing a function. The itch hasn't been strong enough to bother me.) -jJ

6 7