[ python-Bugs-1163325 ] "special" decimals aren't hashable
Bugs item #1163325, was opened at 2005-03-14 17:37
Message generated for change (Comment added) made by rhettinger
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
Category: Python Library
Group: Python 2.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Marien Zwart (marienz)
>Assigned to: Nobody/Anonymous (nobody)
Summary: "special" decimals aren't hashable
Initial Comment:
Python 2.4 (#1, Feb 22 2005, 15:02:34)
[GCC 3.4.3-20050110 (Gentoo Linux 3.4.3.20050110,
ssp-3.4.3.20050110-0, pie-8.7 on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> import decimal
>>> hash(decimal.NaN)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/lib/python2.4/decimal.py", line 720, in
__hash__
i = int(self)
File "/usr/lib/python2.4/decimal.py", line 1410, in
__int__
return context._raise_error(InvalidContext)
File "/usr/lib/python2.4/decimal.py", line 2215, in
_raise_error
raise error, explanation
decimal.InvalidOperation
This behaviour doesn't match the comment in
decimal.py's __hash__:
# Decimal integers must hash the same as the ints
# Non-integer decimals are normalized and hashed as strings
# Normalization assures that hast(100E-1) == hash(10)
Would it make sense to wrap the int(self) in an except
block and return hash(str(self.normalize())) if this
raises?
--
>Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-16 06:07
Message:
Logged In: YES
user_id=80475
Okay, it's backported.
--
Comment By: Anthony Baxter (anthonybaxter)
Date: 2005-03-15 09:10
Message:
Logged In: YES
user_id=29957
If you can check it in in the next 24 hours, yes.
otherwise, it can wait til 2.4.2
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-15 00:00
Message:
Logged In: YES
user_id=80475
Fixed. See Lib/decimal.py 1.35.
Anthony, can this be backported to 2.4.1 or does it need to
wait for 2.4.2?
--
Comment By: James Y Knight (foom)
Date: 2005-03-14 23:15
Message:
Logged In: YES
user_id=1104715
NaN, Inf, and negInf all fail to hash.
Inf and negInf are equal to themselves, so they don't have any problem
being used as a dict key.
As for NaN, I don't see any harm in allowing it to return a hashcode
anyways, but perhaps you're right.
However, in that case, it would be nice to have the exception raised be
somewhat more regular and expected-looking than a InvalidOperation
from int(). Perhaps it should raise TypeError('Decimal("NaN") is
unhashable').
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-14 19:04
Message:
Logged In: YES
user_id=31435
Well, I'm not really a fan of Python's tying hashability
to "usable as a dict key", but given that's what Python
_does_, ya, hashing a NaN doesn't make sense.
marienz, by "special" decimals did you mean only NaNs, or
do you have other cases in mind too?
--
Comment By: Raymond Hettinger (rhettinger)
Date: 2005-03-14 17:42
Message:
Logged In: YES
user_id=80475
Since two NaNs are never equal to one another, I would think
that it doesn't make sense to hash them. Tim, do you have
another thoughts on the subject?
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163325&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1161187 ] Install problem 2.4.1rc1 on Win98
Bugs item #1161187, was opened at 2005-03-11 08:56
Message generated for change (Comment added) made by m_webber_sydney
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1161187&group_id=5470
Category: Installation
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Spider (m_webber_sydney)
Assigned to: Martin v. Löwis (loewis)
Summary: Install problem 2.4.1rc1 on Win98
Initial Comment:
Python 2.4.1 Release Candidate 1.
I installed (with all the defautl settings)
python-2.4.1c1.msi on a Windows 98 machine.
The shortcuts in the Start / Programs / Python 2.4
group includes a shortcut named "Python Manuals".
This shortcut is inactive - does not point to anything
valid, and clicking on it does not bring up the manuals.
I assume that the shortcut should point to
C:/Python24/Doc/Python24.chm which certainly exists on
my machine and works ok if I access it directly.
I guess the install builds the shortcut wrongly.
--
>Comment By: Spider (m_webber_sydney)
Date: 2005-03-16 11:32
Message:
Logged In: YES
user_id=1237039
I tried
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.ms
i
(which is only 96K) and got "the installer has encountered
an unexpected error installing this package. This may
indicate a problem with this package. The error code is 2235."
--
Comment By: Martin v. Löwis (loewis)
Date: 2005-03-16 07:05
Message:
Logged In: YES
user_id=21627
Can you please try
http://www.dcl.hpi.uni-potsdam.de/home/loewis/python-2.4.12857.msi
and confirm that it "works"? This has the CHM shortcut
non-advertised.
As for the log file: the link creation is correct IMO; it is
no problem that the argument is missing (as the CHM file is
the target of the link, and needs no arguments). I was
curious whether an error is logged, but that appears not to
be the case.
--
Comment By: Tim Peters (tim_one)
Date: 2005-03-15 02:20
Message:
Logged In: YES
user_id=31435
Martin, re "resiliency": Cool -- that works! Microsoft has too
much spare cash .
--
Comment By: Spider (m_webber_sydney)
Date: 2005-03-14 08:50
Message:
Logged In: YES
user_id=1237039
I looked at the log file, and an extract is below. It shows
fairly clearly that when the "Manuals" shortcut is created,
the arguments are missing.
Let me know if you still want the full log.
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Note: 1: 2360
MSI (c) (63:E3): Executing op: InstallProtectedFiles(AllowUI=1)
MSI (c) (63:E3): Executing op:
ActionStart(Name=CreateShortcuts,Description=Creating
shortcuts,Template=Shortcut: )
Action 08:30:42: CreateShortcuts. Creating shortcuts
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=PYTHON|Python (command
line),Feature=DefaultFeature,Component={4DC71ADD-ADA5-4029-A5BC-5E8858F4243C},,,WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=2,,,)
CreateShortcuts: Shortcut: PYTHON|Python (command line)
MSI (c) (63:E3): Executing op: ShortcutCreate(Name=IDLE|IDLE
(Python
GUI),Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Lib\idlelib\idle.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: IDLE|IDLE (Python GUI)
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MODDOCS|Module
Docs,Feature=TclTk,Component={1E82B1B6-0262-4141-918C-8A03ED896CB7},,Arguments="C:\Python24\Tools\scripts\pydocgui.pyw",WorkingDir=C:\Python24\,Icon=python_icon.exe,IconIndex=0,,,)
CreateShortcuts: Shortcut: MODDOCS|Module Docs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=MANUAL|Python
Manuals,Feature=Documentation,Component={A7ED4080-C9C8-4AD4-BBAF-2D2846B7FF95}
CreateShortcuts: Shortcut: MANUAL|Python Manuals
MSI (c) (63:E3): Executing op:
SetTargetFolder(Folder=23\Python 2.4\)
MSI (c) (63:E3): SHFOLDER::SHGetFolderPath returned:
C:\WINDOWS\Start Menu\Programs
MSI (c) (63:E3): Executing op:
ShortcutCreate(Name=UNINST|Uninstall
Python,,,FileName=C:\WINDOWS\SYSTEM\msiexec,Arguments=/x{be027411-8e6b-4440-a29b-b07df0690230},,)
CreateShortcuts: Shortcut: UNINST|Uninstall Python
MSI (c) (63:E3): Executing op:
ActionStart(Name=WriteRegistryValues,Description=Writing
system registry values,Template=Key: , Name: , Value: )
Action 08:30:42: WriteRegistryValues. Writing system
registry values
MSI (c) (63:E3): Executing op:
ProgressTotal(Total=23,Type=1,ByteEquivalent=13200)
MSI (c) (63:E3): Executing op:
RegOpenKey(Root=-1,Key=Software\Classes\.py,,BinaryType=0)
MSI (c) (63:E3): Executing op: RegAddValu
[ python-Bugs-672115 ] Assignment to __bases__ of direct object subclasses
Bugs item #672115, was opened at 2003-01-21 22:45 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=672115&group_id=5470 Category: Python Interpreter Core Group: Python 2.3 Status: Open Resolution: None Priority: 5 Submitted By: Greg Chapman (glchapman) Assigned to: Michael Hudson (mwh) Summary: Assignment to __bases__ of direct object subclasses Initial Comment: I'm not entirely sure this is a bug, but I think it is surprising: Python 2.3a1 (#38, Dec 31 2002, 17:53:59) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> class A(object): ... pass ... >>> class B(object): ... pass ... >>> B.__bases__ = (A,) Traceback (most recent call last): File "", line 1, in ? TypeError: __bases__ assignment: 'A' deallocator differs from 'object' It seems like you should be able to change the __bases__ of a new-style class (implemented in Python) which inherits directly from object to another new-style class. (Will the deallocator issue ever come into play if the only types involved are HEAPTYPES and object as the ultimate base?) -- >Comment By: Michael Hudson (mwh) Date: 2005-03-16 13:22 Message: Logged In: YES user_id=6656 Two years on, I think about this again. Still here? :) The motivating thought is that: class A(object): pass class B(object): pass B.__bases__ = (A,) and class A(object): pass class B(A): pass should be equivalent. An issue that hadn't occurred to me before is that in the first example both A and B have a __dict__ (and __weakref__) descriptor, and in the second B doesn't. Should B's __dict__ descriptor be removed on the __bases__ assignment? -- Comment By: Michael Hudson (mwh) Date: 2003-02-05 14:22 Message: Logged In: YES user_id=6656 Mhmm. That looks OK to me (after realizing that solid_base worries about __slots__). But I don't know how one can be sure :-( -- Comment By: Greg Chapman (glchapman) Date: 2003-02-05 02:39 Message: Logged In: YES user_id=86307 Well, I wrote a small patch which I'm attaching. However, I can't say that I'm partcularly confident in it. It works for the simple cases I've been able to think of (and for test_descr.py), but looking at typeobject.c, I get the nagging feeling that a lot more tests are required to be sure it's OK. The problem is, I'm just not sure what they (the tests) are. -- Comment By: Michael Hudson (mwh) Date: 2003-01-31 18:09 Message: Logged In: YES user_id=6656 Are you interested in working up a patch for this? Hacking this kind of stuff requires motivation I'm not sure I can drum up in time for 2.3... -- Comment By: Greg Chapman (glchapman) Date: 2003-01-23 17:03 Message: Logged In: YES user_id=86307 Sorry about the parenthetical comment; I think what I was trying to say is basically what you have in your last paragraph. As for use cases, I don't have any myself (I ran into this with some test code for a metaclass which "overrides" __bases__). However, grepping through the standard library, I note that one place where assignment to __bases__ is used is in xmlrpclib.SlowParser. It appears to me that if SlowParser and xmllib.XMLParser (neither of which has a base class) were converted to new-style classes, the assignment to __bases__ would generate this exception. Of course, that shouldn't be too hard to work around if that turns out to be necessary. -- Comment By: Michael Hudson (mwh) Date: 2003-01-22 11:50 Message: Logged In: YES user_id=6656 I agree this is a bit surprising. When I was writing this code I went for the conservative-as-possible approach as I didn't want to introduce instabilities to Python. It certainly may be that I've overdone it. In this case I probably have; if the tp_dealloc of the class being adjusted is subtype_dealloc and the tp_dealloc that ultimately gets invoked is the same we're probably OK. But I'm not sure and it's been a while since I thought about this. It also happens that my motivating use-case for this isn't troubled by this restriction. I don't understand your last, parenthetical, comment. HEAPTYPES as such doesn't come into it, does it? You might be right that we don't need to worry about tp_dealloc if the ultimate solid_base doesn't change and all the tp_deallocs on the way there are subtype_dealloc... -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&ati
[ python-Bugs-1163401 ] uncaught AttributeError deep in urllib
Bugs item #1163401, was opened at 2005-03-14 16:39
Message generated for change (Comment added) made by lohnk
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
Category: Extension Modules
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: K Lars Lohn (lohnk)
Assigned to: Nobody/Anonymous (nobody)
Summary: uncaught AttributeError deep in urllib
Initial Comment:
Python 2.4 and Python 2.3.4 running under Suse 9.2
We're getting an AttributeError exception "AttributeError: 'NoneType' object
has no attribute 'read'" within a very simple call to urllib.urlopen.
This was discovered while working on Sentry 2, the new mirror integrity checker
for the Mozilla project. We try to touch hundreds of URLs to make sure that
the files are present on each of the mirrors. One particular URL kills the
call to urllib.urlopen:
http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe
This file probably does not exist on the mirror, however, in other cases of bad
URLs, we get much more graceful failures when we try to read from the object
returned by urllib.urlopen.
>>> import urllib
>>> urlReader =
>>> urllib.urlopen("http://mozilla.mirrors.skynet.be/pub/ftp.mozilla.org/firefox/releases/1.0/win32/en-US/Firefox%20Setup%201.0.exe";)
Traceback (most recent call last):
File "", line 1, in ?
File "/usr/local/lib/python2.4/urllib.py", line 77, in urlopen
return opener.open(url)
File "/usr/local/lib/python2.4/urllib.py", line 180, in open
return getattr(self, name)(url)
File "/usr/local/lib/python2.4/urllib.py", line 305, in open_http
return self.http_error(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 322, in http_error
return self.http_error_default(url, fp, errcode, errmsg, headers)
File "/usr/local/lib/python2.4/urllib.py", line 550, in http_error_default
return addinfourl(fp, headers, "http:" + url)
File "/usr/local/lib/python2.4/urllib.py", line 836, in __init__
addbase.__init__(self, fp)
File "/usr/local/lib/python2.4/urllib.py", line 786, in __init__
self.read = self.fp.read
AttributeError: 'NoneType' object has no attribute 'read'
The attached file is a three line scipt that demos the problem.
--
>Comment By: K Lars Lohn (lohnk)
Date: 2005-03-16 09:07
Message:
Logged In: YES
user_id=1239273
I've changed over to urllib2. The only complication involved the exception
handling model: urllib2's HTTPError exceptions cannot be pickled because they
contain an open socket._fileobject. While mildly inconvenient, the workaround
was not difficult.
--
Comment By: Skip Montanaro (montanaro)
Date: 2005-03-15 11:09
Message:
Logged In: YES
user_id=44345
Looking through the code I believe I traced the problem back
to httplib.HTTP which sets self.fp to None when it's closed.
It seems that urllib is trying to access this object after
the connection's been closed.
I realize the problem has passed for the moment, but have you
considered using urllib2? The urllib library still uses
httplib.HTTP
which is really only there for backward compatibility. From
this end it would be nice to leave urllib and httplib.HTTP
alone.
New apps should probably use urllib2 which uses the newer
httplib.HTTPConnection class.
--
Comment By: K Lars Lohn (lohnk)
Date: 2005-03-15 08:50
Message:
Logged In: YES
user_id=1239273
This problem is apparently transient depending on network conditions or,
perhaps, the configuration of the server end. On 3/14 the problem has
mysteriously vanished
--
Comment By: Jarek Zgoda (zgoda)
Date: 2005-03-15 01:52
Message:
Logged In: YES
user_id=9
No such error on Windows:
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310 32 bit
(Intel)] on win32
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1163401&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164631 ] super(...).__new__( ... ) behaves "unexpected"
Bugs item #1164631, was opened at 2005-03-16 17:07 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=1164631&group_id=5470 Category: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dirk Brenckmann (brenck) Assigned to: Nobody/Anonymous (nobody) Summary: super(...).__new__( ... ) behaves "unexpected" Initial Comment: Hello there, python code and trace output enclosed. What I did: 1. Metaclass inheritence: type <-- MA <-- MB <-- MC 2. Created Class A using __metaclass__= MC 3. Create Class B(A) using __metaclass__= MB ...although this might seem strange, it should work... When taking a look at the trace, you will notice one line that goes like: '---> why does super( MA, metacls ).__new__ call MC. __new__ in next line ' if you run the code, you will find it three times. That's ok. In my trace I just replaced two occurences of that line by ">>" to enable focussing on the Problem... What I would expect the code to do is the following: 1. Create a Class A which is of type MC 2. Create a Class B(A) which is of type MB What the interpreter does is different: 1. Create a Class A which is type MC 2.1 Nearly create a Class B which is of type MB. 2.2 In type.__new__( ... ) change it's mind. 2.3 Due to the superclass A of B, create some class A which is of type MC as well. Although B contains a __metaclass__ = MB statement. Well - that's what I experienced is "the way windows works", so I ran the code on Solaris again but the behaviour remains reproduceable... I would consider it a bug therefor. If it's not a bug, I would expect an Exception which tells me where I did wrong... Thanx for your time and efforts -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164631 ] super(...).__new__( ... ) behaves "unexpected"
Bugs item #1164631, was opened at 2005-03-16 17:07 Message generated for change (Comment added) made by brenck You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470 Category: Type/class unification Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Dirk Brenckmann (brenck) Assigned to: Nobody/Anonymous (nobody) Summary: super(...).__new__( ... ) behaves "unexpected" Initial Comment: Hello there, python code and trace output enclosed. What I did: 1. Metaclass inheritence: type <-- MA <-- MB <-- MC 2. Created Class A using __metaclass__= MC 3. Create Class B(A) using __metaclass__= MB ...although this might seem strange, it should work... When taking a look at the trace, you will notice one line that goes like: '---> why does super( MA, metacls ).__new__ call MC. __new__ in next line ' if you run the code, you will find it three times. That's ok. In my trace I just replaced two occurences of that line by ">>" to enable focussing on the Problem... What I would expect the code to do is the following: 1. Create a Class A which is of type MC 2. Create a Class B(A) which is of type MB What the interpreter does is different: 1. Create a Class A which is type MC 2.1 Nearly create a Class B which is of type MB. 2.2 In type.__new__( ... ) change it's mind. 2.3 Due to the superclass A of B, create some class A which is of type MC as well. Although B contains a __metaclass__ = MB statement. Well - that's what I experienced is "the way windows works", so I ran the code on Solaris again but the behaviour remains reproduceable... I would consider it a bug therefor. If it's not a bug, I would expect an Exception which tells me where I did wrong... Thanx for your time and efforts -- >Comment By: Dirk Brenckmann (brenck) Date: 2005-03-16 17:11 Message: Logged In: YES user_id=360037 Sorry - 2.3 must be corrected: 2.3 Due to the superclass A of B, create some class B which is of type MC as well. Although B contains a __metaclass__ = MB statement. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164631&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164726 ] UserDict is not iterable
Bugs item #1164726, was opened at 2005-03-16 19:34 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=1164726&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: UserDict is not iterable Initial Comment: UserDict does not directly support iteration: >>> import UserDict >>> ud = UserDict.UserDict() >>> ud['a'] = 1 >>> [k for k in ud] Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\UserDict.py", line 17, in __getitem__ def __getitem__(self, key): return self.data[key] KeyError: 0 The fix is to define __iter__ = iterkeys: >>> class UD(UserDict.UserDict): ... __iter__ = UserDict.UserDict.iterkeys ... >>> ud = UD() >>> ud['a'] = 1 >>> [k for k in ud] ['a'] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164742 ] Tkdnd.py crashes due to read-only attributes
Bugs item #1164742, was opened at 2005-03-16 19: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=1164742&group_id=5470 Category: Tkinter Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: tynods (tynods) Assigned to: Martin v. Löwis (loewis) Summary: Tkdnd.py crashes due to read-only attributes Initial Comment: When running Tkdnd.py, it crashes : Exception in Tkinter callback Traceback (most recent call last): File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1345, in __call__ return self.func(*args) File "C:\Python24\Lib\lib-tk\Tkdnd.py", line 179, in on_release self.finish(event, 1) File "C:\Python24\Lib\lib-tk\Tkdnd.py", line 190, in finish del root.__dnd File "C:\Python24\Lib\lib-tk\Tkinter.py", line 1653, in __delattr__ return delattr(self.tk, attr) TypeError: 'tkapp' object has only read-only attributes (del ._DndHandler__dnd) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164742&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164726 ] UserDict is not iterable
Bugs item #1164726, was opened at 2005-03-16 14:34 Message generated for change (Settings changed) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470 Category: Python Library Group: Python 2.4 >Status: Closed >Resolution: Wont Fix Priority: 5 Submitted By: Kent Johnson (kjohnson) Assigned to: Nobody/Anonymous (nobody) Summary: UserDict is not iterable Initial Comment: UserDict does not directly support iteration: >>> import UserDict >>> ud = UserDict.UserDict() >>> ud['a'] = 1 >>> [k for k in ud] Traceback (most recent call last): File "", line 1, in ? File "C:\Python24\lib\UserDict.py", line 17, in __getitem__ def __getitem__(self, key): return self.data[key] KeyError: 0 The fix is to define __iter__ = iterkeys: >>> class UD(UserDict.UserDict): ... __iter__ = UserDict.UserDict.iterkeys ... >>> ud = UD() >>> ud['a'] = 1 >>> [k for k in ud] ['a'] -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-03-16 15:24 Message: Logged In: YES user_id=80475 This could not be done for reasons of backwards compatability. To get what you want, use UserDict.IterableUserDict. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164726&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164912 ] xmlrpclib.DateTime.decode() should stringify argument
Bugs item #1164912, was opened at 2005-03-16 16:27 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=1164912&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Allan Saddi (asaddi) Assigned to: Nobody/Anonymous (nobody) Summary: xmlrpclib.DateTime.decode() should stringify argument Initial Comment: DateTime.decode() is allowing unicode strings to be assigned to self.value. Python 2.4 (#2, Feb 17 2005, 09:44:14) [GCC 2.95.4 20020320 [FreeBSD]] on freebsd4 Type "help", "copyright", "credits" or "license" for more information. >>> from xmlrpclib import * >>> s = loads(dumps((DateTime(),), methodresponse=True)) >>> print s ((,), None) When this DateTime object with unicode value is subsequently passed to dumps(), dumps() will either return the result as a unicode string (which I don't believe is the correct behavior), or it will raise a UnicodeDecodeError. >>> dumps(s[0]) u'\n\n20050316T16: 10:20\n\n\n' (UnicodeDecodeError is raised when marshalling other unicode strings that do not have a simple ascii representation with the resultant DateTime.) -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164912&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Bugs item #1164953, was opened at 2005-03-16 20:38
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=1164953&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
Assigned to: Nobody/Anonymous (nobody)
Summary: logging.basicConfig creates phantom handler
Initial Comment:
calling logging.basicConfig() creates a phantom handler
that doesn't operate in an intuitive way. A reproducable
follows.
My actual use case: I started off using the logging
module on a project with the builting logging.info(),
logging.debug(), logging.error() functions. As my needs
got more sophisticated, I started creating some loggers
via logging.getLogger('a.b.c') I setup a custom handler
to do formatting without printing "INFO:a.b.c" headers.
One of my import statements triggered a call to
logging.basicConfig. Halfway through the running
program, my logging messages started showing up
twice. Once without the header and once with. I
eventually tracked this down to usage of a logging.info()
statement. I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors,
but that didn't work.
A trivial patch is attached. It fixes the problem if you
explicitly call logging.basicConfig. I don't know if it will
fix the implicit calls by logging.info(), etc.
C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z
C:\Python24>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1164953 ] logging.basicConfig creates phantom handler
Bugs item #1164953, was opened at 2005-03-16 20:38
Message generated for change (Settings changed) made by logistix
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
Category: Python Library
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: logistix (logistix)
>Assigned to: Vinay Sajip (vsajip)
Summary: logging.basicConfig creates phantom handler
Initial Comment:
calling logging.basicConfig() creates a phantom handler
that doesn't operate in an intuitive way. A reproducable
follows.
My actual use case: I started off using the logging
module on a project with the builting logging.info(),
logging.debug(), logging.error() functions. As my needs
got more sophisticated, I started creating some loggers
via logging.getLogger('a.b.c') I setup a custom handler
to do formatting without printing "INFO:a.b.c" headers.
One of my import statements triggered a call to
logging.basicConfig. Halfway through the running
program, my logging messages started showing up
twice. Once without the header and once with. I
eventually tracked this down to usage of a logging.info()
statement. I tried explicitly calling logging.basicConfig
(level=logging.ERROR) to disable the duplicate errors,
but that didn't work.
A trivial patch is attached. It fixes the problem if you
explicitly call logging.basicConfig. I don't know if it will
fix the implicit calls by logging.info(), etc.
C:\Python24>python
Python 2.4 (#60, Nov 30 2004, 11:49:19) [MSC v.1310
32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more
information.
>>> import logging
>>>
>>> logger = logging.getLogger('foo')
>>> logger.setLevel(logging.INFO)
>>> logger.info('bar') # no output yet
No handlers could be found for logger "foo"
>>>
>>> console = logging.StreamHandler()
>>> console.setLevel(logging.INFO)
>>> console.setFormatter(logging.Formatter("%
(message)s")
... )
>>> logger.addHandler(console)
>>>
>>> logger.info('foo')
foo
>>>
>>> logger.warning('foo')
foo
>>>
>>> logger.debug('foo')
>>>
>>> logger.info('foo')
foo
>>>
>>> logging.basicConfig(level=logging.ERROR)
>>>
>>> logger.info('foo')
foo
INFO:foo:foo
>>> ^Z
C:\Python24>
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1164953&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
