[Python-Dev] 2.4.7: Final 2.4 release
Python 2.4 will become 5 years old this November. I plan to make the final security release this month or next month. If you want to see additional patches in Python 2.4, please let us now, or commit them yourself if you can. Remember that only security fixes can be considered for inclusion, and preferably only fixes that have already been applied to later releases of Python. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] ndPython: I NEED TO TALK WITH ONE OF THE PYTHON CORE
-On [20090626 22:29], Terry Reedy (tjre...@udel.edu) wrote: >If you were running on a PC with what is now considered to be very small >memory, I would hypothesize that you had filled memory so that the >interpreter or parts thereof were being swapped in and out of memory >from and to disk. Is any thing like that possible with the PSP? From what I know it has either 32 or 64 MB of RAM, depending on the model. The storage comes in the form of a Memory Stick PRO Duo, but I doubt it is used in any form as a paging or swap file. At least playing on my own it only accesses it when I want to save game data. -- Jeroen Ruigrok van der Werven / asmodai イェルーン ラウフロック ヴァン デル ウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Friendship is love without wings... ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] PEP 376
Hello, If no one objects, I'd like to push PEP 376 in the "accepted" status and go ahead with its implementation, with continuous feedback at Distutils-SIG as we did to build it. The next PEPs that are being discussed at Distutils-SIG are : - the new version of PEP 345 for the inclusion of fields like "installed_requires" (dependencies) - PEP 386, that talks about distribution version numbers (because it's needed to describe dependencies) While they are still under heavy discussion, I have good hope that they will both make it for 2.7 and 3.2. Regards Tarek -- Tarek Ziadé | http://ziade.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pthread sem PyThread_acquire_lock
I'll do my best to try and explain/contribute, but please feel free to correct anything I get wrong. I believe the "swallowing" he's referring to is the ignoring of errno EINTR. I don't think that's the correct place to handle signals to begin with- why not just use the signal module to deal with such a scenario? http://docs.python.org/dev/library/signal.html#module-signal AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers. There are many functions that don't return this value anymore, making them reentrant. I remember a number of years ago when it wasn't part of any standard to return EINTR or not, and so the only way to provide consistent behavior was to ignore it and loop. I'm not sure if that is still the case. A great example is reading from a socket. Whether or not it can be interrupted depends on the platform, so catching Ctrl+C often requires a timeout loop. Also, remember that signals are asynchronous in the sense that they are handled outside the normal execution flow of a program. Checking for EINTR probably isn't the best way to determine if a signal has been sent to the program. Cheers, Phillip On Sat, Jun 27, 2009 at 3:58 PM, Florian Mayer wrote: > > Martin v. Löwis wrote: >> >> Can you please explain what you mean by "swallowing"? > > The signals don't get through when acquiring the lock. >> >> What is the sequence of actions triggering the case you are talking >> about, what happens, and what do you expect to happen instead? > > Easiest way is to create a Queue.Queue and call .get() on it and try to > Ctrl-C it. >> >> Also, how would you fix this (in principle, not what the specific >> patch would look like)? > > Remove the loop that explicitly does this in a new function and use that > one in threadmodule.c for lock.acquire. >> >> Regards, >> Martin > > Best regards, > Florian > > PS: Excuse me, I messed up things once again. > > ___ > Python-Dev mailing list > Python-Dev@python.org > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/phillip.sitbon%2Bpython-dev%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 376
> If no one objects, I'd like to push PEP 376 in the "accepted" status > and go ahead with its implementation, > with continuous feedback at Distutils-SIG as we did to build it. I think this isn't quite the process. In the past, every PEP required BDFL pronouncement, which you should now seek. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] pthread sem PyThread_acquire_lock
> AFAIK, ignoring EINTR doesn't preclude the calling of signal handlers. This is my understanding as well - so I don't think Python actually "swallows" the signal. > A great example is reading from a socket. Whether or not it can be > interrupted depends on the platform, so catching Ctrl+C often requires > a timeout loop. > > Also, remember that signals are asynchronous in the sense that they > are handled outside the normal execution flow of a program. Checking > for EINTR probably isn't the best way to determine if a signal has > been sent to the program. I think it would be reasonable to support "asynchronous" exceptions, and Python supports SIGINT fairly well most of the time. It might be possible to support keyboard interrupts throughout the system, but changing Python to do so could also cause incompatibilities. So any change must be done with greatest care, but simultaneously, should also try to arrange to cover all cases. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Anyone against having a loop option for regrtest?
Something that's been helping me squirrel out "wacky" and "fun" bugs in multiprocessing is running the tests in a loop - sometimes hundreds of times. Right now, I hack this up with a bash script, but I'm sitting here wondering if adding a "loop for x iterations" option to regrtest.py would be useful to others as well. Any thoughts? Does anyone hate this idea with the power of a thousand suns? -jesse ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Anyone against having a loop option for regrtest?
Jesse Noller writes: > Any thoughts? Does anyone hate this idea with the power of a thousand suns? If somebody has the power of 1000 Suns at their disposal, maybe they can contribute a few buildbots? Wishful-thinking-is-the-order-of-the-day-ly y'rs, ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone against having a loop option for regrtest?
On Mon, Jun 29, 2009 at 6:59 PM, Jesse Noller wrote: > Something that's been helping me squirrel out "wacky" and "fun" bugs > in multiprocessing is running the tests in a loop - sometimes hundreds > of times. Right now, I hack this up with a bash script, but I'm > sitting here wondering if adding a "loop for x iterations" option to > regrtest.py would be useful to others as well. > > Any thoughts? Does anyone hate this idea with the power of a thousand suns? +1 for having this in regrtest. I've wished for this in the past, and ended up going the bash route, same as you. Collin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Anyone against having a loop option for regrtest?
On Mon, Jun 29, 2009 at 10:23 PM, Stephen J. Turnbull wrote: > Jesse Noller writes: > > > Any thoughts? Does anyone hate this idea with the power of a thousand suns? > > If somebody has the power of 1000 Suns at their disposal, maybe they > can contribute a few buildbots? > > Wishful-thinking-is-the-order-of-the-day-ly y'rs, > > Sorry I had to take mine down. That being said, I need to rummage up a mac mini with a lot of ram and possibly fire up VMWare fusion/virtualbox on it to have an os/x/linux/windows buildbot mini farm. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
