[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Jeffrey Yasskin added the comment: After this come the two approximation methods. Both are implemented using the continued fraction representation of the number: http://en.wikipedia.org/wiki/Continued_fraction#Best_rational_approximations. The first, currently named "trim", takes the closest rati

[issue1682] Move Demo/classes/Rat.py to Lib/rational.py and fix it up.

Jeffrey Yasskin added the comment: Here's a patch that adds construction from strings (Guido favored them) and .from_decimal(), changes __init__ to __new__ to enforce immutability, and removes "rational." from repr and the parens from str. I don't expect this to be contentious, so I'll commit it

[issue1621] Do not assume signed integer overflow behavior

Ismail Donmez added the comment: FWIW I reported this to GCC bugzilla as a missing diagnostic @ http://gcc.gnu.org/PR34843 __ Tracker <[EMAIL PROTECTED]> __

[issue1621] Do not assume signed integer overflow behavior

Guido van Rossum added the comment: I think the -Wstrict-overflow option may not be enough for the audit we need. The overflow issue in expandtabs() still exists (in 2.5 as well as in the trunk): if (*p == '\n' || *p == '\r') { i += j; old_j = j = 0;

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Adam Olsen added the comment: Hrm. It seems you're right. Python needs thread-local data to determine if the GIL is held by the current thread. Thus, autoTLSkey and all that need to never be torn down. (The check could be done much more directly than the current PyThreadState_IsCurrent machin

[issue1763] Winpath module - easy access to Windows directories like My Documents

Mark Hammond added the comment: I'm not sure why the approach of "load-em-all" is being taken. Interestingly, SHGetFolderPathW is listed as deprecated, so I doubt that list will grow too much, but the implementation as specified prevents the user from using other facilities available via the API

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Amaury Forgeot d'Arc added the comment: > PyGILState_Ensure WOULD block forever if it acquired the GIL > before doing anything else. Is it possible at all? PyThread_acquire_lock is not reentrant. __ Tracker <[EMAIL PROTECTED]> _

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Adam Olsen added the comment: PyGILState_Ensure WOULD block forever if it acquired the GIL before doing anything else. The only way to make Py_Initialize callable after Py_Finalize is to make various bits of the finalization into no-ops. For instance, it's currently impossible to unload C exten

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Amaury Forgeot d'Arc added the comment: > That doesn't matter. PyGILState_Ensure needs to remain valid > *forever*. Only once the process is completely gone can we be sure > it won't be called. We could apply the same idea: when exiting, PyGILState_Ensure() blocks forever, except for the main

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Adam Olsen added the comment: > Adam, did you notice the change on revision 59231 ? the > PyGILState_Ensure stuff should now remain valid during the > PyInterpreterState_Clear() call. That doesn't matter. PyGILState_Ensure needs to remain valid *forever*. Only once the process is completely go

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Amaury Forgeot d'Arc added the comment: Adam, your patch cover one case of the thread releasing the GIL (Py_ALLOW_THREADS), but there are more calls to PyThread_acquire_lock (the checkinterval for example). I have a competing patch: it makes the main thread never release the GIL after some point

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Amaury Forgeot d'Arc added the comment: > PyGILState_Ensure would still be broken. > It touches various things that get torn down (autoInterpreterState, > autoTLSkey, and the HEAD_LOCK macros) before it grabs the GIL. > Reordering should be possible of course. Adam, did you notice the change o

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Adam Olsen added the comment: I'm not sure I understand you, Gregory. Are arguing in favour of adding extra logic to the GIL code, or against it? I'm attaching a patch that has non-main thread exit, and it seems to fix the test case. It doesn't fix the PyGILState_Ensure problems though. Also

[issue1863] NameError with genexp in class scope

Raymond Hettinger added the comment: I don't follow what you mean. Can you post a working version of the code fragment? -- nosy: +rhettinger __ Tracker <[EMAIL PROTECTED]> __

[issue1692335] Fix exception pickling: Move initial args assignment to BaseException.__new__

Jaroslav Pachola added the comment: While zseil's patch for Python 2.5 works for me (on the current 2.5.1 download), svn version of Python 2.6 rejects the 2.6 patch. Attaching fixed 2.6 patch (2 rejects, 1 fuzz fixed, patch works without complains for me). I would be very glad if someone could re

[issue1863] NameError with genexp in class scope

Guido van Rossum added the comment: It's a weakness, not a bug. Just use a different variable name besides 'a'. -- nosy: +gvanrossum __ Tracker <[EMAIL PROTECTED]> __

[issue1023290] proposed struct module format code addition

Antoine Pitrou added the comment: FWIW, an use case of this I have encountered is to generate a string of random bytes from the long object returned by random.getrandbits(). -- nosy: +pitrou _ Tracker <[EMAIL PROTECTED]>

[issue1836] 'weekly' rotating logging file rotation incorrect

Vinay Sajip added the comment: There's already been a change to this code, since 2.5.1.1. Here's the code in trunk: if when.startswith('W'): day = t[6] # 0 is Monday if day != self.dayOfWeek: if day < self.dayOfWeek: daysToWait = self.dayOfWeek - day - 1 else:

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Gregory P. Smith added the comment: agreed, during shutdown the other threads should be stopped. anything to do this complicates acquiring and releasing the GIL by adding another check to see if we're shutting down. brainstorm: I haven't looked at the existing BEGIN_ALLOW_THREADS and END_ALLOW_

[issue1764286] inspect.getsource does not work with decorated functions

Antoine Pitrou added the comment: Rather than devising something specific to the co_firstlineno attribute, why not have functools.update_wrapper add a "wrapped_func" attribute pointing to the original function object? That way, each function inspecting the decorated function would have the opport

[issue1857] subprocess.Popen.poll/__del__ API breakage

Amaury Forgeot d'Arc added the comment: Does the attached patch correct your problem? -- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9197/subprocess_poll.patch __ Tracker <[EMAIL PROTECTED]>

[issue1863] NameError with genexp in class scope

New submission from Willard: The following code does not work like expected, it triggers a NameError. class C: a = 42 list(a for _ in 'x') >>> NameError: global name 'a' is not defined This issue was discussed on comp.lang.python in the thread "Is this a bug, or is it me?". -

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Adam Olsen added the comment: I think non-main threads should kill themselves off if they grab the interpreter lock and the interpreter is tearing down. They're about to get killed off anyway, when the process exits. PyGILState_Ensure would still be broken. It touches various things that get t

[issue1857] subprocess.Popen.poll/__del__ API breakage

Changes by Christian Heimes: -- priority: -> normal type: -> resource usage __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing lis

[issue1858] Make .pypirc handle multiple servers

Christian Heimes added the comment: I've changed the target version to 2.6+. We can't add new features to 2.5 and earlier. -- keywords: +easy, patch nosy: +tiran priority: -> normal type: -> rfe versions: +Python 3.0 -Python 2.4, Python 2.5 __ Tracker <

[issue1862] Error on "Save As" in IDLE (Vista 32-bit)

Christian Heimes added the comment: It's a duplicate of an already known problem. It seems that files on Vista inherit the flags of their parent folder. Can you test it on your box and see under which circumstances a file has the hidden flag set and how it affects read and write attempts on Vista

[issue1856] shutdown (exit) can hang or segfault with daemon threads running

Amaury Forgeot d'Arc added the comment: I uploaded a script for a similar issue: http://bugs.python.org/issue1596321 (thread_crash.py) which sometimes segfaults on Windows XP (trunk version, debug build), with the same call stacks as printed by Gregory, on both threads. I explain it this way: On

[issue1693149] patch to make 'trace.py --ignore-module' accept module name list.

Raghuram Devarakonda added the comment: The patch trace.diff contains the code and doc change. -- keywords: +easy severity: normal -> title: trace.py --ignore-module should accept module name list. -> patch to make 'trace.py --ignore-module' accept module name list. type: -> rfe Added

[issue1401] urllib2 302 POST

Antoine Pitrou added the comment: Hi, Sending a 302 in response to a POST is a very common practice so that the browser is redirected to a "normal", non state-changing page after the POST request has been processed. It is useful in that it allows the user to reload the resulting page (fetched wi

[issue1693149] trace.py --ignore-module should accept module name list.

Changes by Raghuram Devarakonda: Removed file: http://bugs.python.org/file7923/trace_patch.diff _ Tracker <[EMAIL PROTECTED]> _ ___ Python-bu

[issue1836] 'weekly' rotating logging file rotation incorrect

Kathryn M Kowalski added the comment: downloaded from ActiveState aug 2007 Python 2.5.1.1 # Case 2) The day to rollover is further in the interval (i.e., today is # day 2 (Wednesday) and rollover is on day 6 (Sunday). Days to # next rollover is simply 6 - 2 - 1, or 3. # Case 3)

[issue1596321] KeyError at exit after 'import threading' in other thread

Amaury Forgeot d'Arc added the comment: If a python daemon thread is still running when the interpreter exits, it is likely to fail in random ways. Here is another example, which does not use imports. I run the script many times, with latest version in trunk, on Windows XP, debug build. In the

[issue1861] sched scheduler.queue class member is unordered

Raymond Hettinger added the comment: Checked-in in rev 60024. -- resolution: -> fixed status: open -> closed __ Tracker <[EMAIL PROTECTED]> __

[issue1596321] KeyError at exit after 'import threading' in other thread

Adam Olsen added the comment: Is the bug avoided if you import threading first and use it instead of thread? I'd like to see thread removed in 3.0 (renamed to _thread or the like.) -- nosy: +Rhamphoryncus _ Tracker <[EMAIL PROTECTED]>

[issue1861] sched scheduler.queue class member is unordered

Raymond Hettinger added the comment: Will add a method that returns an ordered list of events. -- type: behavior -> rfe versions: +Python 2.6 -Python 2.5 __ Tracker <[EMAIL PROTECTED]> __

[issue1859] textwrap doesn't linebreak on "\n"

Guido van Rossum added the comment: Good luck reaching him. I'm pretty sure that the default behavior intentional *reflows* all input text. Perhaps you can derive clues from reading the docs (which I haven't)? __ Tracker <[EMAIL PROTECTED]>

[issue1859] textwrap doesn't linebreak on "\n"

Mark Dickinson added the comment: Is it worth double checking with Greg Ward that this behaviour really is intentional? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1861] sched scheduler.queue class member is unordered

Guido van Rossum added the comment: Sure. -- priority: -> low __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe:

[issue1859] textwrap doesn't linebreak on "\n"

Guido van Rossum added the comment: Mark, it looks like the replace_whitespace flag shouldn't be used with input containing newlines. __ Tracker <[EMAIL PROTECTED]> __ _

[issue1861] sched scheduler.queue class member is unordered

Patrick Bureau added the comment: Indeed, the queue is not directly exposed by a method, but the information is nonetheless interesting for monitoring the content. If it's not a bug, then maybe this could be changed to a feature request for a new method to retrieve the queue's events. __

[issue1859] textwrap doesn't linebreak on "\n"

Tom Parker added the comment: @Guido: Thanks for the suggestion, it fixes my immediate problem! @Mark: Yup, that was exactly my issue. It took a while to figure out why the heck it was ignoring my linebreaks, and then once I'd found replace_whitespace it appeared to be doing the "wrong" thing to

[issue1859] textwrap doesn't linebreak on "\n"

Mark Dickinson added the comment: For what it's worth, I think there is a legitimate complaint here, though it was initially unclear to me exactly what that complaint was. Consider the following: >>> from textwrap import * >>> T = TextWrapper(replace_whitespace=False, width=14) >>> for line i

[issue1596321] KeyError at exit after 'import threading' in other thread

Gregory P. Smith added the comment: gah, sorry i misread the report. you are correct. -- versions: +Python 2.4, Python 2.5, Python 2.6 _ Tracker <[EMAIL PROTECTED]> _ _

[issue1859] textwrap doesn't linebreak on "\n"

Guido van Rossum added the comment: Use .splitlines() to break the input into lines, wrap each "line" separately, and join again? __ Tracker <[EMAIL PROTECTED]> __ _

[issue1859] textwrap doesn't linebreak on "\n"

Tom Parker added the comment: Is there any other way to do what I was trying to do then (both dynamic wrapping for long segments + some static breaks)? Right now, the only option I can think of is writing a textwrap.TextWrapper subclass that implements my patch, and copying 70-ish lines of code t

[issue1859] textwrap doesn't linebreak on "\n"

Guido van Rossum added the comment: The original behavior is intentional. Please don't attempt to "fix" it. -- nosy: +gvanrossum resolution: -> rejected status: open -> closed __ Tracker <[EMAIL PROTECTED]>

[issue1861] sched scheduler.queue class member is unordered

Guido van Rossum added the comment: Looking at that change more, the queue is now maintained as a heapq. Perhaps the queue member is for internal use only? __ Tracker <[EMAIL PROTECTED]> __ __

[issue1861] sched scheduler.queue class member is unordered

Guido van Rossum added the comment: Raymond touched it last. :-) Perhaps r38041 is to blame? -- assignee: -> rhettinger nosy: +gvanrossum, rhettinger __ Tracker <[EMAIL PROTECTED]> __ __

[issue1596321] KeyError at exit after 'import threading' in other thread

Christian Walther added the comment: I'm not sure what you mean by "doesn't fail" - from the output you quote, I'd say that it does fail. It's in fact the same output as I get right now with Python 2.5.1 on Mac OS X. Would you classify that KeyError as expected behavior? _

[issue1862] Error on "Save As" in IDLE (Vista 32-bit)

New submission from Rich: Issue 1743 might be related to this. Using "Save As..." in IDLE does work, but if breakpoints.lst is hidden (which it is when Python generates it) it also generates this error in the Shell: Exception in Tkinter callback Traceback (most recent call last): File "C:\P

[issue1861] sched scheduler.queue class member is unordered

New submission from Patrick Bureau: In Python 2.4, retrieving sched's scheduler.queue class member would return a time ordered list of events as expected. Since Python 2.5, the same operation retrieves a list of unordered scheduled events. This makes it difficult to know which events are really

[issue1859] textwrap doesn't linebreak on "\n"

Tom Parker added the comment: If replace_whitespace in textwrap is set to False (True is default) then there are newlines. Yes, if you haven't set this then the patch does nothing (but that sounds sane to me) The exact text was "RadioTest TOSSIM stress tester by Tom Parker <[EMAIL PROTECTED]>\nK

[issue1859] textwrap doesn't linebreak on "\n"

Mark Dickinson added the comment: Could you give an example showing the unexpected behaviour, and describing what behaviour you'd expect, please? As far as I can tell, the patch has no effect on textwrap.wrap or textwrap.fill, since any newlines have already been converted to spaces by the ti

[issue215555] Parser crashes for deeply nested list displays

Changes by Ralf Schmitt: -- nosy: +schmir Tracker <[EMAIL PROTECTED]> ___ Python-bugs-list mailing list Unsubscribe: http://mail.p

[issue1860] traceback.print_last fails

Amaury Forgeot d'Arc added the comment: > traceback.print_last() depends on the existence of sys.last_type Yes, that is exactly as documented: >>> help(traceback.print_last) Help on function print_last in module traceback: print_last(limit=None, file=None) This is a shorthand for 'print_exce

[issue1860] traceback.print_last fails

Χρήστος Γεωργίου (Christos Georgiou) added the comment: I haven't submitted a patch since the transition from sf.net to bugs.python.org; I assume that I don't have to open a new patch for this, but if I have to, please let me know and I will gladly do it. The unified diff is attached; the test e

[issue1860] traceback.print_last fails

New submission from Χρήστος Γεωργίου (Christos Georgiou): traceback.print_last() depends on the existence of sys.last_type, sys.last_value, sys.last_traceback, which don't always exist when called. See attached example file. I will shortly send the patch for Lib/traceback.py -- component

[issue1859] textwrap doesn't linebreak on "\n"

Tom Parker added the comment: Attaching a patch that corrects the issue (against python 2.4) Added file: http://bugs.python.org/file9192/textwrap-fix.patch __ Tracker <[EMAIL PROTECTED]> __ _

[issue1859] textwrap doesn't linebreak on "\n"

New submission from Tom Parker: If a piece of text given to textwrap contains one or more "\n", textwrap does not break at that point. I would have expected "\n" characters to cause forced breaks. -- components: Library (Lib) messages: 60026 nosy: palfrey severity: minor status: open tit

[issue1858] Make .pypirc handle multiple servers

New submission from Tarek Ziadé: explained here: http://wiki.python.org/moin/EnhancedPyPI The patch also adds unit tests for command/register.py and command/upload.py -- components: Distutils files: patch.diff messages: 60025 nosy: tarek severity: normal status: open title: Make .pypirc

[issue1857] subprocess.Popen.poll/__del__ API breakage

New submission from René Stadler: The commit to r45234 has added an internally used keyword attribute named _deadstate to subprocess.Popen.poll, which is called by the __del__ method of this class. If you derived your own class from subprocess.Popen that overrides .poll() without taking kwargs,

[issue1793] ctypes.util.find_msvcrt() function

Amaury Forgeot d'Arc added the comment: Fine with me. __ Tracker <[EMAIL PROTECTED]> __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.pyth

[issue1339] smtplib starttls() should ehlo() if it needs to

Gregory P. Smith added the comment: Accepted and applied, with appropriate documentation updates. In svn trunk r60020 for 2.6. -- resolution: -> accepted status: open -> closed versions: +Python 2.5, Python 2.6 __ Tracker <[EMAIL PROTECTED]>