[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] http://bugs.python.org/issue1339 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1793] ctypes.util.find_msvcrt() function
Amaury Forgeot d'Arc added the comment: Fine with me. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1793 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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, the __del__ method will trigger a TypeError about the unexpected keyword argument. Attached is a very simple test program that triggers the problem. It runs just fine with Python 2.4 however. -- components: Library (Lib) files: subprocessapi.py messages: 60024 nosy: rene.st severity: major status: open title: subprocess.Popen.poll/__del__ API breakage versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9190/subprocessapi.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1857 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 handle multiple servers versions: Python 2.4, Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9191/patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1858 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 title: textwrap doesn't linebreak on \n type: behavior versions: Python 2.4, Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 -- components: Library (Lib) files: test_tb_print_last.py messages: 60028 nosy: tzot severity: normal status: open title: traceback.print_last fails type: behavior versions: Python 2.5, Python 2.6 Added file: http://bugs.python.org/file9193/test_tb_print_last.py __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1860 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 example I issued works with the patched version. Added file: http://bugs.python.org/file9194/traceback_patch.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1860 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue215555] Parser crashes for deeply nested list displays
Changes by Ralf Schmitt: -- nosy: +schmir Tracker [EMAIL PROTECTED] http://bugs.python.org/issue21 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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]\nKeeps running TOSSIM with random seeds until something fails, which with a width of 78 gets broken both before and after the Keeps. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:\Program Files\Python25\lib\lib-tk\Tkinter.py, line 1403, in __call__ return self.func(*args) File C:\Program Files\Python25\lib\idlelib\IOBinding.py, line 357, in save_as self.editwin.store_file_breaks() File C:\Program Files\Python25\lib\idlelib\PyShell.py, line 209, in store_file_breaks new_file = open(self.breakpointPath,w) IOError: [Errno 13] Permission denied: 'C:\\Users\\Rich\\.idlerc\\breakpoints.lst' The error is not generated if I manually unhide the breakpoints file. The issue is unaffected by the hidden (or not) status of the .idlerc folder. -- components: IDLE messages: 60034 nosy: Piffen, kbk, loewis, richjtd, tiran severity: normal status: open title: Error on Save As in IDLE (Vista 32-bit) versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1862 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_exception(sys.last_type, sys.last_value, sys.last_traceback, limit, file)'. Furthermore, in the doc: http://docs.python.org/dev/library/sys.html#sys.last_type ... they are set when an exception is not handled ... In your script, you *are* handling the exception. Your script really should use traceback.print_exc() instead. BTW, your patch basically makes print_last() identical to print_exc()... -- nosy: +amaury.forgeotdarc resolution: - invalid status: open - closed __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1860 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 time the _wrap_chunks method is called. Thanks. -- nosy: +marketdickinson __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 next in queue, especially if scheduled at the same time. -- components: Library (Lib) messages: 60033 nosy: pbureau severity: minor status: open title: sched scheduler.queue class member is unordered type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1596321 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 me. I'm still for the changing of the behaviour to what I expected, but I can live with this otherwise. Documenting that this is the behaviour in the textwrap docs, and suggesting workarounds for those who want the other choice might be a good idea tho. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 in T.wrap('one two\nthree four'): print line
...
one two
three
four
The surprise (if I understand correctly) is not the first line break, but the
second, between
three and four: it shouldn't be necessary, since three four fits quite
happily on a
line of length 14.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1859
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1596321 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to make a 2 line change seems like overkill to me. Could this be added as a new option to TextWrapper? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1859 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1861] sched scheduler.queue class member is unordered
Guido van Rossum added the comment: Sure. -- priority: - low __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1861 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1596321 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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) The day to rollover is behind us in the interval (i.e., today
# is day 5 (Saturday) and rollover is on day 3 (Thursday).
# Days to rollover is 6 - 5 + 3, or 4. In this case, it's the
# number of days left in the current week (1) plus the number
# of days in the next week until the rollover day (3).
if when.startswith('W'):
day = t[6] # 0 is Monday
if day self.dayOfWeek:
daysToWait = (day - self.dayOfWeek) - 1
self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24))
if day self.dayOfWeek:
daysToWait = (6 - self.dayOfWeek) + day
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1836
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 file: http://bugs.python.org/file9196/trace.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1693149 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 with GET) without it popping up a warning dialog, and without re-submitting the request if the user validates the dialog. So, a 302 response after a POST should generate a GET to the new URL. And, of course, without a Content-Length (there's no content in a GET so it can't have a length, does it?). -- nosy: +pitrou __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1401 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 majority of runs, I get an error message: Exception in thread Thread-1 (most likely raised during interpreter shutdown): Other tests seem to show that all modules are emptied by the cleanup process, but the thread insists to get time.sleep. And more interestingly, about every 50 runs, the process segfaults... I suspect that this is a problem similar to http://bugs.python.org/issue1856 -- nosy: +amaury.forgeotdarc Added file: http://bugs.python.org/file9195/thread_crash.py _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1596321 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1693149 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 [EMAIL PROTECTED] http://bugs.python.org/issue1858 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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? -- assignee: - kbk priority: - normal __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1862 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 interpreter shutdown, the main thread clears the other's thread TreadState. There you find the instruction: Py_CLEAR(tstate-frame); But this can call arbitrary python code on deallocation of locals, and release the GIL (file.close() in our case). The other thread can then continue to run. If it is given enough processor time before the whole process shutdowns, it will reach this line in ceval.c (line 2633) if (tstate-frame-f_exc_type != NULL) since tstate-frame has been cleared by the main thread == boom. There can be several ways to solve this problem: - While clearing a thread state, prevent the owner thread to gain focus. Only the main thread can Py_END_ALLOW_THREADS. The daemon thread is blocked forever, and will die there. - Be smarter when clearing tstate-frame: first call frame_clear(), which will free local variables, but let the frame in a valid state. Only after that, call Py_CLEAR(tstate-frame), when we are sure that no more thread switch can occur. Of course there are many other fields in a frame; we have to inspect them carefully. The first solution seems a more robust approach. -- nosy: +amaury.forgeotdarc __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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?. -- components: Interpreter Core messages: 60060 nosy: cptnwillard severity: minor status: open title: NameError with genexp in class scope type: behavior versions: Python 2.5 __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1863 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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_THREADS implementations but would it be possible to modify them on the fly from the thread doing the shutdown (main or not) while it holds the GIL such that all future calls to BEGIN_ALLOW_THREADS do not actually release the GIL and END_ALLOW_THREADS always blocks. That should bring other threads to a halt pretty quickly and prevent destructors from releasing the GIL (file.close, etc). __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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:
daysToWait = 6 - day + self.dayOfWeek
self.rolloverAt = self.rolloverAt + (daysToWait * (60 * 60 * 24))
Does it work for you?
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1836
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1857] subprocess.Popen.poll/__del__ API breakage
Changes by Christian Heimes: -- priority: - normal type: - resource usage __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1857 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1857 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 opportunity to walk the decoration chain if it wants. -- nosy: +pitrou _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1764286 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1023290 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 review the patches and maybe commit them. -- nosy: +jarpa Added file: http://bugs.python.org/file9198/exception_pickling_26.diff _ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1692335 _ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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. Other threads stay blocked and don't clean themselves: the OS will take care of them. Both approaches correct the initial problem, though. A remaining question is where exactly in Py_Finalize() we should ban other threads. I think that this point should be as late as possible, to allow some object/resources to be cleaned properly. Added file: http://bugs.python.org/file9200/thread_noswap.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 thread of course. Note that all this state must be restartable: after Py_Finalize(), it should be possible to call Py_Initialize() again. This seems to raise the score of the exit_thread approach. I don't know if multiple interpreters are well supported, though. Is there somewhere a list of use cases, or a test script that can exercise this? __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 machinations, but I digress.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1863 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 extension modules, so they must be left around permanently. I'm not convinced it works currently, or that there's use cases for it. Note that unloading python.so between Py_Finalize and Py_Initialize would definitely break things, as you'd lose all the global variables maintaining things. That eliminates the only it's more elegant argument. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 gone can we be sure it won't be called. Note that PyGILState_Ensure has two behaviours: it can be called when your thread is already running python code and has a tstate, or it can be called when you have none. revision 59231 fixed the former, but only when Py_Finalize hasn't finished. It doesn't fix it for any daemon threads, or for dummy threads (created outside of python's control). ... You're right, I did forget the 3 other places that acquire the interpreter_lock. The more I think about it the more I think our two approaches are equivalent, but conditionalizing the release means we don't need to touch the broken PyThread_exit_thread functions. I think the banning should be as early as possible, right after call_sys_exitfunc() has finished. You can't do anything sane once the interpreter is half-gone (despite the precedent of trying anyway.) __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1863 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 (ie, what if they *do* want it verified? What if they want to specify CSIDL_FLAG_CREATE?) That said though, I don't object to the patch as it stands, and agree it will meet the requirements of the majority of people who need a known path on Windows. -- nosy: +mhammond __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1763 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 note that PyThread_exit_thread() was completely broken, becoming a no-op once threading was initialized, and even before then it would exit the process rather than just the thread. I've fixed it for pthreads, but not for any of the other platforms. Added file: http://bugs.python.org/file9199/python-trunk-issue1856-threadexit.diff __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 on revision 59231 ? the PyGILState_Ensure stuff should now remain valid during the PyInterpreterState_Clear() call. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1856 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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;
if (i 0) {
PyErr_SetString(PyExc_OverflowError,
new string is too long);
return NULL;
}
}
Here i and j are signed ints (Py_ssize_t) initially know to be = 0; i
can only become 0 through overflow. This is the place where Ismail
(cartman) found a crash because the test was optimized away by GCC 4.3
before we added -fwrap.
If we ever hope to clean up the code to the point where -fwrapv is no
longer needed, the audit should find this spot! (Good thing we at least
had a unittest for the overflow check. This should be standard practice
for all overflow checks, as long it doesn't require allocating a GB or
more of memory.)
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1621
__
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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] http://bugs.python.org/issue1621 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 tomorrow unless I hear objections. Added file: http://bugs.python.org/file9201/rational_tweaks.patch __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 rational whose denominator is less than a given number. This seems useful for computations in which you want to sacrifice some accuracy for speed. At one point in this discussion, Guido suggested that Decimal removed the need for a method like this, and this type isn't optimized for speed anyway. The other, currently named approximate, returns the simplest rational within a certain distance of the real value. This seems useful for converting from float and displaying results to users, where we prefer readability over accuracy (yes, I'll take '1/3' even though it's farther away than '1234/3690'.). We could provide 0, 1, or both of them, or an accessor for the continued fraction representation of the number, which might help with third-party implementations of both. I've never actually used either of these, so I can't say which is actually more useful. It's probably a good question to send to the full python-dev list. Even if we decide against including them in the class, we might put the implementations into the docs or the test as a demonstration. __ Tracker [EMAIL PROTECTED] http://bugs.python.org/issue1682 __ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
