[ python-Bugs-890010 ] Odd warning behaviors
Bugs item #890010, was opened at 2004-02-03 23:25
Message generated for change (Comment added) made by birkenfeld
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&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.3
>Status: Closed
>Resolution: Fixed
Priority: 5
Submitted By: Tim Peters (tim_one)
Assigned to: Georg Brandl (birkenfeld)
Summary: Odd warning behaviors
Initial Comment:
This is from Evan Simpson, on the zope-dev list. The
bulk have to do with what happens if __name__ is set to
None:
Subject: Re: [Zope-dev] Re: Zope 2.7.0 rc2 + python
2.3.3 problem
http://mail.zope.org/mailman/listinfo/zope-dev
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> range(1.0)
__main__:1: DeprecationWarning: integer argument
expected, got float
[0]
>>>
So far, so good. However:
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> __name__=None
>>> range(1.0)
[]
>>> 1+1
Traceback (most recent call last):
File "/usr/lib/python2.3/warnings.py", line 57, in warn
warn_explicit(message, category, filename, lineno,
module, registry)
File "/usr/lib/python2.3/warnings.py", line 63, in
warn_explicit
if module[-3:].lower() == ".py":
TypeError: unsubscriptable object
>>>
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import warnings
>>> warnings.simplefilter("error",
category=DeprecationWarning)
>>> range(1.0)
[]
>>> 1+1
Traceback (most recent call last):
File "/usr/lib/python2.3/warnings.py", line 57, in warn
warn_explicit(message, category, filename, lineno,
module, registry)
File "/usr/lib/python2.3/warnings.py", line 92, in
warn_explicit
raise message
DeprecationWarning: integer argument expected, got
float
>>>
...and...
Python 2.3.3 (#2, Jan 13 2004, 00:47:05)
[GCC 3.3.3 20040110 (prerelease) (Debian)] on linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> import pdb
>>> __name__ = None
>>> pdb.run('range(1.0)')
> (1)?()
(Pdb) s
--Call--
> /usr/lib/python2.3/warnings.py(24)warn()
-> def warn(message, category=None, stacklevel=1):
(Pdb) r
--Return--
/usr/lib/python2.3/bdb.py:302: RuntimeWarning:
tp_compare didn't return
-1 or -2 for exception
i = max(0, len(stack) - 1)
[traceback snipped]
Looks like something isn't properly propagating
exceptions.
Cheers,
Evan @ 4-am
--
>Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-18 19:38
Message:
Logged In: YES
user_id=1188172
I fixed warnings inbetween, see revision 42028.
So I guess this can be closed.
--
Comment By: Tim Peters (tim_one)
Date: 2006-01-17 22:53
Message:
Logged In: YES
user_id=31435
No, it's certainly not OK for range(1.0) to raise either
DeprecationWarning or TypeError depending on what __name__
happens to be. But I may not understand what you mean.
This is a screen scrape from current SVN trunk, on Windows:
>>> __name__ = None; range(1.0)
None:1: DeprecationWarning: integer argument expected, got float
[0]
I don't see TypeError there, so I'm not sure what
"""
In current SVN heads, range(1.0) gives DeprecationWarning and
__name__=None; range(1.0) gives TypeError.
"""
means.
--
Comment By: Georg Brandl (birkenfeld)
Date: 2006-01-10 23:28
Message:
Logged In: YES
user_id=1188172
In current SVN heads, range(1.0) gives DeprecationWarning and
__name__=None; range(1.0) gives TypeError.
Is this okay?
--
Comment By: Tim Peters (tim_one)
Date: 2004-02-17 01:51
Message:
Logged In: YES
user_id=31435
I'm listening, but with half of part of one ear. Have to agree
convertsimple() was wrong in these cases, but can't make
time for more than that. Reassigned to Jeremy, partly at
random (his is one of the names that shows up as a recent
getargs.c changer).
--
Comment By: Michael Hudson (mwh)
Date: 2004-02-12 15:09
Message:
Logged In: YES
user_id=6656
Is anyone listening?
--
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 16:05
Message:
Logged In: YES
user_id=6656
Oops, wrong file.
-
[ python-Bugs-1409403 ] email.Message should supress warning from uu.decode
Bugs item #1409403, was opened at 2006-01-18 12:55 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=1409403&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: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message should supress warning from uu.decode Initial Comment: part.get_payload(decode=True) of a uuencoded email.Message() sub-part can result in warning messages being written to sys.stderr. These warnings occur when pad characters other than encoded zeros were used to fill out the last encoded line to a multiple of 4 characters (+1 for the count character). Such non-zero padded encoded parts are produced by some current versions of Eudora and perhaps other MUAs. The warnings are unnecessary in this case and cause problems for other software, e.g., Mailman. get_payload(decode=True) calls uu.decode to actually decode the part payload. It should specify the quiet=True flag in this call to supress the warning. A suggested patch against Python 2.4.2 is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409403 ] email.Message should supress warning from uu.decode
Bugs item #1409403, was opened at 2006-01-18 12:55 Message generated for change (Settings changed) made by msapiro You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&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: Mark Sapiro (msapiro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message should supress warning from uu.decode Initial Comment: part.get_payload(decode=True) of a uuencoded email.Message() sub-part can result in warning messages being written to sys.stderr. These warnings occur when pad characters other than encoded zeros were used to fill out the last encoded line to a multiple of 4 characters (+1 for the count character). Such non-zero padded encoded parts are produced by some current versions of Eudora and perhaps other MUAs. The warnings are unnecessary in this case and cause problems for other software, e.g., Mailman. get_payload(decode=True) calls uu.decode to actually decode the part payload. It should specify the quiet=True flag in this call to supress the warning. A suggested patch against Python 2.4.2 is attached. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409403&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409443 ] frame->f_lasti not always correct
Bugs item #1409443, was opened at 2006-01-18 21:57 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=1409443&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) Assigned to: Nobody/Anonymous (nobody) Summary: frame->f_lasti not always correct Initial Comment: Contrary to the comment in ceval.c, the f_lasti field is not always correct because it is not updated by the PREDICT / PREDICTED macros. This means that when a GET_ITER is followed by a FOR_ITER, f_lasti will be left at the index of the GET_ITER the first time FOR_ITER is executed. I don't think this is a problem for YIELD_VALUE because it's not predicted to follow any other opcode. I'm running into this when examining bytecode in calling frames within a debugger callback. I suggest either documenting that f_lasti may be incorrect or adjusting it in the PREDICTED macro. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload
Bugs item #1409455, was opened at 2006-01-18 14: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=1409455&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: Mark Sapiro (msapiro) Assigned to: Nobody/Anonymous (nobody) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result
Bugs item #1409460, was opened at 2006-01-18 14:19
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=1409460&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: Mark Sapiro (msapiro)
Assigned to: Nobody/Anonymous (nobody)
Summary: email.Utils.parseaddr() gives arcane result
Initial Comment:
email.Utils.parseaddr('Real Name ((comment))
<[EMAIL PROTECTED]>')
returns
('comment <[EMAIL PROTECTED]>', 'Real')
Granted the string above is invalid as RFC 2822 does
not allow parentheses within comments, but most mail
agents seem to at least take the contents of the angle
brackets as the address in this case.
rfc822.parseaddr() returns the same result in this case.
If these functions aren't going to return their
respective failure indication in this case, I think
they should at least return '[EMAIL PROTECTED]' as
the second item of the returned tuple.
Note that
parseaddr('Real Name <[EMAIL PROTECTED]> ((comment))')
does return
('Real Name', '[EMAIL PROTECTED]')
as 'expected'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409460 ] email.Utils.parseaddr() gives arcane result
Bugs item #1409460, was opened at 2006-01-18 17:19
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&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: Mark Sapiro (msapiro)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: email.Utils.parseaddr() gives arcane result
Initial Comment:
email.Utils.parseaddr('Real Name ((comment))
<[EMAIL PROTECTED]>')
returns
('comment <[EMAIL PROTECTED]>', 'Real')
Granted the string above is invalid as RFC 2822 does
not allow parentheses within comments, but most mail
agents seem to at least take the contents of the angle
brackets as the address in this case.
rfc822.parseaddr() returns the same result in this case.
If these functions aren't going to return their
respective failure indication in this case, I think
they should at least return '[EMAIL PROTECTED]' as
the second item of the returned tuple.
Note that
parseaddr('Real Name <[EMAIL PROTECTED]> ((comment))')
does return
('Real Name', '[EMAIL PROTECTED]')
as 'expected'.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409460&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409455 ] email.Message.set_payload followed by bad result get_payload
Bugs item #1409455, was opened at 2006-01-18 17:09 Message generated for change (Settings changed) made by bwarsaw You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&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: Mark Sapiro (msapiro) >Assigned to: Barry A. Warsaw (bwarsaw) Summary: email.Message.set_payload followed by bad result get_payload Initial Comment: Under certain circumstances, in particular when charset is 'iso-8859-1', where msg is an email.Message() instance, msg.set_payload(text, charset) 'apparently' encodes the text as quoted-printable and adds a Content-Transfer-Encoding: quoted-printable header to msg. I say 'apparently' because if one prints msg or creates a Generator instance and writes msg to a file, the message is printed/written as a correct, quoted-printable encoded message, but text = msg._payload or text = msg.get_payload() gives the original text, not quoted-printable encoded, and text = msg.get_payload(decode=True) gives a quoted-printable decoding of the original text which is munged if the original text included '=' in some ways. This is causing problems in Mailman which are currently worked around by flagging if the payload was set by set_payload() and not subsequently 'decoding' in that case, but it would be better if set_payload()/get_payload() worked properly. A script is attached which illustrates the problem. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409455&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409538 ] email.Charset.py CODEC_MAP no longer requires 'japanese'
Bugs item #1409538, was opened at 2006-01-19 00:35 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=1409538&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: Tokio Kikuchi (tkikuchi) Assigned to: Nobody/Anonymous (nobody) Summary: email.Charset.py CODEC_MAP no longer requires 'japanese' Initial Comment: The commonly used JapaneseCodecs no longer requires 'japanese' prefix in codec specification. On the other hand if a user install CJKCodecs instead of JapaneseCodecs, 'japanese' prefix cause error. This was already fixed in email-3.0 (Python 2.4) but should be fixed in email-2.5.x if we want to support mailman-2.2 for Python 2.3. It looks like 'korean' can also be stripped. See attached patch. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409538&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1409443 ] frame->f_lasti not always correct
Bugs item #1409443, was opened at 2006-01-18 13:57 Message generated for change (Comment added) made by nnorwitz You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: Python Interpreter Core Group: Python 2.5 Status: Open Resolution: None Priority: 5 Submitted By: John Ehresman (jpe) >Assigned to: Raymond Hettinger (rhettinger) Summary: frame->f_lasti not always correct Initial Comment: Contrary to the comment in ceval.c, the f_lasti field is not always correct because it is not updated by the PREDICT / PREDICTED macros. This means that when a GET_ITER is followed by a FOR_ITER, f_lasti will be left at the index of the GET_ITER the first time FOR_ITER is executed. I don't think this is a problem for YIELD_VALUE because it's not predicted to follow any other opcode. I'm running into this when examining bytecode in calling frames within a debugger callback. I suggest either documenting that f_lasti may be incorrect or adjusting it in the PREDICTED macro. -- >Comment By: Neal Norwitz (nnorwitz) Date: 2006-01-18 21:32 Message: Logged In: YES user_id=33168 Raymond? Given that PREDICTED was added for performance, I would lean toward updating the doc. I didn't look at the code, but I'm pretty sure John's description is accurate. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1409443&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1391872 ] floating point literals don't work in non-US locale in 2.5
Bugs item #1391872, was opened at 2005-12-28 03:01
Message generated for change (Comment added) made by bcannon
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Python Interpreter Core
Group: Python 2.5
Status: Open
Resolution: None
Priority: 5
Submitted By: Fredrik Lundh (effbot)
Assigned to: Neal Norwitz (nnorwitz)
Summary: floating point literals don't work in non-US locale in 2.5
Initial Comment:
According to reports on comp.lang.python, the current
SVN trunk fails to handle floating point literals if
the locale is changed:
>>> import locale
>>> locale.setlocale(locale.LC_ALL, '')
'German_Germany.1252'
>>> 3.141592
3.0
This works just fine in 2.4.2.
See the later portions of the thread "build
curiosities of svn head (on WinXP)" for more details:
http://groups.google.com/group/comp.lang.python/browse_
frm/thread/226584dd47047bb6/e609cb1a0d47e98f
--
>Comment By: Brett Cannon (bcannon)
Date: 2006-01-18 23:12
Message:
Logged In: YES
user_id=357491
This still fails on OS X 10.4.4:
AssertionError: using eval('3.14') failed for eu_ES
This is using rev. 42094.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 12:37
Message:
Logged In: YES
user_id=38376
Verified and fixed in SVN. Assinging to Neal, in case
he wants to add an extra locale test pass to his build
robot.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-29 10:52
Message:
Logged In: YES
user_id=38376
Looks good to me. I'll check this in shortly.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-29 00:22
Message:
Logged In: YES
user_id=55188
The new patch tests it along with other locale-dependent
tests on test__locale. How about this?
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 11:00
Message:
Logged In: YES
user_id=38376
I'm not sure you can make too many assumptions about
the locale in the test suite, but I'm pretty sure that
it would be a good idea to let your "build robot" run
the test suite twice; once with the standard C locale,
and once with a non-US locale (e.g. sv_SE.utf8 which
does include some odd characters, different date and
money formats, and a decimal comma).
--
Comment By: Neal Norwitz (nnorwitz)
Date: 2005-12-28 10:16
Message:
Logged In: YES
user_id=33168
Wow, I thought for sure I broke it with my recent patch to remove support for
hex floats. But it looks like just an AST problem (which I can be blamed for
too :-). The patch looks fine, but could you add tests so this doesn't happen
again. Thanks!
I'll be back in a week and try to fix it then if no one gets back to it.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 06:04
Message:
Logged In: YES
user_id=55188
Okay. Here's a fix.
--
Comment By: Hye-Shik Chang (perky)
Date: 2005-12-28 05:41
Message:
Logged In: YES
user_id=55188
This looks like a bug introduced by AST import;
r39757 is okay but r39762 has such an error.
--
Comment By: Fredrik Lundh (effbot)
Date: 2005-12-28 03:02
Message:
Logged In: YES
user_id=38376
I just confirmed this on Unix:
$ export LANG=sv_SE.utf8
$ ./python
Python 2.5a0 (41806M, Dec 25 2005, 12:12:29)
[GCC 2.96 2731 (Red Hat Linux 7.2 2.96-112.7.2)] on
linux2
Type "help", "copyright", "credits" or "license" for more
information.
>>> 3.14
3.1401
>>> import locale
>>> locale.setlocale(locale.LC_ALL, "")
'sv_SE.utf8'
>>> 3.14
3.0
>>>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1391872&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
