[ python-Bugs-890010 ] Odd warning behaviors
SourceForge.net
noreply at sourceforge.net
Wed Jan 18 19:38:04 CET 2006
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)')
> <string>(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.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 16:03
Message:
Logged In: YES
user_id=6656
How's this? It's horrible, but I'm not sure that can be avoided.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 14:22
Message:
Logged In: YES
user_id=6656
OK, the problem is that returning NULL from
getargs.c:convertsimple indicates *success* (argh!).
Fixing that provokes weird errors from handle_range_longs.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2004-02-04 13:10
Message:
Logged In: YES
user_id=6656
Might this be specific to range()?
[mwh at pc150 build]$ ./python.exe -Werror
Python 2.4a0 (#3, Feb 3 2004, 19:23:25)
[GCC 3.3 20030304 (Apple Computer, Inc. build 1493)] on darwin
Type "help", "copyright", "credits" or "license" for more
information.
>>> range(5.0)
[]
range()'s argument handling is somewhat odd
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=890010&group_id=5470
More information about the Python-bugs-list
mailing list