[ python-Bugs-1458903 ] lambda with a parenthesized argument raises TypeError
Bugs item #1458903, was opened at 2006-03-26 12:33 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&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: Parser/Compiler Group: Python 2.5 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Jeong-Min Lee (falsetru) Assigned to: Neal Norwitz (nnorwitz) Summary: lambda with a parenthesized argument raises TypeError Initial Comment: == [EMAIL PROTECTED] ~ $ python2.5 Python 2.5a0 (trunk:43324, Mar 26 2006, 14:18:23) [GCC 3.4.5 (Gentoo 3.4.5, ssp-3.4.5-1.0, pie-8.7.9)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> (lambda(x): x)(1) Traceback (most recent call last): File "", line 1, in File "", line 1, in TypeError: unpack non-sequence >>> (lambda(x): x)((1,)) 1 >>> (lambda(x): x)((1,2)) Traceback (most recent call last): File "", line 1, in File "", line 1, in ValueError: too many values to unpack >>> not 2.4 compatible == [EMAIL PROTECTED] ~ $ python2.4 Python 2.4.2 (#1, Oct 15 2005, 13:17:32) [GCC 3.3.6 (Gentoo 3.3.6, ssp-3.3.6-1.0, pie-8.7.8)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> (lambda(x): x)(1) 1 >>> (lambda(x): x)((1,)) (1,) >>> (lambda(x): x)((1,2)) (1, 2) >>> -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 00:59 Message: Logged In: YES user_id=33168 Thanks for the report! The problem was more general. This code also broke: def foo((x)): Committed revision 43341. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458903&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)):
Bugs item #1459159, was opened at 2006-03-27 01: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=1459159&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 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)):
Bugs item #1459159, was opened at 2006-03-27 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&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 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 11:38 Message: Logged In: YES user_id=849994 That's a bit odd. Following defs: def bar((x)): pass def foo(x): pass In 2.4: >>> dis.dis(bar) 1 0 LOAD_FAST0 (.0) 3 STORE_FAST 1 (x) 6 LOAD_CONST 0 (None) 9 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE In 2.5: >>> dis.dis(bar) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459159 ] inspect.getargspec() is wrong for def foo((x)):
Bugs item #1459159, was opened at 2006-03-27 09:05 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&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 Submitted By: Neal Norwitz (nnorwitz) Assigned to: Nobody/Anonymous (nobody) Summary: inspect.getargspec() is wrong for def foo((x)): Initial Comment: See my recent checkin on HEAD for fixing def foo((x)): in the AST compiler. I had to modify test_inspect because the above signature should not do tuple unpacking. inspect thinkgs it does though. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 11:39 Message: Logged In: YES user_id=849994 This at least explains why test_inspect didn't fail for 2.5 after you had fixed the bug and modified the test. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 11:38 Message: Logged In: YES user_id=849994 That's a bit odd. Following defs: def bar((x)): pass def foo(x): pass In 2.4: >>> dis.dis(bar) 1 0 LOAD_FAST0 (.0) 3 STORE_FAST 1 (x) 6 LOAD_CONST 0 (None) 9 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE In 2.5: >>> dis.dis(bar) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE >>> dis.dis(foo) 1 0 LOAD_CONST 0 (None) 3 RETURN_VALUE -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459159&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459279 ] sgmllib.SGMLparser and hexadecimal numeric character refs
Bugs item #1459279, was opened at 2006-03-27 14:51 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=1459279&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 Submitted By: Francesco Ricciardi (nerby) Assigned to: Nobody/Anonymous (nobody) Summary: sgmllib.SGMLparser and hexadecimal numeric character refs Initial Comment: According to HTML 4.0 specification it is possible to have hexadecimal numeric character references, not only decimal (see http://www.w3.org/TR/REC-html40/charset.html#h-5.3.1). However sgmllib.SGMLparser does not recognize the hexadecimal form. More and more HTML pages now use entities with a high codepoint, not in the official HTML entity list, so proper handling to these references should be implemented. A possible solution could be: - improving the "charref" regular expression, so to include exadecimal values; - considering all numeric references valid: those with n < 255 should be converted to the corresponding characters, those above 255 should be left as numerical charrefs. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459279&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Bugs item #1458017, was opened at 2006-03-24 21:17 Message generated for change (Comment added) made by splitscreen You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip -- Comment By: splitscreen (splitscreen) Date: 2006-03-27 21:27 Message: Logged In: YES user_id=1126061 I can't reproduce on 2.4.2. Although maybe I misunderstood... Are you saying that _log() barfs when you pass an empty tuple? Passing an empty tuple to _log() works fine here.. I can understand it breaking when you pass some format string to args and the msg contains an '%', that's the developer's fault for not escaping the precentage sign. Could you clarify? Or am I totally wrong? Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459642 ] time.timezone / time.strftime('%z') problem
Bugs item #1459642, was opened at 2006-03-27 23:47
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=1459642&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
Submitted By: Simon Lanzmich (si_lan)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.timezone / time.strftime('%z') problem
Initial Comment:
The information returned by time.timezone and
time.strftime('%z') are different!
I get the following results:
[EMAIL PROTECTED] ~]$ date +%z
+0200
[EMAIL PROTECTED] ~]$ date +%Z
CEST
[EMAIL PROTECTED] ~]$ python
Python 2.4.2 (#1, Feb 12 2006, 03:45:41)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2
[...]
>>> time.timezone
-3600
>>> time.strftime('%z')
'+0200'
Please correct me if I'm wrong, but shouldn't
"time.timezone" return -7200 ?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459642 ] time.timezone / time.strftime('%z') problem
Bugs item #1459642, was opened at 2006-03-27 21:47
Message generated for change (Comment added) made by gbrandl
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&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: Invalid
Priority: 5
Submitted By: Simon Lanzmich (si_lan)
Assigned to: Nobody/Anonymous (nobody)
Summary: time.timezone / time.strftime('%z') problem
Initial Comment:
The information returned by time.timezone and
time.strftime('%z') are different!
I get the following results:
[EMAIL PROTECTED] ~]$ date +%z
+0200
[EMAIL PROTECTED] ~]$ date +%Z
CEST
[EMAIL PROTECTED] ~]$ python
Python 2.4.2 (#1, Feb 12 2006, 03:45:41)
[GCC 4.1.0 20060210 (Red Hat 4.1.0-0.24)] on linux2
[...]
>>> time.timezone
-3600
>>> time.strftime('%z')
'+0200'
Please correct me if I'm wrong, but shouldn't
"time.timezone" return -7200 ?
--
>Comment By: Georg Brandl (gbrandl)
Date: 2006-03-27 22:13
Message:
Logged In: YES
user_id=849994
time.timezone is documented to return the offset for the
current non-DST timezone. Your timezone is CEST, which is
CET (+0100) plus DST, which is indicated by time.daylight
being nonzero.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459642&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459103 ] missing links beetween strftime()'s...
Bugs item #1459103, was opened at 2006-03-27 07:03 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&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: Works For Me Priority: 5 Submitted By: Jens Diemer (pylucid) Assigned to: Nobody/Anonymous (nobody) Summary: missing links beetween strftime()'s... Initial Comment: Ther are a few strftime(): strftime() (date method) strftime() (datetime method) strftime() (in module time) strftime() (time method) http://starship.python.net/crew/theller/pyhelp.cgi?keyword=strftime&version=current But only in time.strftime() is the directives table: http://docs.python.org/lib/module-time.html#l2h-1955 That's ok, if there is a Link directly to this table, in the other modules. I suggest: set Links in the other modules to the directives table in module time. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 22:14 Message: Logged In: YES user_id=849994 All the datetime methods refer to the "section of strftime() behavior" which is important to know. From there, there is a link to time.strftime. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459103&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Bugs item #1458927, was opened at 2006-03-26 21:38 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&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: Later Priority: 4 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: -Q warn option is still not default in 2.4 Initial Comment: I noticed that contrary to what has been said in http://www.python.org/doc/2.2.3/whatsnew/node7.html, namely that integer divison should print deprecation warnings beginning with Python 2.3, even Python 2.4 is still quiet about it, i.e. you still need to explicitely set the -Q warn option to see the warnings. Is that by intent or has it simply been forgotten? If it has been forgotten, it should be probably changed in Python 2.5. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-27 22:16 Message: Logged In: YES user_id=849994 Anthony, release manager for 2.5, has decided to put this off (most probably until 3.0). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459733 ] sets.Set can't be subclassed
Bugs item #1459733, was opened at 2006-03-28 04:37 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=1459733&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 Submitted By: Michal Kwiatkowski (rubyjoker) Assigned to: Nobody/Anonymous (nobody) Summary: sets.Set can't be subclassed Initial Comment: sets.Set class fail to hide its implementation. Subclassing it and overriding __init__ causes an exception during object creation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459733 ] sets.Set can't be subclassed
Bugs item #1459733, was opened at 2006-03-28 04:37 Message generated for change (Comment added) made by rubyjoker You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&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 Submitted By: Michal Kwiatkowski (rubyjoker) Assigned to: Nobody/Anonymous (nobody) Summary: sets.Set can't be subclassed Initial Comment: sets.Set class fail to hide its implementation. Subclassing it and overriding __init__ causes an exception during object creation. -- >Comment By: Michal Kwiatkowski (rubyjoker) Date: 2006-03-28 04:41 Message: Logged In: YES user_id=1310227 I'm posting a proposed patch with a test case covering this bug (shouldn't all standard library modules have tests?). It may introduce performance lost, as it removes __slots__ definition. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458017 ] Log._log needs to be more forgiving...
Bugs item #1458017, was opened at 2006-03-24 15:17 Message generated for change (Comment added) made by montanaro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&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: Distutils Group: None Status: Open Resolution: None Priority: 5 Submitted By: Skip Montanaro (montanaro) Assigned to: Nobody/Anonymous (nobody) Summary: Log._log needs to be more forgiving... Initial Comment: The _log method of distutils' Log class executes print msg % args where args might be an empty tuple (the methods that call _log all have varargs signatures). If that's the case and msg happens to contain a % sign, it barfs. It should be more forgiving, for instance: def _log(self, level, msg, args): if level >= self.threshold: try: print msg % args except TypeError: if not args: print msg else: raise sys.stdout.flush() I just corrected this locally for our 2.3 and 2.4 installations. The above is a bit ugly, but it does allow the common case (msg contains a % but an empty args list) to pass while still catching most programmer errors. Distutils is trying to log this message (wrapped): gcc -fno-strict-aliasing -DNDEBUG -g -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/app/mysql-5.0.19/include -I/opt/app/mysql-5.0.19/include -I/opt/lang/python/include/python2.3 -c _mysql.c -o build/temp.solaris-2.8-i86pc-2.3/_mysql.o -I/opt/app/mysql-5.0.19/include -xO3 -mt -fsimple=1 -ftrap=%none -nofstore -xbuiltin=%all -xlibmil -xlibmopt -xtarget=generic I suppose it would be better if all the places in distutils which log compiler commands without extra args escaped their % signs. This seems like an acceptable compromise though. Skip -- >Comment By: Skip Montanaro (montanaro) Date: 2006-03-27 21:58 Message: Logged In: YES user_id=44345 It barfs if you pass an empty tuple and the msg argument contains a % escape. For example, try: print "%s" % () In the particular case that tripped me up, it's trying to print a (bogus) gcc command which contains % escapes while passing no args to map them. -- Comment By: splitscreen (splitscreen) Date: 2006-03-27 15:27 Message: Logged In: YES user_id=1126061 I can't reproduce on 2.4.2. Although maybe I misunderstood... Are you saying that _log() barfs when you pass an empty tuple? Passing an empty tuple to _log() works fine here.. I can understand it breaking when you pass some format string to args and the msg contains an '%', that's the developer's fault for not escaping the precentage sign. Could you clarify? Or am I totally wrong? Thanks -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458017&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459733 ] sets.Set can't be subclassed
Bugs item #1459733, was opened at 2006-03-28 04:37 Message generated for change (Comment added) made by zseil You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&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 Submitted By: Michal Kwiatkowski (rubyjoker) Assigned to: Nobody/Anonymous (nobody) Summary: sets.Set can't be subclassed Initial Comment: sets.Set class fail to hide its implementation. Subclassing it and overriding __init__ causes an exception during object creation. -- Comment By: iga Seilnacht (zseil) Date: 2006-03-28 08:33 Message: Logged In: YES user_id=1326842 This is a bug in your code, you have to call the base class's __init__ method. The error does not occur during the object creation, but later when repr(obj) fails due to incorrect initialization. -- Comment By: Michal Kwiatkowski (rubyjoker) Date: 2006-03-28 04:41 Message: Logged In: YES user_id=1310227 I'm posting a proposed patch with a test case covering this bug (shouldn't all standard library modules have tests?). It may introduce performance lost, as it removes __slots__ definition. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1458927 ] -Q warn option is still not default in 2.4
Bugs item #1458927, was opened at 2006-03-27 08:38 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&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: Later Priority: 4 Submitted By: Christoph Zwerschke (cito) Assigned to: Nobody/Anonymous (nobody) Summary: -Q warn option is still not default in 2.4 Initial Comment: I noticed that contrary to what has been said in http://www.python.org/doc/2.2.3/whatsnew/node7.html, namely that integer divison should print deprecation warnings beginning with Python 2.3, even Python 2.4 is still quiet about it, i.e. you still need to explicitely set the -Q warn option to see the warnings. Is that by intent or has it simply been forgotten? If it has been forgotten, it should be probably changed in Python 2.5. -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-03-28 18:06 Message: Logged In: YES user_id=29957 It's too disruptive a change. If you try running the Python testsuite with -Qnew, you'll see that we don't even get it correct yet. -- Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 09:16 Message: Logged In: YES user_id=849994 Anthony, release manager for 2.5, has decided to put this off (most probably until 3.0). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1458927&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Bugs item #1459808, was opened at 2006-03-28 18:13 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=1459808&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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test suite should pass with -Qnew ? Initial Comment: Even though we're not going to change the default for -Q in Python 2.x, I feel that the testsuite and the stdlib should demonstrate best practices, and pass with -Qnew, at least. The following fail under 2.5-HEAD: test_builtin test_coercion test_decimal test_doctest -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Bugs item #1459808, was opened at 2006-03-28 02:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test suite should pass with -Qnew ? Initial Comment: Even though we're not going to change the default for -Q in Python 2.x, I feel that the testsuite and the stdlib should demonstrate best practices, and pass with -Qnew, at least. The following fail under 2.5-HEAD: test_builtin test_coercion test_decimal test_doctest -- >Comment By: Tim Peters (tim_one) Date: 2006-03-28 02:29 Message: Logged In: YES user_id=31435 FYI, test_doctest works w/ -Qnew now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1379994 ] "unicode_escape" and "raw_unicode_escape" encoding is broken
Bugs item #1379994, was opened at 2005-12-14 11:47
Message generated for change (Comment added) made by anthonybaxter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&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: Unicode
Group: Python 2.4
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Mark Mc Mahon (markmcmahon)
Assigned to: Hye-Shik Chang (perky)
Summary: "unicode_escape" and "raw_unicode_escape" encoding is broken
Initial Comment:
In Python 2.4.2 and Python 2.4.1 (Windows XP)
>>> "\t\\t".encode("string_escape")
'\\tt'
>>> "\t\\t".encode("unicode_escape")
'\\t\\t'
>>> "\t\\t".encode("raw_unicode_escape")
'\t\\t'
>>> u"\t\\t".encode("unicode_escape")
'\\t\\t'
>>> u"\t\\t".encode("raw_unicode_escape")
'\t\\t'
I would have expected all to produce the same result.
Also round-tripping with the encoding doesn't seem to work:
>>> "\t\\t".encode('string_escape').decode('string_escape')
'\t\\t'
>>>
u"\t\\t".encode('unicode_escape').decode('unicode_escape')
u'\t\t'
Thanks
Mark
--
>Comment By: Anthony Baxter (anthonybaxter)
Date: 2006-03-28 18:38
Message:
Logged In: YES
user_id=29957
This caused other issues (#1459029) and was reverted from
the 2.4 branch. Fix is still in 2.5.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-17 15:39
Message:
Logged In: YES
user_id=55188
Committed as r41728. Thank you!
--
Comment By: M.-A. Lemburg (lemburg)
Date: 2005-12-17 02:01
Message:
Logged In: YES
user_id=38388
Please add a test case and check in the patch.
Thanks.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2005-12-16 08:39
Message:
Logged In: YES
user_id=1188172
Patch looks good.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-14 12:41
Message:
Logged In: YES
user_id=55188
Attached a patch. It looks like a simple typo. :)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1379994&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459808 ] test suite should pass with -Qnew ?
Bugs item #1459808, was opened at 2006-03-28 02:13 Message generated for change (Comment added) made by tim_one You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&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 Submitted By: Anthony Baxter (anthonybaxter) Assigned to: Neal Norwitz (nnorwitz) Summary: test suite should pass with -Qnew ? Initial Comment: Even though we're not going to change the default for -Q in Python 2.x, I feel that the testsuite and the stdlib should demonstrate best practices, and pass with -Qnew, at least. The following fail under 2.5-HEAD: test_builtin test_coercion test_decimal test_doctest -- >Comment By: Tim Peters (tim_one) Date: 2006-03-28 02:39 Message: Logged In: YES user_id=31435 FYI, test_builtin passes w/ or w/o -Qnew now, and I'm going to sleep :-). -- Comment By: Tim Peters (tim_one) Date: 2006-03-28 02:29 Message: Logged In: YES user_id=31435 FYI, test_doctest works w/ -Qnew now. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459808&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459029 ] Doubled backslash in repr() method for unicode
Bugs item #1459029, was opened at 2006-03-27 13:54 Message generated for change (Comment added) made by anthonybaxter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&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: Unicode Group: Python 2.4 >Status: Closed >Resolution: Fixed Priority: 7 Submitted By: Christoph Zwerschke (cito) Assigned to: Hye-Shik Chang (perky) Summary: Doubled backslash in repr() method for unicode Initial Comment: Here is an issue that caused Kid templates (used by Turbogears) to malfunction in Python 2.4.3c1. The problem shows up with the following code: class s1: def __repr__(self): return '\\n' class s2: def __repr__(self): return u'\\n' print repr(s1()), repr(s2()) I get the following results: Python 2.3.5: \n \n Python 2.4.2: \n \n Python 2.4.3c1: \n \\n In the output for Python 2.4.3c1, the backslash in the representation of class2 appears doubled. This did not happen in earlier Python versions and seems to be a bug. My vague guess is that the issue may have crept in with an attempted fix of Bug #1379994. -- Christoph -- >Comment By: Anthony Baxter (anthonybaxter) Date: 2006-03-28 18:39 Message: Logged In: YES user_id=29957 Ok. After talking to perky, I reverted the fix for 1379994 on the release24-maint branch, and reverted /F's ancient change on the trunk. This seemed the best combination of practicality and purity. Fix will be in 2.4.3 final. Thanks for the bug report. Man, unicode and repr is a twisty ball of horrors. -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 18:09 Message: Logged In: YES user_id=33168 We need to retain the old behaviour, but also fix the bug. How can we do that? -- Comment By: Hye-Shik Chang (perky) Date: 2006-03-27 18:05 Message: Logged In: YES user_id=55188 Because unicode-escape codec didn't escape \, PyObject_Repr(u'\\') bypassed backslashes. But Martin and Fredrik made PyObject_Repr to use unicode-escape codec for unicode repr-returns 5 years ago. So by fixing unicode-escape codec, their intention could be applied for the first time, 3 months ago. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-03-27 17:57 Message: Logged In: YES user_id=29957 I'm confused how a checkin from 5+ years ago broke a change from 3 months ago? Or am I misunderstanding you? -- Comment By: Hye-Shik Chang (perky) Date: 2006-03-27 17:56 Message: Logged In: YES user_id=55188 Found it!: http://mail.python.org/pipermail/python-dev/2000-July/005353.html But their intention had never applied before 2.4.3. What problem would be if we change PyObject_Repr to use the default encoding not unicode-escape? (revert r16198) -- Comment By: Hye-Shik Chang (perky) Date: 2006-03-27 17:38 Message: Logged In: YES user_id=55188 Looking the C code, unicode_repr is doing correct. But the inconsistency came from PyObject_Repr. This change made it which is intended: r16198 | effbot | 2000-07-09 02:43:32 +0900 (ì¼, 09 7 2000) | 6 lines - changed __repr__ to use "unicode escape" encoding for unicode strings, instead of the default encoding. (see "minidom" thread for discussion, and also patch #100706) -- Comment By: Neal Norwitz (nnorwitz) Date: 2006-03-27 17:28 Message: Logged In: YES user_id=33168 Attached a patch for the test case to be added with fix. -- Comment By: Anthony Baxter (anthonybaxter) Date: 2006-03-27 16:53 Message: Logged In: YES user_id=29957 Confirmed - it's also broken in the trunk, and backing out the patch for http://www.python.org/sf/1379994 (r41728) fixes the problem. Perky, you checked this in - can you look at this soon, please? I don't want to release 2.4.3 until it's fixed, but I also want to get 2.4.3 out this week. Thanks for the bug report! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459029&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1459733 ] sets.Set can't be subclassed
Bugs item #1459733, was opened at 2006-03-28 02:37 Message generated for change (Comment added) made by gbrandl You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&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: Closed >Resolution: Invalid Priority: 5 Submitted By: Michal Kwiatkowski (rubyjoker) Assigned to: Nobody/Anonymous (nobody) Summary: sets.Set can't be subclassed Initial Comment: sets.Set class fail to hide its implementation. Subclassing it and overriding __init__ causes an exception during object creation. -- >Comment By: Georg Brandl (gbrandl) Date: 2006-03-28 07:48 Message: Logged In: YES user_id=849994 Ziga is correct, this is Invalid. -- Comment By: iga Seilnacht (zseil) Date: 2006-03-28 06:33 Message: Logged In: YES user_id=1326842 This is a bug in your code, you have to call the base class's __init__ method. The error does not occur during the object creation, but later when repr(obj) fails due to incorrect initialization. -- Comment By: Michal Kwiatkowski (rubyjoker) Date: 2006-03-28 02:41 Message: Logged In: YES user_id=1310227 I'm posting a proposed patch with a test case covering this bug (shouldn't all standard library modules have tests?). It may introduce performance lost, as it removes __slots__ definition. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1459733&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
