[Python-Dev] patch review request: float.hex and float.fromhex
Does anyone have time to review the patch http://bugs.python.org/file10876/hex_float5.patch for issue 3008 (float <-> hexadecimal string conversion): http://bugs.python.org/issue3008 ? It would be really good if this could go in before next week's beta. Guido's approved the idea in principle, but I still need to: - get permission from Barry to check in a new feature this late in the release cycle, and - persuade some other developer to review the patch. I'll gladly 'pay' for a patch review by reviewing one or more of someone else's patches. Mark ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] patch review request: float.hex and float.fromhex
From: "Mark Dickinson" <[EMAIL PROTECTED]> Does anyone have time to review the patch http://bugs.python.org/file10876/hex_float5.patch for issue 3008 (float <-> hexadecimal string conversion): I'll look at it today and tomorrow. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Running Py2.6 with the -3 option
Some effort needs to be made to clear the standard library of -3 warnings. Running -3 on production code usually involves exercising library code so the useful result is obscured by Python complaining about itself. Since that use case involves the users own tests, I don't think the effort needs to be extended to our own unittest suite. But the rest of the library could likely benefit from a good -3 cleanup. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] A proposed solution for Issue 502236: Asyncrhonous exceptions between threads
[OK so a newbie post here so many apologies if I am doing this wrong] Quick Synopsis: A child thread in an executing Python program can not safely shutdown the program. The issue URL is: http://bugs.python.org/issue502236 So my proposal is: Example: We have three threads - t0 - Main system thread t1 - Worker thread t2 - Worker thread t1 encounters an issue that means it wants to shut down the application in as safe a way as possible A Solution: 1. Put in place a new function call sys.exitapplication, what this would do is: a. Mark a flag in t0's data structure saying a request to shutdown has been made b. Raise a new exception, SystemShuttingDown, in t1. 2. As the main interpreter executes it checks the "shutting down flag" in the per thread data and follows one of two paths: If it is t0: a. Stops execution of the current code sequence b. Iterates over all extant threads setting the "system shutdown" flag in the per thread data structure. Setting this flag is a one time deal - it can not be undone once set. (And to avoid issues with multiple threads setting it - it can only ever be a single fixed value so setting it multiple times results in the same answer) c. Enters a timed wait loop where it will allow the other threads time to see the signal. It will iterate this loop a set number of times to avoid being blocked on any given thread. d. When all threads have exited, or been forcefully closed, raise the SystemShuttingDown exception If it is not t0: a. Stops execution of the current code sequence b. Raises the exception, SystemShuttingDown. There are problems with this approach, as I see it they are (but please see the assumptions I have made): P1. If the thread is in a tight loop will it see the exception? Or more generally: when should the exception be raised? P2. When should the interpreter check this flag? I think the answer to both of these problems is to: Check the flag, and hence raise the exception, in the following circumstances: - When the interpreter executes a back loop. So this should catch the jump back to the top of a "while True:" loop - Just before the interpreter makes a call to a hooked in non-Python system function, e.g. file I/O, networking &c. Checking at these points should be the minimal required, I think, to ensure that a given thread can not ignore the exception. It may be possible, or even required, to perform the check every time a Python function call is made. I think this approach would then allow for the finally handlers to be called. Assumptions: [Here I must admit to a large amount of ignorance of the internals of Python at this time. So if my assumptions are incorrect I would greatly appreciate being told so :-) Preferably as polite as possible and any code pointers while welcome unless they point to some very esoteric and arcane area would be best kept general so I feel more of a spur to go learn the code base] 1. The Python interpreter has per thread information. 2. The Python interpreter can tell if the system, t0, thread is running. 3. The Python engine has (or can easily obtain) a list of all threads it created. 4. It is possible to raise exceptions as the byte code is executing. I am mailing this out as: A. I have no idea if my thoughts are correct or total un-mitigated rubbish :-) B. I believe the introduction of this proposal (if I am correct) will require a PEP being raised, which aiui requires building community support (which is very fair imo) so this is me trying to do so :-) So apologies if this post has been total spam (but no eggs) or too long - give a little whistle and it will all be OK again. Andy --Brain chemistry is not just for Christmas _ Play and win great prizes with Live Search and Kung Fu Panda http://clk.atdmt.com/UKM/go/101719966/direct/01/___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Py2.6 with the -3 option
On Fri, Jul 11, 2008 at 6:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > Some effort needs to be made to clear the standard library of -3 warnings. > Running -3 on production code usually involves exercising library code so > the useful result is obscured by Python complaining about itself. Since > that use case involves the users own tests, I don't think the effort needs > to be extended to our own unittest suite. But the rest of the library could > likely benefit from a good -3 cleanup. Yes, indeed. We should make sure, however, that the changes in the 2.6 libraries are the absolute minimum to get the job done. (I'm trying to pretend like this isn't violating the prohibition on all-inclusive overhauls in the stdlib.) -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Py2.6 with the -3 option
Benjamin Peterson wrote: On Fri, Jul 11, 2008 at 6:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: Some effort needs to be made to clear the standard library of -3 warnings. Running -3 on production code usually involves exercising library code so the useful result is obscured by Python complaining about itself. Since that use case involves the users own tests, I don't think the effort needs to be extended to our own unittest suite. But the rest of the library could likely benefit from a good -3 cleanup. Yes, indeed. We should make sure, however, that the changes in the 2.6 libraries are the absolute minimum to get the job done. (I'm trying to pretend like this isn't violating the prohibition on all-inclusive overhauls in the stdlib.) The prohibition is on *gratuitous* changes, basically along the lines of "if it ain't broke, don't fix it". The stdlib is definitely broken if it raises warnings of that kind. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Py2.6 with the -3 option
On Fri, Jul 11, 2008 at 8:02 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Benjamin Peterson wrote: >> >> Yes, indeed. We should make sure, however, that the changes in the 2.6 >> libraries are the absolute minimum to get the job done. (I'm trying to >> pretend like this isn't violating the prohibition on all-inclusive >> overhauls in the stdlib.) >> > The prohibition is on *gratuitous* changes, basically along the lines of "if > it ain't broke, don't fix it". The stdlib is definitely broken if it raises > warnings of that kind. Just because it's massive breakage fixage doesn't mean that it's unlikely to break something else. :) > > regards > Steve > -- > Steve Holden+1 571 484 6266 +1 800 494 3119 > Holden Web LLC http://www.holdenweb.com/ > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/musiccomposition%40gmail.com > -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Py2.6 with the -3 option
Benjamin Peterson wrote: On Fri, Jul 11, 2008 at 8:02 AM, Steve Holden <[EMAIL PROTECTED]> wrote: Benjamin Peterson wrote: Yes, indeed. We should make sure, however, that the changes in the 2.6 libraries are the absolute minimum to get the job done. (I'm trying to pretend like this isn't violating the prohibition on all-inclusive overhauls in the stdlib.) The prohibition is on *gratuitous* changes, basically along the lines of "if it ain't broke, don't fix it". The stdlib is definitely broken if it raises warnings of that kind. Just because it's massive breakage fixage doesn't mean that it's unlikely to break something else. :) I agree but, contrariwise, just because we are likely to break other things doesn't mean we shouldn't fix the massive breakage. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC http://www.holdenweb.com/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (07/04/08 - 07/11/08) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue number. Do NOT respond to this message. 1967 open (+43) / 13199 closed (+17) / 15166 total (+60) Open issues with patches: 621 Average duration of open issues: 700 days. Median duration of open issues: 1604 days. Open Issues Breakdown open 1939 (+42) pending28 ( +1) Issues Created Or Reopened (60) ___ Delete obsolete 'Unicode' in Py3 str docstrings; related fixes 07/04/08 CLOSED http://bugs.python.org/issue3284created tjreedy easy Fraction.from_any() 07/04/08 CLOSED http://bugs.python.org/issue3285created rhettinger patch IDLE opens window too low on Windows 07/04/08 http://bugs.python.org/issue3286created tjreedy Fraction constructor should raise TypeError instead of Attribute 07/04/08 CLOSED http://bugs.python.org/issue3287created rhettinger patch float.as_integer_ratio method is not documented 07/05/08 http://bugs.python.org/issue3288created marketdickinson unnecessary call to time and localtime slows time.mktime 07/05/08 CLOSED http://bugs.python.org/issue3289created nother_jnelson python-config --cflags includes irrelevant flags 07/05/08 http://bugs.python.org/issue3290created sacha rlcompleter doesn't work anymore 07/05/08 CLOSED http://bugs.python.org/issue3291created pitrou patch Position index limit; s.insert(i,x) not same as s[i:i]=[x] 07/05/08 http://bugs.python.org/issue3292created tjreedy incorrect comments for PyObject_ReleaseBuffer07/05/08 http://bugs.python.org/issue3293created pitrou SVN repository contains an incorrect symbolic link 07/05/08 CLOSED http://bugs.python.org/issue3294created pitrou PyExc_BufferError is declared but nowhere defined07/05/08 CLOSED http://bugs.python.org/issue3295created pitrou patch print function not executed in python 3.0 tutorial 07/05/08 CLOSED http://bugs.python.org/issue3296created segfaulthunter Python interpreter uses Unicode surrogate pairs only before the 07/06/08 http://bugs.python.org/issue3297created ezio.melotti Multiline string with quotes is not parsed correctly.07/06/08 CLOSED http://bugs.python.org/issue3298created Stavros invalid object destruction in re.finditer() 07/06/08 http://bugs.python.org/issue3299created haypo patch urllib.quote and unquote - Unicode issues07/06/08 http://bugs.python.org/issue3300created mgiuca patch DoS when lo is negative in bisect.insort_right() / _left() 07/06/08 CLOSED http://bugs.python.org/issue3301created haypo patch segfault on gettext(None)07/06/08 http://bugs.python.org/issue3302created haypo patch invalid ref count on locale.strcoll() error
Re: [Python-Dev] Running Py2.6 with the -3 option
On Fri, Jul 11, 2008 at 7:02 AM, Steve Holden <[EMAIL PROTECTED]> wrote: > Benjamin Peterson wrote: >> >> On Fri, Jul 11, 2008 at 6:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >>> >>> Some effort needs to be made to clear the standard library of -3 >>> warnings. >>> Running -3 on production code usually involves exercising library code >>> so >>> the useful result is obscured by Python complaining about itself. Since >>> that use case involves the users own tests, I don't think the effort >>> needs >>> to be extended to our own unittest suite. But the rest of the library >>> could >>> likely benefit from a good -3 cleanup. >> >> Yes, indeed. We should make sure, however, that the changes in the 2.6 >> libraries are the absolute minimum to get the job done. (I'm trying to >> pretend like this isn't violating the prohibition on all-inclusive >> overhauls in the stdlib.) >> > The prohibition is on *gratuitous* changes, basically along the lines of "if > it ain't broke, don't fix it". The stdlib is definitely broken if it raises > warnings of that kind. Is the stdlib broken or is it the warnings that are broken? The code is just fine in 2.6. Adding pragmas to disable warnings would be just fine. Or we could hardcode some warnings as "already seen". -- Adam Olsen, aka Rhamphoryncus ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Py2.6 with the -3 option
On Fri, Jul 11, 2008 at 12:26 PM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Fri, Jul 11, 2008 at 7:02 AM, Steve Holden <[EMAIL PROTECTED]> wrote: >> Benjamin Peterson wrote: >>> >>> On Fri, Jul 11, 2008 at 6:24 AM, Raymond Hettinger <[EMAIL PROTECTED]> >>> wrote: Some effort needs to be made to clear the standard library of -3 warnings. Running -3 on production code usually involves exercising library code so the useful result is obscured by Python complaining about itself. Since that use case involves the users own tests, I don't think the effort needs to be extended to our own unittest suite. But the rest of the library could likely benefit from a good -3 cleanup. >>> >>> Yes, indeed. We should make sure, however, that the changes in the 2.6 >>> libraries are the absolute minimum to get the job done. (I'm trying to >>> pretend like this isn't violating the prohibition on all-inclusive >>> overhauls in the stdlib.) >>> >> The prohibition is on *gratuitous* changes, basically along the lines of "if >> it ain't broke, don't fix it". The stdlib is definitely broken if it raises >> warnings of that kind. > > Is the stdlib broken or is it the warnings that are broken? Nothing is broken, per se, but the stdlib emits a ton of warnings through basic usage for Py3K-related changes. We are telling people to run their code in 2.6 with -3 and to eliminate all warnings in order to have 2to3 work to transition to 3.0. Having the stdlib itself emit warnings is just not reasonable. > The code > is just fine in 2.6. Adding pragmas to disable warnings would be just > fine. Or we could hardcode some warnings as "already seen". > No, we should eat our own dog food and transition the code over. If anything it will help with code maintenance between 2.x and 3.x. -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] A proposed solution for Issue 502236: Asyncrhonous exceptions between threads
This doesn't need to be an interpreter thing; it's easy to implement by the user (I've done it about a dozen times using a single global flag). If you want it to be automatic, it's even possible to make it happen automatically using sys.settrace() and friends (you can even make it reasonably fast if you use a C callback). - Josiah On Fri, Jul 11, 2008 at 4:27 AM, Andy Scott <[EMAIL PROTECTED]> wrote: > [OK so a newbie post here so many apologies if I am doing this wrong] > > Quick Synopsis: > > A child thread in an executing Python program can not safely shutdown the > program. The issue URL is: http://bugs.python.org/issue502236 > > So my proposal is: > > Example: > > We have three threads - > t0 - Main system thread > t1 - Worker thread > t2 - Worker thread > > t1 encounters an issue that means it wants to shut down the application in > as safe a way as possible > > > A Solution: > > 1. Put in place a new function call sys.exitapplication, what this would do > is: > a. Mark a flag in t0's data structure saying a request to shutdown has > been made > b. Raise a new exception, SystemShuttingDown, in t1. > 2. As the main interpreter executes it checks the "shutting down flag" in > the per thread data and follows one of two paths: > If it is t0: > a. Stops execution of the current code sequence > b. Iterates over all extant threads setting the "system shutdown" flag > in the per thread data structure. Setting this flag is a one time deal - it > can not be undone once set. (And to avoid issues with multiple threads > setting it - it can only ever be a single fixed value so setting it multiple > times results in the same answer) > c. Enters a timed wait loop where it will allow the other threads time > to see the signal. It will iterate this loop a set number of times to avoid > being blocked on any given thread. > d. When all threads have exited, or been forcefully closed, raise the > SystemShuttingDown exception > > If it is not t0: > a. Stops execution of the current code sequence > b. Raises the exception, SystemShuttingDown. > > There are problems with this approach, as I see it they are (but please see > the assumptions I have made): > > P1. If the thread is in a tight loop will it see the exception? Or more > generally: when should the exception be raised? > P2. When should the interpreter check this flag? > > I think the answer to both of these problems is to: > > Check the flag, and hence raise the exception, in the following > circumstances: > > - When the interpreter executes a back loop. So this should catch the jump > back to the top of a "while True:" loop > - Just before the interpreter makes a call to a hooked in non-Python > system function, e.g. file I/O, networking &c. > > Checking at these points should be the minimal required, I think, to ensure > that a given thread can not ignore the exception. It may be possible, or > even required, to perform the check every time a Python function call is > made. > > I think this approach would then allow for the finally handlers to be > called. > > Assumptions: > > [Here I must admit to a large amount of ignorance of the internals of Python > at this time. So if my assumptions are incorrect I would greatly appreciate > being told so :-) Preferably as polite as possible and any code pointers > while welcome unless they point to some very esoteric and arcane area would > be best kept general so I feel more of a spur to go learn the code base] > > 1. The Python interpreter has per thread information. > 2. The Python interpreter can tell if the system, t0, thread is running. > 3. The Python engine has (or can easily obtain) a list of all threads it > created. > 4. It is possible to raise exceptions as the byte code is executing. > > I am mailing this out as: > > A. I have no idea if my thoughts are correct or total un-mitigated rubbish > :-) > B. I believe the introduction of this proposal (if I am correct) will > require a PEP being raised, which aiui requires building community support > (which is very fair imo) so this is me trying to do so :-) > > So apologies if this post has been total spam (but no eggs) or too long - > give a little whistle and it will all be OK again. > > Andy > -- > Brain chemistry is not just for Christmas > > > > Get Messenger on your Mobile! Get it now! > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/josiah.carlson%40gmail.com > > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
