[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 23:10 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Neal Norwitz (nnorwitz) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 10:13 Message: Logged In: YES user_id=308438 Originator: NO Done. I'm not sure what you're getting at with those revision numbers - trunk and branches/release25-maint are now up to date; if you think other branches need to be updated, please name those branches explicitly. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-08 02:19 Message: Logged In: YES user_id=1611720 Originator: YES This fix should be back-ported to 2.5 maint: r52100,52101,52102 perhaps also r52555,52556? -- Comment By: Vinay Sajip (vsajip) Date: 2006-10-03 18:22 Message: Logged In: YES user_id=308438 Documentation now updated in CVS. Also changed the added "func" parameter to have a default value of None. Sorry for the inconvenience caused. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-03 17:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-03 06:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Bugs item #889153, was opened at 2004-02-02 19:04 Message generated for change (Comment added) made by klimkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Sankov Dmitry Alexandrovich (sankov_da) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.dispactcher: incorrect connect Initial Comment: When i use non-blocking socket, connect() method of asyncore.dispatcher class looks like works incorrect. Example: if connection have not established then socket merely closed and handle_error not called and no exception throwed. One more example: if writable() and readble() methods returns zero than handle_connect() will never be called even if connection will be established. Thanks. -- Comment By: Alexey Klimkin (klimkin) Date: 2007-01-08 13:37 Message: Logged In: YES user_id=410460 Originator: NO It's about _non-blocking_ socket. Socket has been created and connect called. However, for non-blocking socket connect returns immediately. The patch allows to use connect in non-blocking manner. I don't see any reason of limiting socket to be connected in blocking manner. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-07 02:05 Message: Logged In: YES user_id=341410 Originator: NO It sounds as though the original poster is passing a socket that has been created, but which is not yet connected, to the dispatcher constructor. We should update the documentation to state that either the user should pass a completely connected socket (as returned by socket.accept(), or which has connected as the result of a a blocking socket.connect() call), or use the .create_socket() and .connect() methods of the dispatcher. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 11:22 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630511 ] doc error for re.sub
Bugs item #1630511, was opened at 2007-01-08 12:05 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=1630511&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: Python 2.4 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: doc error for re.sub Initial Comment: http://www.python.org/doc/2.4.3/lib/node115.html says that repl in sub(pattern, repl, string[, count]) can be a function. This is fact does not work and this facility came in a later version. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630515 ] doc misleading in re.compile
Bugs item #1630515, was opened at 2007-01-08 12:09 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=1630515&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) Assigned to: Nobody/Anonymous (nobody) Summary: doc misleading in re.compile Initial Comment: http://www.python.org/doc/2.5/lib/node46.html has compile(pattern[, flags]) Compile a regular expression pattern into a regular expression object, which can be used for matching using its match() and search() methods, described below. This could be read as implying that the regular expression object can ONLY be used for matching using the match() and search() methods. In fact, I believe it can be used wherever "pattern" is mentioned. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630515&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Bugs item #889153, was opened at 2004-02-02 08:04 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Sankov Dmitry Alexandrovich (sankov_da) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.dispactcher: incorrect connect Initial Comment: When i use non-blocking socket, connect() method of asyncore.dispatcher class looks like works incorrect. Example: if connection have not established then socket merely closed and handle_error not called and no exception throwed. One more example: if writable() and readble() methods returns zero than handle_connect() will never be called even if connection will be established. Thanks. -- >Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-08 09:02 Message: Logged In: YES user_id=341410 Originator: NO According to my reading, the only change necessary to make the semantics equivalent for a non-blocking socket for which .connect() has been called is to change a portion of the dispatcher's __init__ method to: try: self.addr = sock.getpeername() except socket.error: # if we can't get the peer name, we haven't connected yet self.connected = False -- Comment By: Alexey Klimkin (klimkin) Date: 2007-01-08 02:37 Message: Logged In: YES user_id=410460 Originator: NO It's about _non-blocking_ socket. Socket has been created and connect called. However, for non-blocking socket connect returns immediately. The patch allows to use connect in non-blocking manner. I don't see any reason of limiting socket to be connected in blocking manner. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-06 15:05 Message: Logged In: YES user_id=341410 Originator: NO It sounds as though the original poster is passing a socket that has been created, but which is not yet connected, to the dispatcher constructor. We should update the documentation to state that either the user should pass a completely connected socket (as returned by socket.accept(), or which has connected as the result of a a blocking socket.connect() call), or use the .create_socket() and .connect() methods of the dispatcher. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 00:22 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630511 ] doc error for re.sub
Bugs item #1630511, was opened at 2007-01-08 12:05 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630511&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: Python 2.4 >Status: Closed >Resolution: Invalid Priority: 5 Private: No Submitted By: Keith Briggs (kbriggs) >Assigned to: Michael Hudson (mwh) Summary: doc error for re.sub Initial Comment: http://www.python.org/doc/2.4.3/lib/node115.html says that repl in sub(pattern, repl, string[, count]) can be a function. This is fact does not work and this facility came in a later version. -- >Comment By: Michael Hudson (mwh) Date: 2007-01-08 17:51 Message: Logged In: YES user_id=6656 Originator: NO Um, what? This has worked since at least 1.5.2, and probably before. Did you think you'd found the docs for 1.4? Closing. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630511&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630794 ] Seg fault in readline call.
Bugs item #1630794, was opened at 2007-01-08 10:02 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=1630794&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: Open Resolution: None Priority: 5 Private: No Submitted By: gnovak (gnovak) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in readline call. Initial Comment: GDL is a free implementation of the IDL programming language that can be built as a Python module to allow one to call IDL code from Python. http://gnudatalanguage.sourceforge.net/ When "enough" of readline has been activated, I get a seg fault with the backtrace listed below when trying to call any GDL code from Python. I've also reported the problem there. One way to initialize enough of readline is to use IPython (http://ipython.scipy.org), an enhanced interactive Python shell (this is how I found the bug). Another way is to follow the instructions from IPython's author (no IPython required) listed below. I am using: OS X 10.4.8 Python 2.4.2 (#1, Mar 22 2006, 21:27:43) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin GDL 0.9 pre 3 readline 5.0 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 16:10 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Neal Norwitz (nnorwitz) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Mike Klaas (mklaas) Date: 2007-01-08 10:07 Message: Logged In: YES user_id=1611720 Originator: YES Sorry - I was just trying to to see if the fix was backported, and I only saw the trunk checkins on python-checkins -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 02:13 Message: Logged In: YES user_id=308438 Originator: NO Done. I'm not sure what you're getting at with those revision numbers - trunk and branches/release25-maint are now up to date; if you think other branches need to be updated, please name those branches explicitly. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-07 18:19 Message: Logged In: YES user_id=1611720 Originator: YES This fix should be back-ported to 2.5 maint: r52100,52101,52102 perhaps also r52555,52556? -- Comment By: Vinay Sajip (vsajip) Date: 2006-10-03 11:22 Message: Logged In: YES user_id=308438 Documentation now updated in CVS. Also changed the added "func" parameter to have a default value of None. Sorry for the inconvenience caused. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-03 10:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-02 23:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 23:10 Message generated for change (Comment added) made by vsajip You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Neal Norwitz (nnorwitz) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 18:26 Message: Logged In: YES user_id=308438 Originator: NO No need to be sorry, you were absolutely right to re-open the issue for backports - I had not originally checked in the backport. What I meant in my last mail was that I have now checked in the backport, but wasn't sure about the specific revisions you were referring to. Thanks for the reminder about release25-maint. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-08 18:07 Message: Logged In: YES user_id=1611720 Originator: YES Sorry - I was just trying to to see if the fix was backported, and I only saw the trunk checkins on python-checkins -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 10:13 Message: Logged In: YES user_id=308438 Originator: NO Done. I'm not sure what you're getting at with those revision numbers - trunk and branches/release25-maint are now up to date; if you think other branches need to be updated, please name those branches explicitly. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-08 02:19 Message: Logged In: YES user_id=1611720 Originator: YES This fix should be back-ported to 2.5 maint: r52100,52101,52102 perhaps also r52555,52556? -- Comment By: Vinay Sajip (vsajip) Date: 2006-10-03 18:22 Message: Logged In: YES user_id=308438 Documentation now updated in CVS. Also changed the added "func" parameter to have a default value of None. Sorry for the inconvenience caused. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-03 17:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-03 06:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1569622 ] Backward incompatibility in logging.py
Bugs item #1569622, was opened at 2006-10-02 16:10 Message generated for change (Comment added) made by mklaas You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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: 9 Private: No Submitted By: Mike Klaas (mklaas) Assigned to: Neal Norwitz (nnorwitz) Summary: Backward incompatibility in logging.py Initial Comment: LogRecord.__init__ changed in a backward incompatible way in python 2.5 (added one parameter). There is no mention of this breakage in the release notes, nor has the documentation of the module been updated (http://docs.python.org/lib/node424.html) -- >Comment By: Mike Klaas (mklaas) Date: 2007-01-08 10:30 Message: Logged In: YES user_id=1611720 Originator: YES Ah... the revisions were simply the fix revisions (the last two were not directly related to this issue, but one was a documentation bug, and the other was a minor performance edit, so I thought those might also be backport candidates). -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 10:26 Message: Logged In: YES user_id=308438 Originator: NO No need to be sorry, you were absolutely right to re-open the issue for backports - I had not originally checked in the backport. What I meant in my last mail was that I have now checked in the backport, but wasn't sure about the specific revisions you were referring to. Thanks for the reminder about release25-maint. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-08 10:07 Message: Logged In: YES user_id=1611720 Originator: YES Sorry - I was just trying to to see if the fix was backported, and I only saw the trunk checkins on python-checkins -- Comment By: Vinay Sajip (vsajip) Date: 2007-01-08 02:13 Message: Logged In: YES user_id=308438 Originator: NO Done. I'm not sure what you're getting at with those revision numbers - trunk and branches/release25-maint are now up to date; if you think other branches need to be updated, please name those branches explicitly. -- Comment By: Mike Klaas (mklaas) Date: 2007-01-07 18:19 Message: Logged In: YES user_id=1611720 Originator: YES This fix should be back-ported to 2.5 maint: r52100,52101,52102 perhaps also r52555,52556? -- Comment By: Vinay Sajip (vsajip) Date: 2006-10-03 11:22 Message: Logged In: YES user_id=308438 Documentation now updated in CVS. Also changed the added "func" parameter to have a default value of None. Sorry for the inconvenience caused. -- Comment By: Mike Klaas (mklaas) Date: 2006-10-03 10:14 Message: Logged In: YES user_id=1611720 It is incompatible as code written for 2.4 will break in 2.5, and vice-versa (this is a required parameter, not an optional parameter, and the change could have been made in a backward-compatible way). You're right that the documentation fix is the important thing. -- Comment By: Georg Brandl (gbrandl) Date: 2006-10-02 23:11 Message: Logged In: YES user_id=849994 I don't see why adding one parameter is backwards incompatible, but it's true that the docs must be updated. Assigning to Vinay. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1569622&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 12:58 Message generated for change (Comment added) made by vsajip 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: Pending >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: Vinay Sajip (vsajip) Date: 2007-01-08 18: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 12: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-22 07: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/handlers.py: BaseRotatingHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything if raiseExceptions is set (the default). SocketHandler.createSocket(): I could add a raise clause for SystemExit/KeyboardInterrupt. SocketHandler.emit(): Reraises SystemExit and KeyboardInterrupt, and otherwise calls handleError() which raises everything
[ python-Bugs-1630844 ] fnmatch.translate undocumented
Bugs item #1630844, was opened at 2007-01-08 16:29 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=1630844&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: Python 2.5 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Gabriel Genellina (gagenellina) Assigned to: Nobody/Anonymous (nobody) Summary: fnmatch.translate undocumented Initial Comment: fnmatch.translate is not documented, but it is menctioned on the module docstring and in __all__, so it appears to be public. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630844&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1574217 ] isinstance swallows exceptions
Bugs item #1574217, was opened at 2006-10-09 21:55
Message generated for change (Settings changed) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Brian Harring (ferringb)
>Assigned to: Raymond Hettinger (rhettinger)
Summary: isinstance swallows exceptions
Initial Comment:
Attached is a simple example; yes, a bit contrived, but
it's exactly what bit me in the ass for a week or two :)
nestled within abstract.c's recursive_isinstance, is
this lil nugget-
icls = PyObject_GetAttr(inst, __class__);
if (icls == NULL) {
PyErr_Clear();
retval = 0;
}
else {
No surrouding comments to indicate *why* it's
swallowing exceptions, but best explanation I've heard
was that it was attempting to swallow just
AttributeError... which would make sense.
So the question is, whats the purpose of it swallowing
exceptions there? Bad form of AttributeError catching,
or some unstated reason?
--
Comment By: Brian Harring (ferringb)
Date: 2006-11-04 23:06
Message:
Logged In: YES
user_id=874085
quicky patch for this; basically, wipe the exception only if
it's AttributeError, else let it bubble it's way up.
--
Comment By: Brian Harring (ferringb)
Date: 2006-10-09 21:56
Message:
Logged In: YES
user_id=874085
addition note; this is both 2.5 and 2.4, probably stretches
bit further back also.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1574217&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630863 ] PyLong_AsLong doesn't check tp_as_number
Bugs item #1630863, was opened at 2007-01-08 15:06 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=1630863&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: Open Resolution: None Priority: 5 Private: No Submitted By: Roger Upole (rupole) Assigned to: Nobody/Anonymous (nobody) Summary: PyLong_AsLong doesn't check tp_as_number Initial Comment: Both PyInt_AsLong and PyLong_AsLongLong check if an object's type has PyNumberMethods defined. However, PyLong_AsLong does not, causing conversion to fail for objects which can legitimately be converted to a long. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630863&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630894 ] Garbage output to file of specific size
Bugs item #1630894, was opened at 2007-01-08 15:40
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=1630894&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: Michael Culbertson (mculbert)
Assigned to: Nobody/Anonymous (nobody)
Summary: Garbage output to file of specific size
Initial Comment:
The attached script inexplicably fills the output file with garbage using the
input file available at:
http://cs.wheaton.edu/~mculbert/StdDetVol_Scaled_SMDS.dat (4.6Mb)
If the string outputed in line 26 is changed to f.write("bla "), the output
file is legible. If the expression is changed from f.write("%g " % k) to
f.write("%f " % k) or f.write("%e " % k), the file is legible. If, however,
the expression is changed to f.write('x'*len(str(k))+" "), the file remains
illegible. Adding a print statement:
print "%g " % k
before line 26 indicates that k is assuming the correct values and that the
string interpolation is functioning properly. This suggests that the problem
causing the garbage may be related to the specific file size created with this
particular set of data.
The problem occurs with Python 2.4.3 (#69, Mar 29 2006, 17:35:34) [MSC v.1310
32 bit (Intel)] under Windows XP. The problem doesn't occur with the same
script and input file using Python 2.3.5 on Mac OS 10.4.8.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630894&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-889153 ] asyncore.dispactcher: incorrect connect
Bugs item #889153, was opened at 2004-02-02 19:04 Message generated for change (Comment added) made by klimkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&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: Sankov Dmitry Alexandrovich (sankov_da) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore.dispactcher: incorrect connect Initial Comment: When i use non-blocking socket, connect() method of asyncore.dispatcher class looks like works incorrect. Example: if connection have not established then socket merely closed and handle_error not called and no exception throwed. One more example: if writable() and readble() methods returns zero than handle_connect() will never be called even if connection will be established. Thanks. -- Comment By: Alexey Klimkin (klimkin) Date: 2007-01-08 23:52 Message: Logged In: YES user_id=410460 Originator: NO I was working with Dmitry desk by desk :), but I don't remember, what did he really mean with his "broken" english :). The main problem was in impossibility to connect to another peer in non-blocking manner. The patch contains the workaround code, which changes original behaviour significantly. You may seek for your own way to fix blocking connect there. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-08 20:02 Message: Logged In: YES user_id=341410 Originator: NO According to my reading, the only change necessary to make the semantics equivalent for a non-blocking socket for which .connect() has been called is to change a portion of the dispatcher's __init__ method to: try: self.addr = sock.getpeername() except socket.error: # if we can't get the peer name, we haven't connected yet self.connected = False -- Comment By: Alexey Klimkin (klimkin) Date: 2007-01-08 13:37 Message: Logged In: YES user_id=410460 Originator: NO It's about _non-blocking_ socket. Socket has been created and connect called. However, for non-blocking socket connect returns immediately. The patch allows to use connect in non-blocking manner. I don't see any reason of limiting socket to be connected in blocking manner. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-07 02:05 Message: Logged In: YES user_id=341410 Originator: NO It sounds as though the original poster is passing a socket that has been created, but which is not yet connected, to the dispatcher constructor. We should update the documentation to state that either the user should pass a completely connected socket (as returned by socket.accept(), or which has connected as the result of a a blocking socket.connect() call), or use the .create_socket() and .connect() methods of the dispatcher. -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 11:22 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=889153&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-658749 ] asyncore connect() and winsock errors
Bugs item #658749, was opened at 2002-12-26 21:25 Message generated for change (Comment added) made by klimkin You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&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.3 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Guido van Rossum (gvanrossum) Assigned to: Josiah Carlson (josiahcarlson) Summary: asyncore connect() and winsock errors Initial Comment: asyncore's connect() method should interpret the winsock errors; these are different from Unix (and different between the Win98 family and the Win2k family). -- Comment By: Alexey Klimkin (klimkin) Date: 2007-01-08 23:59 Message: Logged In: YES user_id=410460 Originator: NO Sorry, but 2 years ago we were developing this for Linux and XP only;). Even they say to be POSIX, they behave a little differently. As I remember, we have added handling of some E* return codes, which was appearing for non-blocking connect on XP. If you connect while in blocking state, you won't get those values. -- Comment By: Josiah Carlson (josiahcarlson) Date: 2007-01-07 09:10 Message: Logged In: YES user_id=341410 Originator: NO klimkin: Please explain how either of the versions of patch #909005 fix the problem. From what I can tell, the only change you made was to move the accept() handling of errors to the handle_read() method. Guido: In terms of winsock errors, which are actually raised on connection error between win98, win2k, and/or XP, 2003, and Vista? -- Comment By: Alexey Klimkin (klimkin) Date: 2004-03-04 11:24 Message: Logged In: YES user_id=410460 Patch #909005 fixes the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=658749&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630794 ] Seg fault in readline call.
Bugs item #1630794, was opened at 2007-01-08 18:02 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&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: Open Resolution: None Priority: 5 Private: No Submitted By: gnovak (gnovak) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in readline call. Initial Comment: GDL is a free implementation of the IDL programming language that can be built as a Python module to allow one to call IDL code from Python. http://gnudatalanguage.sourceforge.net/ When "enough" of readline has been activated, I get a seg fault with the backtrace listed below when trying to call any GDL code from Python. I've also reported the problem there. One way to initialize enough of readline is to use IPython (http://ipython.scipy.org), an enhanced interactive Python shell (this is how I found the bug). Another way is to follow the instructions from IPython's author (no IPython required) listed below. I am using: OS X 10.4.8 Python 2.4.2 (#1, Mar 22 2006, 21:27:43) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin GDL 0.9 pre 3 readline 5.0 -- >Comment By: Michael Hudson (mwh) Date: 2007-01-08 21:09 Message: Logged In: YES user_id=6656 Originator: NO You don't really provide enough information for us to be able to help you. A self-contained test case would be best, failing that a backtrace from gdb might help. Also, Python 2.5 and readline 5.1 are out now, maybe you could try with them? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 17:50 Message generated for change (Comment added) made by t-v You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&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: Wont Fix Priority: 5 Private: No Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- Comment By: Thomas Viehmann (t-v) Date: 2007-01-08 22:34 Message: Logged In: YES user_id=680463 Originator: NO Hi, could you please reconsider closing this bug and consider fixing it or at least providing an option for standard behaviour? Leaving aside the question of performance impact of postprocessing in longer mails (for those, email may not a be good optionin the first place), the module as is renders the email.Generator mostly useless for multipart messages with binary data that needs to be standards compliant, e.g. Multipart-Messages containing images, possibly signed or uploading (with httplib) multipart/form-data. Thank you for your consideration. Kind regards Thomas -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-20 11:05 Message: Logged In: YES user_id=1054957 But the generator does not output in native line endings! On Windows: >>> from email.Message import Message >>> msg = Message() >>> msg["From"] = "me" >>> msg["To"] = "you" >>> print repr(msg.as_string()) 'From: me\nTo: you\n\n' -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-18 00:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 17:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 13:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 10:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 06:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n line endings, don't. The smtplib module automatically ensures proper line endings for the on-the-wire communication. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1630794 ] Seg fault in readline call.
Bugs item #1630794, was opened at 2007-01-08 10:02 Message generated for change (Comment added) made by gnovak You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&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: Open Resolution: None Priority: 5 Private: No Submitted By: gnovak (gnovak) Assigned to: Nobody/Anonymous (nobody) Summary: Seg fault in readline call. Initial Comment: GDL is a free implementation of the IDL programming language that can be built as a Python module to allow one to call IDL code from Python. http://gnudatalanguage.sourceforge.net/ When "enough" of readline has been activated, I get a seg fault with the backtrace listed below when trying to call any GDL code from Python. I've also reported the problem there. One way to initialize enough of readline is to use IPython (http://ipython.scipy.org), an enhanced interactive Python shell (this is how I found the bug). Another way is to follow the instructions from IPython's author (no IPython required) listed below. I am using: OS X 10.4.8 Python 2.4.2 (#1, Mar 22 2006, 21:27:43) [GCC 4.0.1 (Apple Computer, Inc. build 5247)] on darwin GDL 0.9 pre 3 readline 5.0 -- >Comment By: gnovak (gnovak) Date: 2007-01-08 13:46 Message: Logged In: YES user_id=1037806 Originator: YES The GDB backtrace is (and was) in the attached text file extra.txt. Also in extra.txt are instructions for causing Python to crash using plain Python and GDL. Unfortunately I don't know a way to cause the seg fault without installing GDL. I'm working on trying it with Python2.5 and newer readlines. -- Comment By: Michael Hudson (mwh) Date: 2007-01-08 13:09 Message: Logged In: YES user_id=6656 Originator: NO You don't really provide enough information for us to be able to help you. A self-contained test case would be best, failing that a backtrace from gdb might help. Also, Python 2.5 and readline 5.1 are out now, maybe you could try with them? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1630794&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1349106 ] email.Generators does not separates headers with "\r\n"
Bugs item #1349106, was opened at 2005-11-05 11:50 Message generated for change (Comment added) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1349106&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: Feature Request >Status: Open >Resolution: None Priority: 5 Private: No Submitted By: Manlio Perillo (manlioperillo) Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Generators does not separates headers with "\r\n" Initial Comment: Regards. The email.Generator module does not separates headers with "\r\n". Manlio Perillo -- >Comment By: Barry A. Warsaw (bwarsaw) Date: 2007-01-08 17:10 Message: Logged In: YES user_id=12800 Originator: NO I am reopening this as a feature request. I still think it's better for protocols that require these line endings to ensure that their data is standards compliant, but I can see that there may be other use cases where you'd want to generate protocol required line endings. I'm not totally convinced, but it's worth opening the issue for now and discussing this on the email-sig. -- Comment By: Thomas Viehmann (t-v) Date: 2007-01-08 16:34 Message: Logged In: YES user_id=680463 Originator: NO Hi, could you please reconsider closing this bug and consider fixing it or at least providing an option for standard behaviour? Leaving aside the question of performance impact of postprocessing in longer mails (for those, email may not a be good optionin the first place), the module as is renders the email.Generator mostly useless for multipart messages with binary data that needs to be standards compliant, e.g. Multipart-Messages containing images, possibly signed or uploading (with httplib) multipart/form-data. Thank you for your consideration. Kind regards Thomas -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-20 05:05 Message: Logged In: YES user_id=1054957 But the generator does not output in native line endings! On Windows: >>> from email.Message import Message >>> msg = Message() >>> msg["From"] = "me" >>> msg["To"] = "you" >>> print repr(msg.as_string()) 'From: me\nTo: you\n\n' -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 18:47 Message: Logged In: YES user_id=12800 I hear what you're saying, but so far, it has been more convenient for developers when the generator outputs native line endings. I can see a case for a flag or other switch on the Generator instance to force RFC 2822 line endings. I would suggest joining the email-sig and posting a request there so the issue can be discussed as an RFE. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 11:26 Message: Logged In: YES user_id=1054957 I do not agree here (but I'm not an expert). First - the documentation says: """The email package attempts to be as RFC-compliant as possible, supporting in addition to RFC 2822, such MIME-related RFCs as RFC 2045, RFC 2046, RFC 2047, and RFC 2231. """ But, as I can see, the generated email does not conform to RFC 2822. Second - I use email package as a "filter". read raw email text, do some processing, generate raw email text. Really, I don't understand why generated headers don't are separed by '\r\n' and one must rely on an external tool for the right conversion. Thanks. -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 07:54 Message: Logged In: YES user_id=12800 The module that speaks the wire protocol should do the conversion. IMO, there's no other way to guarantee that you're RFC compliant. You could be getting your data from the email package, but you could be getting it from anywhere else, and /that/ source may not be RFC line ended either. Since you can't change every possible source of data for NNTP or SMTP, your network interface must guarantee conformance. -- Comment By: Manlio Perillo (manlioperillo) Date: 2006-01-17 04:20 Message: Logged In: YES user_id=1054957 Ok, thanks. But what if I don't use the smtplib module? I discovered the bug because I have written a small NNTP server with twisted, using email module for parsing... -- Comment By: Barry A. Warsaw (bwarsaw) Date: 2006-01-17 00:35 Message: Logged In: YES user_id=12800 Correct; this is by design. If you're worried about protocols such as RFC 2821 requiring \r\n
