[ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed
Bugs item #1483133, was opened at 2006-05-06 23:09 Message generated for change (Comment added) made by loewis You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 Status: Open Resolution: None >Priority: 5 Private: No Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) -- >Comment By: Martin v. Löwis (loewis) Date: 2007-01-22 09:06 Message: Logged In: YES user_id=21627 Originator: NO Python 2.4 is not actively maintained anymore. As this occurs in the debug build only, I recommend closing it as "won't fix". Just lowering the priority for now (svensoho, please don't change priorities). -- Comment By: svensoho (svensoho) Date: 2006-06-30 09:35 Message: Logged In: YES user_id=1518209 2.5 is already fixed: http://sourceforge.net/tracker/ index.php?func=detail&aid=1257960&group_id=5470&atid=105470 2.4 has exactly same problematic assertion, even same modification helps. Fedora has fixed it in their distribution: https://bugzilla.redhat.com/bugzilla/ show_bug.cgi?id=192592 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 09:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. -- Comment By: svensoho (svensoho) Date: 2006-05-26 16:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php -- Comment By: svensoho (svensoho) Date: 2006-05-15 10:26 Message: Logged In: YES user_id=1518209 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-978833 ] SSL-ed sockets don't close correct?
Bugs item #978833, was opened at 2004-06-24 11:57
Message generated for change (Settings changed) made by loewis
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=978833&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: Python 2.5
Status: Open
Resolution: None
Priority: 8
Private: No
Submitted By: kxroberto (kxroberto)
>Assigned to: Martin v. Löwis (loewis)
Summary: SSL-ed sockets don't close correct?
Initial Comment:
When testing FTP over SSL I have strong doubt, that
ssl-ed sockets are not closed correctly. (This doesn't
show with https because nobody takes care about whats
going on "after the party".) See the following :
---
I need to run FTP over SSL from windows (not shitty
sftp via ssh etc!)
as explained on
http://www.ford-hutchinson.com/~fh-1-pfh/ftps-ext.html
(good variant
3: FTP_TLS )
I tried to learn from M2Crypto's ftpslib.py (uses
OpenSSL - not
Pythons SSL) and made a wrapper for ftplib.FTP using
Pythons SSL.
I wrap the cmd socket like:
self.voidcmd('AUTH TLS')
ssl = socket.ssl(self.sock, self.key_file,
self.cert_file)
import httplib
self.sock = httplib.FakeSocket(self.sock, ssl)
self.file = self.sock.makefile('rb')
Everything works ok, if I don't SSL the data port
connection, but only
the
If I SSL the data port connection too, it almosts work,
but ...
self.voidcmd('PBSZ 0')
self.voidcmd('PROT P')
wrap the data connection with SSL:
ssl = socket.ssl(conn, self.key_file,
self.cert_file)
import httplib
conn = httplib.FakeSocket(conn, ssl)
than in retrbinary it hangs endless in the last 'return
self.voidresp()'. all data of the retrieved file is
already correctly
in my basket! The ftp server just won't send the final
'226 Transfer
complete.' on the cmd socket. Why?
def retrbinary(self, cmd, callback, blocksize=8192,
rest=None):
self.voidcmd('TYPE I')
conn = self.transfercmd(cmd, rest)
fp = conn.makefile('rb')
while 1:
#data = conn.recv(blocksize)
data = fp.read()#blocksize)
if not data:
break
callback(data)
fp.close()
conn.close()
return self.voidresp()
what could be reason?
The server is a ProFTPD 1.2.9 Server.
I debugged, that the underlying (Shared)socket of the
conn object is
really closed.
(If I simly omit the self.voidresp(), I have one file
in the box, but
subsequent ftp communication on that connection is not
anymore
correct.)
--
Comment By: Armin Rigo (arigo)
Date: 2006-11-20 12:33
Message:
Logged In: YES
user_id=4771
Originator: NO
Martin, I think the rev 50844 is wrong. To start with,
it goes clearly against the documentation for makefile()
which states that both the socket and the pseudo-file
can be closed independently. What httplib.py was doing
was correct.
I could write a whole essay about the twisted history
of socket.py. It would boil down to: in r43746, Georg
removed a comment that was partially out-of-date,
but that was essential in explaining why there was no
self._sock.close() in _socketobject.close(): because
the original purpose of _socketobject was to implement
dup(), so that multiple _socketobjects could refer to
the same underlying _sock. The latter would close
automagically when its reference counter dropped to
zero. (This means that your check-in also made dup()
stop working on all platforms.)
The real OP's problem is that the _ssl object keeps
a reference to the underlying _sock as well, as
kxroberto pointed out. We need somewhere code that
closes the _ssl object...
For reference, PyPy - which doesn't have strong
refcounting guarantees - added the equivalent of an
explicit usage counter in the C socket object, and
socket.py calls methods on its underlying object to
increment and decrement that counter. It looks like
a solution for CPython too - at least, relying on
refcounting is bad, if only because - as you have
just proved - it creates confusion. (Also,
httplib/urllib have their own explicitly-refcounted
wrappers...)
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-26 14:14
Message:
Logged In: YES
user_id=21627
This is now fixed in 50844. I won't backport it to 2.4, as
it may cause working code to fail. For example, httplib
would fail since it would already close the connection in
getresponse, when the response object should still be able
to read from the connection.
--
Comment By: Martin v. Löwis (loewis)
Date: 2006-07-03 14:03
Message:
Logged In: YES
user_id=21627
Can you please try the attached patch? It
[ python-Bugs-1641109 ] 2.3.6.4 Error in append and extend descriptions
Bugs item #1641109, was opened at 2007-01-21 23:34 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1641109&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Documentation Group: None >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: ilalopoulos (arafin) Assigned to: Nobody/Anonymous (nobody) Summary: 2.3.6.4 Error in append and extend descriptions Initial Comment: 2.3.6.4 Mutable Sequence Types (2.4.4 Python Doc) Error in the table describing append and extend operations for the list type. specificaly: s.append(x) same as s[len(s):len(s)] = [x] (2) s.extend(x) same as s[len(s):len(s)] = x (3) should be: s.append(x) same as s[len(s):len(s)] = x (2) s.extend(x) same as s[len(s):len(s)] = [x] (3) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-22 08:20 Message: Logged In: YES user_id=849994 Originator: NO Have you tried the original code and your corrections? If you do, you'll find that the original is correct. (In extend, x is already a sequence, so you mustn't wrap it in a list. In append, you want only one element added, so you wrap x in a list.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1641109&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1579370 ] Segfault provoked by generators and exceptions
Bugs item #1579370, was opened at 2006-10-18 02:23 Message generated for change (Comment added) made by awaters You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1579370&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Nobody/Anonymous (nobody) Summary: Segfault provoked by generators and exceptions Initial Comment: A reproducible segfault when using heavily-nested generators and exceptions. Unfortunately, I haven't yet been able to provoke this behaviour with a standalone python2.5 script. There are, however, no third-party c extensions running in the process so I'm fairly confident that it is a problem in the core. The gist of the code is a series of nested generators which leave scope when an exception is raised. This exception is caught and re-raised in an outer loop. The old exception was holding on to the frame which was keeping the generators alive, and the sequence of generator destruction and new finalization caused the segfault. -- Comment By: Andrew Waters (awaters) Date: 2007-01-22 08:46 Message: Logged In: YES user_id=1418249 Originator: NO A quick test on code that always segfaulted with unpatched Python 2.5 seems to work. Needs more extensive testing... -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-22 07:51 Message: Logged In: YES user_id=21627 Originator: NO I don't like mklaas' patch, since I think it is conceptually wrong to have PyTraceBack_Here() use the frame's thread state (mklaas describes it as dirty, and I agree). I'm proposing an alternative patch (tr.diff); please test this as well. File Added: tr.diff -- Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-17 07:01 Message: Logged In: YES user_id=33168 Originator: NO Bumping priority to see if this should go into 2.5.1. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-04 10:42 Message: Logged In: YES user_id=21627 Originator: NO Why do frame objects have a thread state in the first place? In particular, why does PyTraceBack_Here get the thread state from the frame, instead of using the current thread? Introduction of f_tstate goes back to r7882, but it is not clear why it was done that way. -- Comment By: Andrew Waters (awaters) Date: 2007-01-04 09:35 Message: Logged In: YES user_id=1418249 Originator: NO This fixes the segfault problem that I was able to reliably reproduce on Linux. We need to get this applied (assuming it is the correct fix) to the source to make Python 2.5 usable for me in production code. -- Comment By: Mike Klaas (mklaas) Date: 2006-11-27 18:41 Message: Logged In: YES user_id=1611720 Originator: YES The following patch resets the thread state of the generator when it is resumed, which prevents the segfault for me: Index: Objects/genobject.c === --- Objects/genobject.c (revision 52849) +++ Objects/genobject.c (working copy) @@ -77,6 +77,7 @@ Py_XINCREF(tstate->frame); assert(f->f_back == NULL); f->f_back = tstate->frame; +f->f_tstate = tstate; gen->gi_running = 1; result = PyEval_EvalFrameEx(f, exc); -- Comment By: Eric Noyau (eric_noyau) Date: 2006-11-27 18:07 Message: Logged In: YES user_id=1388768 Originator: NO We are experiencing the same segfault in our application, reliably. Running our unit test suite just segfault everytime on both Linux and Mac OS X. Applying Martin's patch fixes the segfault, and makes everything fine and dandy, at the cost of some memory leaks if I understand properly. This particular bug prevents us to upgrade to python 2.5 in production. -- Comment By: Tim Peters (tim_one) Date: 2006-10-28 05:18 Message: Logged In: YES user_id=31435 > I tried Tim's hope.py on Linux x86_64 and > Mac OS X 10.4 with debug builds and neither > one crashed. Tim's guess looks pretty damn > good too. Neal, note that it's the /Windows/ malloc that fills freed memory with "dangerous bytes" in a debug build -- this really has nothing to do with that it's a debug build of /Python/ apart from that on Windows a debug build of Python also links in the debug version of Microsoft's m
[ python-Bugs-1568240 ] Tix is not included in 2.5 for Windows
Bugs item #1568240, was opened at 2006-09-30 12:19 Message generated for change (Comment added) made by tzot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: Christos Georgiou (tzot) Assigned to: Martin v. Löwis (loewis) Summary: Tix is not included in 2.5 for Windows Initial Comment: (I hope "Build" is more precise than "Extension Modules" and "Tkinter" for this specific bug.) At least the following files are missing from 2.5 for Windows: DLLs\tix8184.dll tcl\tix8184.lib tcl\tix8.1\* -- >Comment By: Christos Georgiou (tzot) Date: 2007-01-22 14:13 Message: Logged In: YES user_id=539787 Originator: YES For me, yes, x86 is sufficient. Hopefully for others too. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-20 15:16 Message: Logged In: YES user_id=21627 Originator: NO It seems that I can provide Tix binaries only for x86, not for AMD64 or Itanium. Is that sufficient? -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-03 16:59 Message: Logged In: YES user_id=21627 Originator: NO Ah, ok. No, assigning this report to Neal or bumping its priority should not be done. -- Comment By: Christos Georgiou (tzot) Date: 2007-01-02 12:22 Message: Logged In: YES user_id=539787 Originator: YES Neal's message is this: http://mail.python.org/pipermail/python-dev/2006-December/070406.html and it refers to the 2.5.1 release, not prior to it. As you see, I refrained from both increasing the priority and assigning it to Neal, and actually just added a comment to the case with a related question, since I know you are the one responsible for the windows build and you already had assigned the bug to you. My adding this comment to the bug was nothing more or less than the action that felt appropriate, and still does feel appropriate to me (ie I didn't overstep any limits). The "we" was just all parties interested, and in this case, the ones I know are at least you (responsible for the windows build) and I (a user of Tix on windows). Happy new year, Martin! -- Comment By: Martin v. Löwis (loewis) Date: 2006-12-30 00:26 Message: Logged In: YES user_id=21627 Originator: NO I haven't read Neal's message yet, but I wonder what he could do about it. I plan to fix this with 2.5.1, there is absolutely no way to fix this earlier. I'm not sure who "we" is who would like to bump the bug, and what precisely this bumping would do; tzot, please refrain from changing the priority to higher than 7. These priorities are reserved to the release manager. -- Comment By: Christos Georgiou (tzot) Date: 2006-12-27 19:46 Message: Logged In: YES user_id=539787 Originator: YES Should we bump the bug up and/or assign it to Neal Norwitz as he requested on Python-Dev? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1568240&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 11:03 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None >Priority: 7 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 10:46 Message: Logged In: YES user_id=11375 Originator: NO This would be an API change, and therefore out-of-bounds for 2.5. I suggest giving up on this for 2.5.1 and only fixing it in 2.6. I'll add another warning to the docs, and maybe to the module as well. -- Comment By: David Watson (baikie) Date: 2007-01-21 17:10 Message: Logged In: YES user_id=1504904 Originator: YES Hold on, I have a plan. If _toc is only regenerated on locking, or at the end of a flush(), then the only way self._pending can be set at that time is if the application has made modifications before calling lock(). If we make that an exception-raising offence, then we can assume that self._toc is a faithful representation of the last known contents of the file. That means we can preserve the existing message keys on a reread without any of that _user_toc nonsense. Diff attached, to apply on top of mailbox-unified2. It's probably had even less review and testing than the previous version, but it appears to pass all the regression tests and doesn't change any existing semantics. File Added: mailbox-update-toc-new.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-20 22:16 Message: Logged In: YES user_id=11375 Originator: NO I'm starting to lose track of all the variations on the bug. Maybe we should just add more warnings to the documentation about locking the mailbox when modifying it and not try to fix this at all. -- Comment By: David Watson (baikie) Date: 2007-01-20 13:20 Message: Logged In: YES user_id=1504904 Originator: YES Hang on. If a message's key changes after recreating _toc, that does not mean that another process has modified the mailbox. If the application removes a message and then (inadvertently) causes _toc to be regenerated, the keys of all subsequent messages will be decremented by one, due only to the application's own actions. That's what happens in the "broken locking" test case: the program intends to remove message 0, flush, and then remove message 1, but because _toc is regenerated in between, message 1 is renumbered as 0, message 2 is renumbered as 1, and so the program deletes message 2 instead. To clear _toc in such code without attempting to preserve the message keys turns possible data loss (in the case that another process modified the mailbox) into certain data loss. That's what I'm concerned about. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-19 10:24 Message: Logged In: YES user_id=11375 Originator: NO After reflection, I don't think the potential changing actually makes things any worse. _generate() always starts num
[ python-Feature Requests-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount
Feature Requests item #1567331, was opened at 2006-09-28 21:36 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-22 16:09 Message: Logged In: YES user_id=308438 Originator: NO Josiah - OK...suppose I use your semantics: Create log ... at rollover, log -> log.1, create log anew ... at rollover, log -> log.2, create log anew ... at rollover, log -> log.3, and the user has set a backup count of 3 so I can't do log -> log.4 - then I still need to rename files, it seems to me. If I don't, and say reuse log.1, then the user gets an unintuitive ordering where log.1 is newer than log.3 sometimes, but not ar other times - so your approach would *only* be beneficial where the backup count was infinite. For such scenarios, I think it's better to either use e.g. logrotate and WatchedFileHandler, or create a new class based on RotatingFileHandler to do what you want. Providing support for "infinite" log files is not a common enough use case, IMO, to justify support in the core package. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-20 18:39 Message: Logged In: YES user_id=341410 Originator: NO What about an optional different semantic for log renaming? Rather than log -> log.1, log -> log.+1, so if you have log, log.1, log.2; log -> log.3 and log gets created anew. I've used a similar semantic in other logging packages, and it works pretty well. It would also allow for users to have an "infinite" count of logfiles (if that is what they want). -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-15 16:44 Message: Logged In: YES user_id=308438 Originator: NO The problem with this is that on rollover, RotatingFileHandler renames old logs: rollover.log.3 -> rollover.log.4, rollover.log.2 -> rollover.log.3, rollover.log.1 -> rollover.log.2, rollover.log -> rollover.log.1, and a new rollover.log is opened. With an arbitrary number of old log files, this leads to arbitrary renaming time - which could cause long pauses due to logging, not a good idea. If you are using e.g. logrotate or newsyslog, or a custom program to do logfile rotation, you can use the new logging.handlers.WatchedFileHandler handler (meant for use on Unix/Linux only - on Windows, logfiles can't be renamed or moved while in use and so the requirement doesn't arise) which watches the logged-to file to see when it changes. This has recently been checked into SVN trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1552726 ] Python polls unnecessarily every 0.1 second when interactive
Bugs item #1552726, was opened at 2006-09-05 10:42
Message generated for change (Comment added) made by akuchling
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1552726&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
Resolution: Fixed
Priority: 9
Private: No
Submitted By: Richard Boulton (richardb)
Assigned to: A.M. Kuchling (akuchling)
Summary: Python polls unnecessarily every 0.1 second when interactive
Initial Comment:
When python is running an interactive session, and is
idle, it calls "select" with a timeout of 0.1 seconds
repeatedly. This is intended to allow PyOS_InputHook()
to be called every 0.1 seconds, but happens even if
PyOS_InputHook() isn't being used (ie, is NULL).
To reproduce:
- start a python session
- attach to it using strace -p PID
- observe that python repeatedly
This isn't a significant problem, since it only affects
idle interactive python sessions and uses only a tiny
bit of CPU, but people are whinging about it (though
some appear to be doing so tongue-in-cheek) and it
would be nice to fix it.
The attached patch (against Python-2.5c1) modifies the
readline.c module so that the polling doesn't happen
unless PyOS_InputHook is not NULL.
--
>Comment By: A.M. Kuchling (akuchling)
Date: 2007-01-22 11:10
Message:
Logged In: YES
user_id=11375
Originator: NO
Applied to 2.5.1 in rev. 53516.
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2007-01-17 01:47
Message:
Logged In: YES
user_id=33168
Originator: NO
I'm fine if this patch is applied. Since it was applied to trunk, it
seems like it might as well go into 2.5.1 as well. I agree it's not that
high priority, but don't see much reason to wait either. OTOH, I won't
lose sleep if it's not applied, so do what you think is best.
--
Comment By: Richard Boulton (richardb)
Date: 2006-09-08 10:30
Message:
Logged In: YES
user_id=9565
I'm finding the function because it's defined in the
compiled library - the header files aren't examined by
configure when testing for this function. (this is because
configure.in uses AC_CHECK_LIB to check for
rl_callback_handler_install, which just tries to link the
named function against the library). Presumably, rlconf.h
is the configuration used when the readline library was
compiled, so if READLINE_CALLBACKS is defined in it, I would
expect the relevant functions to be present in the compiled
library.
In any case, this isn't desperately important, since you've
managed to hack around the test anyway.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-08 09:12
Message:
Logged In: YES
user_id=11375
That's exactly my setup. I don't think there is a -dev
package for readline 4.
I do note that READLINE_CALLBACKS is defined in
/usr/include/readline/rlconf.h, but Python's readline.c
doesn't include this file, and none of the readline headers
include it. So I don't know why you're finding the function!
--
Comment By: Richard Boulton (richardb)
Date: 2006-09-08 05:34
Message:
Logged In: YES
user_id=9565
HAVE_READLINE_CALLBACK is defined by configure.in whenever
the readline library on the platform supports the
rl_callback_handler_install() function. I'm using Ubuntu
Dapper, and have libreadline 4 and 5 installed (more
precisely, 4.3-18 and 5.1-7build1), but only the -dev
package for 5.1-7build1. "info readline" describes
rl_callback_handler_install(), and configure.in finds it, so
I'm surprised it wasn't found on akuchling's machine.
I agree that the code looks buggy on platforms in which
signals don't necessarily get delivered to the main thread,
but looks no more buggy with the patch than without.
--
Comment By: A.M. Kuchling (akuchling)
Date: 2006-09-07 10:38
Message:
Logged In: YES
user_id=11375
On looking at the readline code, I think this patch makes no
difference to signals.
The code in readline.c for the callbacks looks like this:
has_input = 0;
while (!has_input) {
...
has_input = select.select(rl_input);
}
if (has_input > 0) {read character}
elif (errno == EINTR) {check signals}
So I think that, if a signal is delivered to a thread and
select() in the main thread doesn't return EINTR, the old
code is just as problematic as the code with this patch.
The (while !has_input) loop doesn't check for signals at all
as an exit condition.
I'm not sure what to do at this point. I think the new code
is no worse than the old code with r
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I pressed Ctrl-Z and then Enter ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again foo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I pressed Ctrl-Z and then Enter ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again foo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1567331 ] logging.RotatingFileHandler has no "infinite" backupCount
Feature Requests item #1567331, was opened at 2006-09-28 14:36 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Skip Montanaro (montanaro) Assigned to: Vinay Sajip (vsajip) Summary: logging.RotatingFileHandler has no "infinite" backupCount Initial Comment: It seems to me that logging.RotatingFileHandler should have a way to spell "never delete old log files". This is useful in situations where you want an external process (manual or automatic) make decisions about deleting log files. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-22 09:26 Message: Logged In: YES user_id=341410 Originator: NO There are at least two ways to "solve" the "problem" regarding "what do we name the log after it is full". Here are just a few: 1) The 'being written to' log is X.log, the most recent 'finished' log is X.log., it uses the reverse renaming semantic to what is already available. 2) The 'being written to' log is X.log, the most recent 'finished' log is the log just before a 'missing' log. Say you have .log, .log.1, .log.3; .log.1 is the most recent 'finished' log, and when .log is full, you delete .log.3, rename .log to .log.2, and start writing to a new .log ( (mod x) + 1 method ). Semantic #1 isn't reasonable when you have a large number of log files (that isn't infinite), just like the current semantic isn't reasonable when you have a large number of log files (even infinite), but #2 is reasonable (in terms of filesystem manipulations) when you have any number of log files. It is unambiguous to the computer, and can be made unambiguous to the user with a 'get log filenames' function that returns the chronological listing of log files (everything after the 'missing' file comes first, then the stuff before the 'missing' file, then the 'current' log). -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-22 08:09 Message: Logged In: YES user_id=308438 Originator: NO Josiah - OK...suppose I use your semantics: Create log ... at rollover, log -> log.1, create log anew ... at rollover, log -> log.2, create log anew ... at rollover, log -> log.3, and the user has set a backup count of 3 so I can't do log -> log.4 - then I still need to rename files, it seems to me. If I don't, and say reuse log.1, then the user gets an unintuitive ordering where log.1 is newer than log.3 sometimes, but not ar other times - so your approach would *only* be beneficial where the backup count was infinite. For such scenarios, I think it's better to either use e.g. logrotate and WatchedFileHandler, or create a new class based on RotatingFileHandler to do what you want. Providing support for "infinite" log files is not a common enough use case, IMO, to justify support in the core package. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-20 10:39 Message: Logged In: YES user_id=341410 Originator: NO What about an optional different semantic for log renaming? Rather than log -> log.1, log -> log.+1, so if you have log, log.1, log.2; log -> log.3 and log gets created anew. I've used a similar semantic in other logging packages, and it works pretty well. It would also allow for users to have an "infinite" count of logfiles (if that is what they want). -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-15 08:44 Message: Logged In: YES user_id=308438 Originator: NO The problem with this is that on rollover, RotatingFileHandler renames old logs: rollover.log.3 -> rollover.log.4, rollover.log.2 -> rollover.log.3, rollover.log.1 -> rollover.log.2, rollover.log -> rollover.log.1, and a new rollover.log is opened. With an arbitrary number of old log files, this leads to arbitrary renaming time - which could cause long pauses due to logging, not a good idea. If you are using e.g. logrotate or newsyslog, or a custom program to do logfile rotation, you can use the new logging.handlers.WatchedFileHandler handler (meant for use on Unix/Linux only - on Windows, logfiles can't be renamed or moved while in use and so the requirement doesn't arise) which watches the logged-to file to see when it changes. This has recently been checked into SVN trunk. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1567331&group_id=5470 _
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I pressed Ctrl-Z and then Enter ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again foo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633941 ] for line in sys.stdin: doesn't notice EOF the first time
Bugs item #1633941, was opened at 2007-01-12 05:34 Message generated for change (Comment added) made by draghuram You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: Nobody/Anonymous (nobody) Summary: for line in sys.stdin: doesn't notice EOF the first time Initial Comment: [forwarded from http://bugs.debian.org/315888] for line in sys.stdin: doesn't notice EOF the first time when reading from tty. The test program: import sys for line in sys.stdin: print line, print "eof" A sample session: [EMAIL PROTECTED] python foo.py foo <--- I pressed Enter and then Ctrl-D foo <--- then this appeared, but not more eof <--- this only came when I pressed Ctrl-D a second time [EMAIL PROTECTED] Seems to me that there is some buffering issue where Python needs to read end-of-file twice to notice it on all levels. Once should be enough. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:45 Message: Logged In: YES user_id=984087 Originator: NO Ok. This may sound stupid but I couldn't find a way to attach a file to this bug report. So I am copying the code here: import sys line = sys.stdin.readline() while (line): print line, line = sys.stdin.readline() print "eof" * -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 12:37 Message: Logged In: YES user_id=984087 Originator: NO Sorry for my duplicate comment. It was a mistake. On closer examination, the OP's description does seem to indicate some issue. Please look at (attached) stdin_noiter.py which uses readline() directly and it does not have the problem described here. It properly detects EOF on first CTRL-D. This points to some problem with the iterator function fileobject.c:file_iternext(). I think that the first CTRL-D might be getting lost somewhere in the read ahead code (which only comes into picture with iterator). -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Raghuram Devarakonda (draghuram) Date: 2007-01-22 11:34 Message: Logged In: YES user_id=984087 Originator: NO I am not entirely sure that this is a bug. $ cat testfile line1 line2 $ python foo.py < testfile This command behaves as expected. Only when the input is from tty, the above described behaviour happens. That could be because of the terminal settings where characters may be buffered until a newline is entered. -- Comment By: Gabriel Genellina (gagenellina) Date: 2007-01-13 23:20 Message: Logged In: YES user_id=479790 Originator: NO Same thing occurs on Windows. Even worse, if the line does not end with CR, Ctrl-Z (EOF in Windows, equivalent to Ctrl-D) has to be pressed 3 times: D:\Temp>python foo.py foo <--- I pressed Enter ^Z <--- I pressed Ctrl-Z and then Enter again foo <--- this appeared ^Z <--- I pressed Ctrl-Z and then Enter again D:\Temp>python foo.py foo^Z <--- I pressed Ctrl-Z and then Enter ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again ^Z <--- cursor stays here; I pressed Ctrl-Z and then Enter again foo -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633941&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1586414 ] tarfile.extract() may cause file fragmentation on Windows XP
Bugs item #1586414, was opened at 2006-10-28 23:22 Message generated for change (Comment added) made by gustaebel You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Rejected Priority: 5 Private: No Submitted By: Enoch Julias (enochjul) Assigned to: Lars Gustäbel (gustaebel) Summary: tarfile.extract() may cause file fragmentation on Windows XP Initial Comment: When I use tarfile.extract() to extract all the files from a large tar archive with lots of files tends to cause file fragmentation in Windows. Apparently NTFS cluster allocation interacts badly with such operations if Windows is not aware of the size of each file. The solution is to use a combination of the Win32 APIs SetFilePointer() and SetEndOfFile() before writing to the target file. This helps Windows choose a contiguous free space for the file. I tried it on the 2.6 trunk by calling file.truncate() (which seems to implement the appropriate calls on Windows) to set the file size before writing to a file. It helps to avoid fragmentation for the extracted files on my Windows XP x64 system. Can this be added to tarfile to improve its performance on Windows? -- >Comment By: Lars Gustäbel (gustaebel) Date: 2007-01-22 20:09 Message: Logged In: YES user_id=642936 Originator: NO Closed due to lack of interest, see discussion at #1587674. -- Comment By: Enoch Julias (enochjul) Date: 2006-10-31 06:07 Message: Logged In: YES user_id=6071 I submitted patch #1587674 for this, though I am not sure if it is a good idea to use truncate() for such a purpose. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-29 09:55 Message: Logged In: YES user_id=849994 Can you try to come up with a patch? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1586414&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1446119 ] subprocess interpreted double quotation wrong on windows
Bugs item #1446119, was opened at 2006-03-09 05:26 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Windows Group: Python 2.4 >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: simon (simonhang) Assigned to: Peter Åstrand (astrand) Summary: subprocess interpreted double quotation wrong on windows Initial Comment: If we run below python command print subprocess.Popen([r'c:\test.bat', r'test"string:']).pid Actually c:\test.bat test\"string\" is executed. Module subprocess doesn't interpret double quotation mark right. Back slash shouldn't be added. I believe problem is in function subprocess.list2cmdline. -- >Comment By: Peter Åstrand (astrand) Date: 2007-01-22 20:12 Message: Logged In: YES user_id=344921 Originator: NO No response from reporter, we confirm to the MS documentation as far as I can tell. -- Comment By: Peter Åstrand (astrand) Date: 2006-07-10 22:12 Message: Logged In: YES user_id=344921 As far as I can tell, there's nothing wrong with subprocess.list2cmdline. Take a look at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vccelng/htm/progs_12.asp. There, you will find: ab"c which corresponds to: "ab\"c" In other words: a backslash should be added when converting from an argument to a string. Or do you intepret the MS web page differently? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1446119&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1358527 ] subprocess.py fails on Windows when there is no console
Bugs item #1358527, was opened at 2005-11-16 23:59 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Martin Blais (blais) Assigned to: Peter Åstrand (astrand) Summary: subprocess.py fails on Windows when there is no console Initial Comment: Under Windows XP, using Python 2.4.2, calling a subprocess from "subprocess.py" from a script that does not have a console, with stdin=None (the default) fails. Since there is a check for stdin=stdout=stderr=None that just returns, to exhibit this problem you need to at least set stdout=PIPE (just to get it to run past the check for that special case). The problem is that in _get_handles(), l581-582: if stdin == None: p2cread = GetStdHandle(STD_INPUT_HANDLE) GetStdHandle returns None if there is no console. This is rather nasty bugger of a bug, since I suppose it breaks most GUI applications that start without the console (i.e. most) and that eventually invoke subprocesses and capture their output. I'm surprised to find this. To reproduce the problem, do this: 1. save the attached script to C:/temp/bug.py and C:/temp/bug.pyw 2. create two shortcuts on your desktop to invoke those scripts 3. open a shell and tail C:/temp/out.log For bug.py, the log file should display: 2005-11-16 17:38:11,661 INFO 0 For bug.pyw (no console), the log file should show the following exception: 2005-11-16 17:38:13,084 ERROR Traceback (most recent call last): File "C:\Temp\bug.pyw", line 20, in ? out = call(['C:/Cygwin/bin/ls.exe'], stdout=PIPE) #, stderr=PIPE) File "C:\Python24\lib\subprocess.py", line 412, in call return Popen(*args, **kwargs).wait() File "C:\Python24\lib\subprocess.py", line 533, in __init__ (p2cread, p2cwrite, File "C:\Python24\lib\subprocess.py", line 593, in _get_handles p2cread = self._make_inheritable(p2cread) File "C:\Python24\lib\subprocess.py", line 634, in _make_inheritable DUPLICATE_SAME_ACCESS) TypeError: an integer is required This is the bug. Note: in this test program, I'm invoking Cygwin's ls.exe. Feel free to change it -- >Comment By: Peter Åstrand (astrand) Date: 2007-01-22 20:27 Message: Logged In: YES user_id=344921 Originator: NO Duplicate of 1124861. -- Comment By: Martin Blais (blais) Date: 2005-11-17 14:41 Message: Logged In: YES user_id=10996 Here is an example of a workaround: p = Popen(ps2pdf, stdin=PIPE, stdout=PIPE, stderr=PIPE, cwd=tempfile.gettempdir()) p.stdin.close() # FIXME: we need to specify and close stdin explicitly # because of a bug I found and reported in subprocess.py # when the program is launched without a console, see SF bug # tracker for the Python project for details. When the bug # gets fixed we should be able to remove this. Basically I just specify stdin=PIPE and close it by hand. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1358527&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124861 ] subprocess fails on GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 17:23
Message generated for change (Settings changed) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
>Summary: subprocess fails on GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
Comment By: craig (codecraig)
Date: 2006-10-13 17:54
Message:
Logged In: YES
user_id=1258995
On windows, this seems to work
from subprocess import *
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
in some cases (depending on what command you are
executing, a command prompt window may appear). Do not show
a window use this...
import win32con
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE,
creationflags=win32con.CREATE_NO_WINDOW)
...google for Microsoft Process Creation Flags for more info
--
Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 16:53
Message:
Logged In: YES
user_id=945502
This issue was discussed on comp.lang.python[1] and Roger
Upole suggested:
"""
Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0. _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error. Pywin32 just returns the 0, so the process gets
one step further but still hits the above error.
Subprocess.py should probably check the
result of GetStdHandle for None (or 0)
and throw a readable error that says something like
"No standard handle available, you must specify one"
"""
[1]http://mail.python.org/pipermail/python-list/2005-September/300744.html
--
Comment By: Steven Bethard (bediviere)
Date: 2005-08-13 22:37
Message:
Logged In: YES
user_id=945502
I ran into a similar problem in Ellogon (www.ellogon.org)
which interfaces with Python through tclpython
(http://jfontain.free.fr/tclpython.htm).
My current workaround is to always set all of stdin, stdout,
and stderr to subprocess.PIPE. I never use the stderr pipe,
but at least this keeps the broken GetStdHandle calls from
happening.
Looking at the code, I kinda think the fix should be::
if handle is None:
return handle
return DuplicateHandle(GetCurrentProcess(), ...
where if handle is None, it stays None. But I'm also
probably in over my head here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1603907 ] subprocess: error redirecting i/o from non-console process
Bugs item #1603907, was opened at 2006-11-27 18:20
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603907&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: Python 2.5
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Oren Tirosh (orenti)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess: error redirecting i/o from non-console process
Initial Comment:
In IDLE, PythonWin or other non-console interactive Python under Windows:
>>> from subprocess import *
>>> Popen('cmd', stdout=PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
Popen('', stdout=PIPE)
File "C:\python24\lib\subprocess.py", line 533, in __init__
(p2cread, p2cwrite,
File "C:\python24\lib\subprocess.py", line 593, in _get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\python24\lib\subprocess.py", line 634, in _make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The same command in a console windows is successful.
Why it happens:
subprocess assumes that GetStdHandle always succeeds but when there is no
console it returns None. DuplicateHandle then complains about getting a
non-integer. This problem does not happen when redirecting all three standard
handles.
Solution:
Replace None with -1 (INVALID_HANDLE_VALUE) in _make_inheritable.
Patch attached.
--
>Comment By: Peter Åstrand (astrand)
Date: 2007-01-22 20:29
Message:
Logged In: YES
user_id=344921
Originator: NO
Duplicate of 1124861.
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-21 16:31
Message:
Logged In: YES
user_id=344921
Originator: NO
This the suggested patches are not ready for commit, I'm moving this issue
to "bugs" instead.
--
Comment By: Oren Tirosh (orenti)
Date: 2007-01-07 19:13
Message:
Logged In: YES
user_id=562624
Originator: YES
Oops. The new patch does not solve it in all cases in the win32api
version, either...
--
Comment By: Oren Tirosh (orenti)
Date: 2007-01-07 19:09
Message:
Logged In: YES
user_id=562624
Originator: YES
If you duplicate INVALID_HANDLE_VALUE you get a new valid handle to
nothing :-) I guess the code really should not rely on this undocumented
behavior. The reason I didn't return INVALID_HANDLE_VALUE directly is
because DuplicateHandle returns a _subprocess_handle object, not an int.
It's expected to have a .Close() method elsewhere in the code.
Because of subtle difference between in the behavior of the _subprocess
and win32api implementations of GetStdHandle in this case solving this
issue this gets quite messy!
File Added: subprocess-noconsole2.patch
--
Comment By: Peter Åstrand (astrand)
Date: 2007-01-07 11:58
Message:
Logged In: YES
user_id=344921
Originator: NO
This patch looks very interesting. However, it feels a little bit strange
to call DuplicateHandle with a handle of -1. Is this really allowed? What
will DuplicateHandle return in this case? INVALID_HANDLE_VALUE? In that
case, isn't it better to return INVALID_HANDLE_VALUE directly?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1603907&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1126208 ] subprocess.py Errors with IDLE
Bugs item #1126208, was opened at 2005-02-17 21:33
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Library
Group: None
>Status: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Kurt B. Kaiser (kbk)
Assigned to: Peter Åstrand (astrand)
Summary: subprocess.py Errors with IDLE
Initial Comment:
=
From: David S. alumni.tufts.edu>
Subject: subprocess problem on Windows in IDLE and PythonWin
Newsgroups: gmane.comp.python.general
Date: Wed, 16 Feb 2005 02:05:24 +
Python 2.4 on Windows XP
In the python command-line the following works fine:
>>> from subprocess import *
>>> p = Popen('dir', stdout=PIPE)
>From within IDLE or PythonWin I get the following exception:
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = Popen('dir', stdout=PIPE)
File "c:\python24\lib\subprocess.py", line 545, in __init__
(p2cread, p2cwrite,
File "c:\python24\lib\subprocess.py", line 605, in _get_handles
p2cread = self._make_inheritable(p2cread)
File "c:\python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
Note it works fine on Linux also. I tested it with
>>> p = Popen('ls', stdout=PIPE)
... and had no trouble.
===
I (KBK) can duplicate this on W2K using 2.4. If I run IDLE with the -n
switch (no subprocess) the error doesn't occur.
Unfortunately, I can't debug it because I don't have the necessary
tools on Windows. It appears that the problem is in
_subprocess.c:sp_DuplicateHandle(), likely that PyArg_ParseTuple()
is OK but the failure occurs in the call to DuplicateHandle().
All the args to sp_DuplicateHandle() seem to be the right type.
DUPLICATE_SAME_ACCESS is an integer, value 2
To find out what's going on, it would seem necessary to attach a
windows debugger to IDLE's subprocess (not the IDLE GUI). Let
me know if I can help.
--
>Comment By: Peter Åstrand (astrand)
Date: 2007-01-22 20:30
Message:
Logged In: YES
user_id=344921
Originator: NO
Duplicate of 1124861.
--
Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 16:51
Message:
Logged In: YES
user_id=945502
I believe this is related to 1124861 (if it's not a
duplicate of it)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1126208&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1543469 ] test_subprocess fails on cygwin
Bugs item #1543469, was opened at 2006-08-20 15:22 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Installation Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Miki Tebeka (tebeka) Assigned to: Nobody/Anonymous (nobody) Summary: test_subprocess fails on cygwin Initial Comment: This is RC1. test_subprocess fails. IMO due to the fact that there is a directory called "Python" in the python source directory. The fix should be that sys.executable will return the name with the '.exe' suffix on cygwin. Attached log of running the test. -- >Comment By: Peter Åstrand (astrand) Date: 2007-01-22 20:32 Message: Logged In: YES user_id=344921 Originator: NO Since this is not a subprocess bug per se, I'm letting someone else take care of this one. -- Comment By: Nobody/Anonymous (nobody) Date: 2006-08-21 10:07 Message: Logged In: NO Attached a patch, test_subprocess now passes. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-08-21 04:15 Message: Logged In: YES user_id=33168 Cygwin recently changed their behaviour. I have an outstanding hack to fix this. Patches would help get things fixed up. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1543469&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1238747 ] subprocess.Popen fails inside a Windows service
Bugs item #1238747, was opened at 2005-07-15 10:31 Message generated for change (Comment added) made by astrand You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Platform-specific >Status: Closed >Resolution: Duplicate Priority: 5 Private: No Submitted By: Adam Kerrison (adamk550) Assigned to: Peter Åstrand (astrand) Summary: subprocess.Popen fails inside a Windows service Initial Comment: If you use subprocess.Popen() from within a Windows service and you try to redirect stdout or stderr, the call will fail with a TypeError. The issue appears to be that if you attempt to redirect stdout and/or stderr, the module also needs to set up stdin. Since you haven't specified what to do with stdin, the code simple duplicates the processes stdin handle using GetStdHandle(STD_INPUT_HANDLE) However, a Windows service doesn't have stdin etc so the returned handle is None. This handle is then passed to DuplicateHandle() which fails with the TypeError. A workaround is to explictly PIPE stdin but I have found at least one Windows program (the RCMD.EXE utility) that fails if its stdin is a pipe! (RCMD says "Internal Error 109" ...) The only other workaround is a to explictly open the NUL device and use that for stdin. -- >Comment By: Peter Åstrand (astrand) Date: 2007-01-22 20:33 Message: Logged In: YES user_id=344921 Originator: NO Duplicate of 1124861. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1238747&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1637167 ] mailbox.py uses old email names
Bugs item #1637167, was opened at 2007-01-16 17:19 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Russell Owen (reowen) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox.py uses old email names Initial Comment: mailbox.py uses old (and presumably deprecated) names for stuff in the email package. This can confuse application packagers such as py2app. I believe the complete list of desirable changes is: email.Generator -> email.generator email.Message -> email.message email.message_from_string -> email.parser.message_from_string email.message_from_file -> email.parser.message_from_file I submitted patches for urllib, urllib2 and smptlib but wasn't sure enough of mailbox to do that. Those four modules are the only instances I found that needed changing at the main level of the library. However, I did not do a recursive search. There may be files inside packages that could also use cleanup. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 14:34 Message: Logged In: YES user_id=11375 Originator: NO Barry, are the suggested name changes for the email module correct? If yes, please assign this bug back to me and I'll make the changes to the mailbox module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1124861 ] subprocess fails on GetStdHandle in interactive GUI
Bugs item #1124861, was opened at 2005-02-17 17:23
Message generated for change (Comment added) made by astrand
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Windows
Group: Python 2.4
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: davids (davidschein)
Assigned to: Nobody/Anonymous (nobody)
Summary: subprocess fails on GetStdHandle in interactive GUI
Initial Comment:
Using the suprocess module from with IDLE or PyWindows,
it appears that calls GetStdHandle (STD__HANDLE)
returns None, which causes an error. (All appears fine
on Linux, the standard Python command-line, and ipython.)
For example:
>>> import subprocess
>>> p = subprocess.Popen("dir", stdout=subprocess.PIPE)
Traceback (most recent call last):
File "", line 1, in -toplevel-
p = subprocess.Popen("dir", stdout=subprocess.PIPE)
File "C:\Python24\lib\subprocess.py", line 545, in
__init__
(p2cread, p2cwrite,
File "C:\Python24\lib\subprocess.py", line 605, in
_get_handles
p2cread = self._make_inheritable(p2cread)
File "C:\Python24\lib\subprocess.py", line 646, in
_make_inheritable
DUPLICATE_SAME_ACCESS)
TypeError: an integer is required
The error originates in the mswindows implementation of
_get_handles. You need to set one of stdin, stdout, or
strerr because the first line in the method is:
if stdin == None and stdout == None and stderr == None:
...return (None, None, None, None, None, None)
I added "if not handle: return GetCurrentProcess()" to
_make_inheritable() as below and it worked. Of course,
I really do not know what is going on, so I am letting
go now...
def _make_inheritable(self, handle):
..."""Return a duplicate of handle, which is inheritable"""
...if not handle: return GetCurrentProcess()
...return DuplicateHandle(GetCurrentProcess(), handle,
GetCurrentProcess(),
0, 1,
DUPLICATE_SAME_ACCESS)
--
>Comment By: Peter Åstrand (astrand)
Date: 2007-01-22 20:36
Message:
Logged In: YES
user_id=344921
Originator: NO
The following bugs have been marked as duplicate of this bug:
1358527
1603907
1126208
1238747
--
Comment By: craig (codecraig)
Date: 2006-10-13 17:54
Message:
Logged In: YES
user_id=1258995
On windows, this seems to work
from subprocess import *
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE)
in some cases (depending on what command you are
executing, a command prompt window may appear). Do not show
a window use this...
import win32con
p = Popen(cmd, stdin=PIPE, stdout=PIPE, stderr=PIPE,
creationflags=win32con.CREATE_NO_WINDOW)
...google for Microsoft Process Creation Flags for more info
--
Comment By: Steven Bethard (bediviere)
Date: 2005-09-26 16:53
Message:
Logged In: YES
user_id=945502
This issue was discussed on comp.lang.python[1] and Roger
Upole suggested:
"""
Basically, gui apps like VS don't have a console, so
GetStdHandle returns 0. _subprocess.GetStdHandle
returns None if the handle is 0, which gives the original
error. Pywin32 just returns the 0, so the process gets
one step further but still hits the above error.
Subprocess.py should probably check the
result of GetStdHandle for None (or 0)
and throw a readable error that says something like
"No standard handle available, you must specify one"
"""
[1]http://mail.python.org/pipermail/python-list/2005-September/300744.html
--
Comment By: Steven Bethard (bediviere)
Date: 2005-08-13 22:37
Message:
Logged In: YES
user_id=945502
I ran into a similar problem in Ellogon (www.ellogon.org)
which interfaces with Python through tclpython
(http://jfontain.free.fr/tclpython.htm).
My current workaround is to always set all of stdin, stdout,
and stderr to subprocess.PIPE. I never use the stderr pipe,
but at least this keeps the broken GetStdHandle calls from
happening.
Looking at the code, I kinda think the fix should be::
if handle is None:
return handle
return DuplicateHandle(GetCurrentProcess(), ...
where if handle is None, it stays None. But I'm also
probably in over my head here.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1124861&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1599254 ] mailbox: other programs' messages can vanish without trace
Bugs item #1599254, was opened at 2006-11-19 16:03 Message generated for change (Comment added) made by baikie You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1599254&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 Status: Open Resolution: None Priority: 7 Private: No Submitted By: David Watson (baikie) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox: other programs' messages can vanish without trace Initial Comment: The mailbox classes based on _singlefileMailbox (mbox, MMDF, Babyl) implement the flush() method by writing the new mailbox contents into a temporary file which is then renamed over the original. Unfortunately, if another program tries to deliver messages while mailbox.py is working, and uses only fcntl() locking, it will have the old file open and be blocked waiting for the lock to become available. Once mailbox.py has replaced the old file and closed it, making the lock available, the other program will write its messages into the now-deleted "old" file, consigning them to oblivion. I've caused Postfix on Linux to lose mail this way (although I did have to turn off its use of dot-locking to do so). A possible fix is attached. Instead of new_file being renamed, its contents are copied back to the original file. If file.truncate() is available, the mailbox is then truncated to size. Otherwise, if truncation is required, it's truncated to zero length beforehand by reopening self._path with mode wb+. In the latter case, there's a check to see if the mailbox was replaced while we weren't looking, but there's still a race condition. Any alternative ideas? Incidentally, this fixes a problem whereby Postfix wouldn't deliver to the replacement file as it had the execute bit set. -- >Comment By: David Watson (baikie) Date: 2007-01-22 20:24 Message: Logged In: YES user_id=1504904 Originator: YES So what you propose to commit for 2.5 is basically mailbox-unified2 (your mailbox-unified-patch, minus the _toc clearing)? -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 15:46 Message: Logged In: YES user_id=11375 Originator: NO This would be an API change, and therefore out-of-bounds for 2.5. I suggest giving up on this for 2.5.1 and only fixing it in 2.6. I'll add another warning to the docs, and maybe to the module as well. -- Comment By: David Watson (baikie) Date: 2007-01-21 22:10 Message: Logged In: YES user_id=1504904 Originator: YES Hold on, I have a plan. If _toc is only regenerated on locking, or at the end of a flush(), then the only way self._pending can be set at that time is if the application has made modifications before calling lock(). If we make that an exception-raising offence, then we can assume that self._toc is a faithful representation of the last known contents of the file. That means we can preserve the existing message keys on a reread without any of that _user_toc nonsense. Diff attached, to apply on top of mailbox-unified2. It's probably had even less review and testing than the previous version, but it appears to pass all the regression tests and doesn't change any existing semantics. File Added: mailbox-update-toc-new.diff -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-21 03:16 Message: Logged In: YES user_id=11375 Originator: NO I'm starting to lose track of all the variations on the bug. Maybe we should just add more warnings to the documentation about locking the mailbox when modifying it and not try to fix this at all. -- Comment By: David Watson (baikie) Date: 2007-01-20 18:20 Message: Logged In: YES user_id=1504904 Originator: YES Hang on. If a message's key changes after recreating _toc, that does not mean that another process has modified the mailbox. If the application removes a message and then (inadvertently) causes _toc to be regenerated, the keys of all subsequent messages will be decremented by one, due only to the application's own actions. That's what happens in the "broken locking" test case: the program intends to remove message 0, flush, and then remove message 1, but because _toc is regenerated in between, message 1 is renumbered as 0, message 2 is renumbered as 1, and so the program deletes message 2 instead. To clear _toc in such code without attempting to preserve the message keys turns possible data loss (in the case that another process modified the mailbox) into certain data loss. That's what I'm concerned about.
[ python-Bugs-1637167 ] mailbox.py uses old email names
Bugs item #1637167, was opened at 2007-01-16 22:19 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637167&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Russell Owen (reowen) Assigned to: Barry A. Warsaw (bwarsaw) Summary: mailbox.py uses old email names Initial Comment: mailbox.py uses old (and presumably deprecated) names for stuff in the email package. This can confuse application packagers such as py2app. I believe the complete list of desirable changes is: email.Generator -> email.generator email.Message -> email.message email.message_from_string -> email.parser.message_from_string email.message_from_file -> email.parser.message_from_file I submitted patches for urllib, urllib2 and smptlib but wasn't sure enough of mailbox to do that. Those four modules are the only instances I found that needed changing at the main level of the library. However, I did not do a recursive search. There may be files inside packages that could also use cleanup. -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-22 20:34 Message: Logged In: YES user_id=849994 Originator: NO FWIW, the last two are incorrect. I already fixed that while doing the other three patches. There shouldn't be any occurences of old style package name imports left. -- Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 19:34 Message: Logged In: YES user_id=11375 Originator: NO Barry, are the suggested name changes for the email module correct? If yes, please assign this bug back to me and I'll make the changes to the mailbox module. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1637167&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1633678 ] mailbox.py _fromlinepattern regexp does not support positive
Bugs item #1633678, was opened at 2007-01-11 20:14 Message generated for change (Comment added) made by akuchling You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633678&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Matthias Klose (doko) Assigned to: A.M. Kuchling (akuchling) Summary: mailbox.py _fromlinepattern regexp does not support positive Initial Comment: [forwarded from http://bugs.debian.org/254757] mailbox.py _fromlinepattern regexp does not support positive GMT offsets. the pattern didn't change in 2.5. bug submitter writes: archivemail incorrectly splits up messages in my mbox-format mail archvies. I use Squirrelmail, which seems to create mbox lines that look like this: >From [EMAIL PROTECTED] Mon Jan 26 12:29:24 2004 -0400 The "-0400" appears to be throwing it off. If the first message of an mbox file has such a line on it, archivemail flat out stops, saying the file is not mbox. If the later messages in an mbox file are in this style, they are not counted, and archivemail thinks that the preceding message is just kind of long, and the decision to archive or not is broken. I have stumbled on this bug when I wanted to archive my mails on a Sarge system. And since my TZ is positive, the regexp did not work. I think the correct regexp for /usr/lib/python2.3/mailbox.py should be: _fromlinepattern = r"From \s*[^\s]+\s+\w\w\w\s+\w\w\w\s+\d?\d\s+" \ r"\d?\d:\d\d(:\d\d)?(\s+[^\s]+)?\s+\d\d\d\d\s*((\+|-)\d\d\d\d)?\s*$" This should handle positive and negative timezones in From lines. I have tested it successfully with an email beginning with this line: >From [EMAIL PROTECTED] Mon May 31 13:24:50 2004 +0200 as well as one withouth TZ reference. -- >Comment By: A.M. Kuchling (akuchling) Date: 2007-01-22 15:55 Message: Logged In: YES user_id=11375 Originator: NO According to qmail's description of the mbox format (http://www.qmail.org/qmail-manual-html/man5/mbox.html), the 'from' lines shouldn't contain timezone info, but may contain additional information after the date. So I think a better change is just to add [^\s]*\s* to the end of the pattern. Note that the docs recommend the PortableUnixMailbox class as preferable for just this reason: there's too much variation in from lines to make the strict parsing useful. Change committed to trunk in rev. 53519, and to release25-maint in rev. 53521. Thanks for your report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1633678&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1249573 ] rfc822 module, bug in parsedate_tz
Bugs item #1249573, was opened at 2005-08-01 13:56
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249573&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Extension Modules
Group: Python 2.4
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: nemesis (nemesis_xpn)
Assigned to: Nobody/Anonymous (nobody)
Summary: rfc822 module, bug in parsedate_tz
Initial Comment:
I found that the function parsedate_tz of the rfc822
module has a bug (or at least I think so).
I found a usenet article (message-id:
<[EMAIL PROTECTED]>)
that has this Date field:
Date: Tue,26 Jul 2005 13:14:27 GMT +0200
It seems to be correct�, but parsedate_tz is not able
to decode it, it
is confused by the absence of a space after the ",".
I studied the parsedate_tz code and the problem is on
its third line:
...
if not data:
return None
data = data.split()
...
After the split I have:
['Tue,26', 'Jul', '2005', '13:14:27', 'GMT', '+0200']
but "Tue," and "26" should be separated.
Of course parsedate_tz correctly decode the field if
you add a space after the ",".
A possible solution is to change the line n�863 of
rfc822.py (data=data.split()) with this one:
data=data.replace(",",", ").split()
it solves the problem and should not affect the normal
behaviour.
� and looking at rfc2822 par3.3 it should be correct,
the space after
the comma is not mandatory:
date-time = [ day-of-week "," ] date FWS
time [CFWS]
day-of-week = ([FWS] day-name) / obs-day-of-week
day-name= "Mon" / "Tue" / "Wed" / "Thu" /
"Fri" / "Sat" / "Sun"
date= day month year
--
>Comment By: Georg Brandl (gbrandl)
Date: 2007-01-22 21:10
Message:
Logged In: YES
user_id=849994
Originator: NO
Fixed in rev. 53522, 53523 (2.5).
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1249573&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-975330 ] Inconsistent newline handling in email module
Bugs item #975330, was opened at 2004-06-18 12:50 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975330&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Anders Hammarquist (iko) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: Inconsistent newline handling in email module Initial Comment: text/* parts of email messages must use \r\n as the newline separator. For unencoded messages. smtplib and friends take care of the translation from \n to \r\n in the SMTP processing. Parts which are unencoded (i.e. 7bit character sets) MUST use \n line endings, or smtplib with translate to \r\r\n. Parts that get encoded using quoted-printable can use either, because the qp-encoder assumes input data is text and reencodes with \n. However, parts which get encoded using base64 are NOT translated, and so must use \r\n line endings. This means you have to guess whether your text is going to get encoded or not (admittedly, usually not that hard), and translate the line endings appropriately before generating a Message instance. I think the fix would be for Charset.encode_body() to alway force the encoder to text mode (i.e.binary=False), since it seems unlikely to have a Charset for something which is not text. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=975330&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1627316 ] an extra comma in condition command crashes pdb
Bugs item #1627316, was opened at 2007-01-03 20:26 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627316&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Ilya Sandler (isandler) Assigned to: Nobody/Anonymous (nobody) Summary: an extra comma in condition command crashes pdb Initial Comment: if instead of condition one enters (note the extra comma): condition , pdb throws an exception and aborts execution of a program Relevant parts of stacktrace: File "/usr/lib/python2.4/bdb.py", line 48, in trace_dispatch return self.dispatch_line(frame) File "/usr/lib/python2.4/bdb.py", line 66, in dispatch_line self.user_line(frame) File "/usr/lib/python2.4/pdb.py", line 135, in user_line self.interaction(frame, None) File "/usr/lib/python2.4/pdb.py", line 158, in interaction self.cmdloop() File "/usr/lib/python2.4/cmd.py", line 142, in cmdloop stop = self.onecmd(line) File "/usr/lib/python2.4/cmd.py", line 219, in onecmd return func(arg) File "/usr/lib/python2.4/pdb.py", line 390, in do_condition bpnum = int(args[0].strip()) ValueError: invalid literal for int(): 2, Uncaught exception. Entering post mortem debugging Running 'cont' or 'step' will restart the program > /site/tools/pse/lib/python2.4/pdb.py(390)do_condition() -> bpnum = int(args[0].strip()) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-22 21:24 Message: Logged In: YES user_id=849994 Originator: NO Fixed in rev. 53524, 53525 (2.5). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1627316&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1642054 ] Python 2.5 gets curses.h warning on HPUX
Bugs item #1642054, was opened at 2007-01-22 19:27 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Build Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Roy Smith (roysmith) Assigned to: Nobody/Anonymous (nobody) Summary: Python 2.5 gets curses.h warning on HPUX Initial Comment: I downloaded http://www.python.org/ftp/python/2.5/Python-2.5.tgz and tried to build it on "HP-UX glade B.11.11 U 9000/800 unknown". When I ran "./configure", I got warnings that "curses.h: present but cannot be compiled". See attached log file. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1642054&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-411881 ] Use of "except:" in logging module
Bugs item #411881, was opened at 2001-03-28 04:58 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=411881&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Library Group: None >Status: Closed Resolution: Fixed Priority: 2 Private: No Submitted By: Itamar Shtull-Trauring (itamar) Assigned to: Vinay Sajip (vsajip) Summary: Use of "except:" in logging module Initial Comment: A large amount of modules in the standard library use "except:" instead of specifying the exceptions to be caught. In some cases this may be correct, but I think in most cases this not true and this may cause problems. Here's the list of modules, which I got by doing: grep "except:" *.py | cut -f 1 -d " " | sort | uniq Bastion.py CGIHTTPServer.py Cookie.py SocketServer.py anydbm.py asyncore.py bdb.py cgi.py chunk.py cmd.py code.py compileall.py doctest.py fileinput.py formatter.py getpass.py htmllib.py imaplib.py inspect.py locale.py locale.py mailcap.py mhlib.py mimetools.py mimify.py os.py pdb.py popen2.py posixfile.py pre.py pstats.py pty.py pyclbr.py pydoc.py repr.py rexec.py rfc822.py shelve.py shutil.py tempfile.py threading.py traceback.py types.py unittest.py urllib.py zipfile.py -- >Comment By: SourceForge Robot (sf-robot) Date: 2007-01-22 19:20 Message: Logged In: YES user_id=1312539 Originator: NO This Tracker item was closed automatically by the system. It was previously set to a Pending status, and the original submitter did not respond within 14 days (the time period specified by the administrator of this Tracker). -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 10:55 Message: Logged In: YES user_id=308438 Originator: NO The following changes have been checked into trunk: logging.handlers: bare except clause removed from SMTPHandler.emit. Now, only ImportError is trapped. logging.handlers: bare except clause removed from SocketHandler.createSocket. Now, only socket.error is trapped. logging: bare except clause removed from LogRecord.__init__. Now, only ValueError, TypeError and AttributeError are trapped. I'm marking this as Pending; please submit a change if you think these changes are insufficient. With the default setting of raiseExceptions, all exceptions caused by programmer error should be re-thrown by logging. -- Comment By: Skip Montanaro (montanaro) Date: 2006-12-22 04:52 Message: Logged In: YES user_id=44345 Originator: NO Vinay, In LogRecord.__init__ what exceptions do you expect to catch? Looking at the code for basename and splitext in os.py it's pretty hard to see how they would raise an exception unless they were passed something besides string or unicode objects. I think all you are doing here is masking programmer error. In StreamHandler.emit what might you get besides ValueError (if self.stream is closed)? I don't have time to go through each of the cases, but in general, it seems like the set of possible exceptions that could be raised at any given point in the code is generally pretty small. You should catch those exceptions and let the other stuff go. They are generally going to be programmer's errors and shouldn't be silently squashed. Skip -- Comment By: Vinay Sajip (vsajip) Date: 2006-12-21 23:42 Message: Logged In: YES user_id=308438 Originator: NO The reason for the fair number of bare excepts in logging is this: in many cases (e.g. long-running processes like Zope servers) users don't want their application to change behaviour just because of some exception thrown in logging. So, logging aims to be very quiet indeed and swallows exceptions, except SystemExit and KeyboardInterrupt in certain situations. Also, logging is one of the modules which is (meant to be) 1.5.2 compatible, and string exceptions are not that uncommon in older code. I've looked at bare excepts in logging and here's my summary on them: logging/__init__.py: currentframe(): Backward compatibility only, sys._getframe is used where available so currentframe() will only be called on rare occasions. LogRecord.__init__(): There's a try/bare except around calls to os.path.basename() and os.path.splitext(). I could add a raise clause for SystemExit/KeyboardInterrupt. StreamHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). shutdown(): Normally only called at system exit, and will re-raise everything if raiseExceptions is set (the default). logging/
[ python-Bugs-1483133 ] gen_iternext: Assertion `f->f_back != ((void *)0)' failed
Bugs item #1483133, was opened at 2006-05-06 14:09 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: svensoho (svensoho) Assigned to: Phillip J. Eby (pje) Summary: gen_iternext: Assertion `f->f_back != ((void *)0)' failed Initial Comment: Seems to be similar bug as http://sourceforge.net/ tracker/index.php? func=detail&aid=1257960&group_id=5470&atid=105470 (fixed) Couldn't trigger with same script but with C application. Same source modification helps (at Objects/genobject.c:53) -- >Comment By: Neal Norwitz (nnorwitz) Date: 2007-01-22 20:45 Message: Logged In: YES user_id=33168 Originator: NO I agree with Martin. This is fixed in 2.5, but since we are no longer maintaining 2.4, it will not be fixed there. -- Comment By: Martin v. Löwis (loewis) Date: 2007-01-22 00:06 Message: Logged In: YES user_id=21627 Originator: NO Python 2.4 is not actively maintained anymore. As this occurs in the debug build only, I recommend closing it as "won't fix". Just lowering the priority for now (svensoho, please don't change priorities). -- Comment By: svensoho (svensoho) Date: 2006-06-30 00:35 Message: Logged In: YES user_id=1518209 2.5 is already fixed: http://sourceforge.net/tracker/ index.php?func=detail&aid=1257960&group_id=5470&atid=105470 2.4 has exactly same problematic assertion, even same modification helps. Fedora has fixed it in their distribution: https://bugzilla.redhat.com/bugzilla/ show_bug.cgi?id=192592 -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-06-30 00:14 Message: Logged In: YES user_id=33168 Does this affect 2.5 or only 2.4? There were a fair amount of generator changes in 2.5. -- Comment By: svensoho (svensoho) Date: 2006-05-26 07:42 Message: Logged In: YES user_id=1518209 This bug is blocking development of PostgreSQL Python based stored procedure language -- PL/Python. See http://archives.postgresql.org/pgsql-patches/2006-04/msg 00265.php -- Comment By: svensoho (svensoho) Date: 2006-05-15 01:26 Message: Logged In: YES user_id=1518209 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1483133&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1560179 ] Better/faster implementation of os.path.basename/dirname
Bugs item #1560179, was opened at 2006-09-17 16:55
Message generated for change (Comment added) made by pylucid
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Accepted
Priority: 5
Private: No
Submitted By: Michael Gebetsroither (einsteinmg)
Assigned to: Nobody/Anonymous (nobody)
Summary: Better/faster implementation of os.path.basename/dirname
Initial Comment:
hi,
basename/dirname could do better (especially on long
pathnames)
def basename(p):
return split(p)[1]
def dirname(p):
return split(p)[0]
both construct base and dirname and discard the unused
one.
what about that?
def basename(p):
i = p.rfind('/') + 1
return p[i:]
def dirname(p):
i = p.rfind('/') + 1
return p[:i]
greets,
michael
--
Comment By: Jens Diemer (pylucid)
Date: 2007-01-23 07:21
Message:
Logged In: YES
user_id=1330780
Originator: NO
A faster implementation is ok...
But why only posixpath patched? Why not ntpath and macpath updated, too?
--
Comment By: Josiah Carlson (josiahcarlson)
Date: 2006-10-17 00:23
Message:
Logged In: YES
user_id=341410
I note that in the current SVN, dirname uses a test of "if
head and head != '/'*len(head):" to check for the path being
all /, could be replaced by "if head and head.count('/') !=
len(head):", but it probably isn't terribly important.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-10-12 15:08
Message:
Logged In: YES
user_id=849994
Committed in rev. 52316.
--
Comment By: Michael Gebetsroither (einsteinmg)
Date: 2006-09-18 14:42
Message:
Logged In: YES
user_id=1600082
posixpath with this patch passes all test from
test_posixpath cleanly.
benchmark:
basename( 310 ) means basename called with a 310 chars long
path
sum = 0.0435626506805 min = 4.19616699219e-05
posixpath.basename( 310 )
sum = 0.152147769928 min = 0.00014591217041
posixpath_orig.basename( 310 )
sum = 0.0436658859253 min = 4.07695770264e-05
posixpath.basename( 106 )
sum = 0.117312431335 min = 0.000112771987915
posixpath_orig.basename( 106 )
sum = 0.0426909923553 min = 4.07695770264e-05
posixpath.basename( 21 )
sum = 0.113305330276 min = 0.000110864639282
posixpath_orig.basename( 21 )
sum = 0.12392115593 min = 0.000121831893921
posixpath.dirname( 310 )
sum = 0.152860403061 min = 0.00014591217041
posixpath_orig.dirname( 310 )
sum = 0.0942873954773 min = 9.08374786377e-05
posixpath.dirname( 106 )
sum = 0.114937067032 min = 0.000111818313599
posixpath_orig.dirname( 106 )
sum = 0.0918889045715 min = 8.79764556885e-05
posixpath.dirname( 21 )
sum = 0.114675760269 min = 0.000109910964966
posixpath_orig.dirname( 21 )
greets
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1560179&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
