[ python-Bugs-1632328 ] logging.config.fileConfig doesn't clear logging._handlerList
Bugs item #1632328, was opened at 2007-01-10 13:56 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=1632328&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: Stefan H. Holek (shh42) Assigned to: Nobody/Anonymous (nobody) Summary: logging.config.fileConfig doesn't clear logging._handlerList Initial Comment: logging.config.fileConfig resets logging._handlers but not logging._handlerList, resulting in tracebacks on shutdown. e.g. Error in atexit._run_exitfuncs: Traceback (most recent call last): File "/usr/local/python2.4/lib/python2.4/atexit.py", line 24, in _run_exitfuncs func(*targs, **kargs) File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 1333, in shutdown h.close() File "/usr/local/python2.4/lib/python2.4/logging/__init__.py", line 674, in close del _handlers[self] KeyError: AFAICT this is fixed in Python 2.5 but has not been backported. Zope cannot use 2.5 as of yet. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1632328&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-1630515 ] doc misleading in re.compile
Feature Requests item #1630515, was opened at 2007-01-08 12:09 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&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: None 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. -- Comment By: Christos Georgiou (tzot) Date: 2007-01-09 20:32 Message: Logged In: YES user_id=539787 Originator: NO I like exact wording too, but I don't think this is a serious issue. I would suggest, unless you (kbriggs) offers a suitable patch, that this be dropped as a non-bug (it's a RFE, anyway). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&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-Feature Requests-1349106 ] email.Generators does not separates headers with "\r\n"
Feature Requests item #1349106, was opened at 2005-11-05 16:50 Message generated for change (Settings changed) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&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: 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 22: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 21: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 10: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 23: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 16: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 12: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 09: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 05: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
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 16:17 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6 Private: No Submitted By: dib (dib_at_work) >Assigned to: Raymond Hettinger (rhettinger) Summary: Over-zealous keyword-arguments check for built-in set class Initial Comment: The fix for bug #1119418 (xrange() builtin accepts keyword arg silently) included in Python 2.4.2c1+ breaks code that passes keyword argument(s) into classes derived from the built-in set class, even if those derived classes explictly accept those keyword arguments and avoid passing them down to the built-in base class. Simplified version of code in attached BuiltinSetKeywordArgumentsCheckBroken.py fails at (G) due to bug #1119418 if version < 2.4.2c1; if version >= 2.4.2c1 (G) passes thanks to that bug fix, but instead (H) incorrectly-in-my-view fails. [Presume similar cases would fail for xrange and the other classes mentioned in #1119418.] -- David Bruce (Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.) -- >Comment By: Georg Brandl (gbrandl) Date: 2007-01-10 21:30 Message: Logged In: YES user_id=849994 Originator: NO I'll do that, only in set_init, you have if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable)) Changing this to use PyArg_ParseTupleAndKeywords would require a format string of "|O:" + self->ob_type->tp_name Is it worth constructing that string each time set_init() is called or should it just be "|O:set" for sets and frozensets? -- Comment By: Raymond Hettinger (rhettinger) Date: 2007-01-06 02:26 Message: Logged In: YES user_id=80475 Originator: NO I prefer the approach used by list(). -- Comment By: Žiga Seilnacht (zseil) Date: 2006-05-20 01:19 Message: Logged In: YES user_id=1326842 See patch #1491939 -- Comment By: Žiga Seilnacht (zseil) Date: 2006-05-19 20:02 Message: Logged In: YES user_id=1326842 This bug was introduced as part of the fix for bug #1119418. It also affects collections.deque. Can't the _PyArg_NoKeywords check simply be moved to set_init and deque_init as it was done for zipimport.zipimporter? array.array doesn't need to be changed, since it already does all of its initialization in its __new__ method. The rest of the types changed in that fix should not be affected, since they are immutable. -- Comment By: Georg Brandl (gbrandl) Date: 2006-05-11 17:23 Message: Logged In: YES user_id=849994 Raymond, what to do in this case? Note that other built-in types, such as list(), do accept keyword arguments. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1486663 ] Over-zealous keyword-arguments check for built-in set class
Bugs item #1486663, was opened at 2006-05-11 11:17
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&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: 6
Private: No
Submitted By: dib (dib_at_work)
Assigned to: Raymond Hettinger (rhettinger)
Summary: Over-zealous keyword-arguments check for built-in set class
Initial Comment:
The fix for bug #1119418 (xrange() builtin accepts
keyword arg silently) included in Python 2.4.2c1+
breaks code that passes keyword argument(s) into
classes derived from the built-in set class, even if
those derived classes explictly accept those keyword
arguments and avoid passing them down to the built-in
base class.
Simplified version of code in attached
BuiltinSetKeywordArgumentsCheckBroken.py fails at (G)
due to bug #1119418 if version < 2.4.2c1; if version >=
2.4.2c1 (G) passes thanks to that bug fix, but instead
(H) incorrectly-in-my-view fails.
[Presume similar cases would fail for xrange and the
other classes mentioned in #1119418.]
-- David Bruce
(Tested on 2.4, 2.4.2, 2.5a2 on linux2, win32.)
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-10 19:49
Message:
Logged In: YES
user_id=80475
Originator: NO
My proposed solution:
- if(!PyArg_NoKeywords("set()", kwds)
+ if(type == &PySet_Type && !PyArg_NoKeywords("set()", kwds)
--
Comment By: Georg Brandl (gbrandl)
Date: 2007-01-10 16:30
Message:
Logged In: YES
user_id=849994
Originator: NO
I'll do that, only in set_init, you have
if (!PyArg_UnpackTuple(args, self->ob_type->tp_name, 0, 1, &iterable))
Changing this to use PyArg_ParseTupleAndKeywords would require a format
string of
"|O:" + self->ob_type->tp_name
Is it worth constructing that string each time set_init() is called or
should it just be "|O:set" for
sets and frozensets?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2007-01-05 21:26
Message:
Logged In: YES
user_id=80475
Originator: NO
I prefer the approach used by list().
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 20:19
Message:
Logged In: YES
user_id=1326842
See patch #1491939
--
Comment By: Žiga Seilnacht (zseil)
Date: 2006-05-19 15:02
Message:
Logged In: YES
user_id=1326842
This bug was introduced as part of the fix for bug #1119418.
It also affects collections.deque.
Can't the _PyArg_NoKeywords check simply be moved
to set_init and deque_init as it was done for
zipimport.zipimporter?
array.array doesn't need to be changed, since it
already does all of its initialization in its
__new__ method.
The rest of the types changed in that fix should not
be affected, since they are immutable.
--
Comment By: Georg Brandl (gbrandl)
Date: 2006-05-11 12:23
Message:
Logged In: YES
user_id=849994
Raymond, what to do in this case?
Note that other built-in types, such as list(), do accept
keyword arguments.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1486663&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1619060 ] bisect on presorted list
Bugs item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) >Assigned to: Raymond Hettinger (rhettinger) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 16:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1619060 ] bisect on presorted list
Bugs item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) >Assigned to: Raymond Hettinger (rhettinger) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 16:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1619060 ] bisect on presorted list
Bugs item #1619060, was opened at 2006-12-19 16:14 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&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.6 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Jeffrey C. Jacobs (timehorse) >Assigned to: Raymond Hettinger (rhettinger) Summary: bisect on presorted list Initial Comment: The python and c implementation of bisect do not support custom-sorted lists using the list.sort method. In order to support an arbitrarily sorted list via sort(cmp, key, reverse), I have added 3 corresponding parameters to the bisect methods for bisection and insort (insert-sorted) corresponding to the parameters in sort. This would be useful if a list is initially sorted by its sort method and then the client wishes to maintain the sort order (or reverse-sort order) while inserting an element. In this case, being able to use the same, arbitrary binary function cmp, unary function key and boolean reverse flag to preserve the list order. The change imposes 3 new branch conditions and potential no-op function calls for when key is None. I have here implemented and partially tested the python implementation and if someone besides me would find this useful, I will update the _bisectmodule.c for this change as well. The Heap functions may also find use of an arbitrary predicate function so I may look at that later, but because bisect goes hand in hand with sorting, I wanted to tackle that first. -- Comment By: Raymond Hettinger (rhettinger) Date: 2006-12-19 16:43 Message: Logged In: YES user_id=80475 Originator: NO I'm -1 on this patch. At first blush it would seem nice to progagate sort's notion of a key= function; however, sort() is an all at once operation that can guarantee the function gets called only once per key. In contrast, bisect() is more granualar so consecutive calls may need to invoke the same key= function again and again. This is almost always the the-wrong-way-to-do-it (the key function should be precomputed and either stored separately or follow a decorate-sort pattern). By including custom sorting in bisect's API we would be diverting users away from better approaches. A better idea would be to create a recipe for a SortedList class that performed pre-calculated custom keys upon insertion and maintained an internal, decorated list. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1619060&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
