Mailman 3 April 2005 - Python-Dev

super_getattro() Behaviour
by Phil Thompson April 14, 2005

April 14, 2005

In PyQt, wrapped types implement lazy access to the type dictionary through tp_getattro. If the normal attribute lookup fails, then private tables are searched and the attribute (if found) is created on the fly and returned. It is also put into the type dictionary so that it is found next time through the normal lookup. This is done to speed up the import of, and the memory consumed by, the qt module which contains thousands of class methods. This all works fine - except when super is used. The implementation of super_getattro() doesn't use the normal attribute lookup (ie. doesn't go via tp_getattro). Instead it walks the MRO hierarchy itself and searches instance dictionaries explicitly. This means that attributes that have not yet been referenced (ie. not yet been cached in the type dictionary) will not be found. Questions... 1. What is the reason why it doesn't go via tp_getattro? Bug or feature? 2. A possible workaround is to subvert the ma_lookup function of the type dictionary after creating the type to do something similar to what my tp_getattro function is doing. Are there any inherent problems with that? 3. Why, when creating a new type and eventually calling type_new() is a copy of the dictionary passed in made? Why not take a reference to it? This would allow a dict sub-class to be used as the type dictionary. I could then implement a lazy-dict sub-class with the behaviour I need. 4. Am I missing a more correct/obvious technique? (There is no need to support classic classes.) Many thanks, Phil

2 4

Python tests fails on HP-UX 11.11 and core dumps
by Senthil Prabu.S April 14, 2005

April 14, 2005

Hello Experts, I tried python -4.2.1 on a HP-UX 11.11 PA machine. I was able to python. Gmake passes, gmake test results in error. The python reported that test_pty fails,when running this test alone. Can anyone help to find why core dumps at running the test_subprocess.py test. Also how can I solve it? Have anyone faced the same problem earlier. The details are given below; # ../../python test_pty.py Calling master_open() Got master_fd '3', slave_name '/dev/pts/0' Calling slave_open('/dev/pts/0') Got slave_fd '4' Traceback (most recent call last): File "test_pty.py", line 58, in ? test_basic_pty() File "test_pty.py", line 29, in test_basic_pty if not os.isatty(slave_fd): File "test_pty.py", line 50, in handle_sig raise TestFailed, "isatty hung" test.test_support.TestFailed: isatty hung # # ../../python test_subprocess.py test_args_string (__main__.ProcessTestCase) ... ok test_call_kwargs (__main__.ProcessTestCase) ... ok test_call_seq (__main__.ProcessTestCase) ... ok test_call_string (__main__.ProcessTestCase) ... ok test_communicate (__main__.ProcessTestCase) ... ok test_communicate_pipe_buf (__main__.ProcessTestCase) ... ok test_communicate_returns (__main__.ProcessTestCase) ... ok test_cwd (__main__.ProcessTestCase) ... ok test_env (__main__.ProcessTestCase) ... ok test_exceptions (__main__.ProcessTestCase) ... ok test_executable (__main__.ProcessTestCase) ... ok test_invalid_args (__main__.ProcessTestCase) ... ok test_invalid_bufsize (__main__.ProcessTestCase) ... ok test_list2cmdline (__main__.ProcessTestCase) ... ok test_no_leaking (__main__.ProcessTestCase) ... ok test_poll (__main__.ProcessTestCase) ... ok test_preexec (__main__.ProcessTestCase) ... ok test_run_abort (__main__.ProcessTestCase) ... ok test_shell_sequence (__main__.ProcessTestCase) ... ok test_shell_string (__main__.ProcessTestCase) ... ok test_stderr_filedes (__main__.ProcessTestCase) ... ok test_stderr_fileobj (__main__.ProcessTestCase) ... ok test_stderr_none (__main__.ProcessTestCase) ... ok test_stderr_pipe (__main__.ProcessTestCase) ... ok test_stdin_filedes (__main__.ProcessTestCase) ... ok test_stdin_fileobj (__main__.ProcessTestCase) ... ok test_stdin_none (__main__.ProcessTestCase) ... ok test_stdin_pipe (__main__.ProcessTestCase) ... ok test_stdout_filedes (__main__.ProcessTestCase) ... ok test_stdout_fileobj (__main__.ProcessTestCase) ... ok this bit of output is from a test of stdout in a different process ... test_stdout_none (__main__.ProcessTestCase) ... ok test_stdout_pipe (__main__.ProcessTestCase) ... ok test_stdout_stderr_file (__main__.ProcessTestCase) ... ok test_stdout_stderr_pipe (__main__.ProcessTestCase) ... ok test_universal_newlines (__main__.ProcessTestCase) ... ok test_universal_newlines_communicate (__main__.ProcessTestCase) ... ok test_wait (__main__.ProcessTestCase) ... ok test_writes_before_communicate (__main__.ProcessTestCase) ... ok ---------------------------------------------------------------------- Ran 38 tests in 8.171s Analysing the core file through GDB; # gdb ../../python core HP gdb 4.5 for PA-RISC 1.1 or 2.0 (narrow), HP-UX 11.00 and target hppa1.1-hp-hpux11.00. Copyright 1986 - 2001 Free Software Foundation, Inc. Hewlett-Packard Wildebeest 4.5 (based on GDB) is covered by the GNU General Public License. Type "show copying" to see the conditions to change it and/or distribute copies. Type "show warranty" for warranty/support. .. Core was generated by `python'. Program terminated with signal 6, Aborted. #0 0xc020bad0 in kill+0x10 () from /usr/lib/libc.2 (gdb) bt #0 0xc020bad0 in kill+0x10 () from /usr/lib/libc.2 #1 0xc01a655c in raise+0x24 () from /usr/lib/libc.2 #2 0xc01e69a8 in abort_C+0x160 () from /usr/lib/libc.2 #3 0xc01e6a04 in abort+0x1c () from /usr/lib/libc.2 #4 0xffbe4 in posix_abort (self=0x40029098, noargs=0x0) at ./Modules/posixmodule.c:7158 #5 0xc9b7c in PyEval_EvalFrame (f=0x40028e54) at Python/ceval.c:3531 #6 0xc01a655c in raise+0x24 () from /usr/lib/libc.2 #7 0x475b0 in freechildren (n=0x0) at Parser/node.c:131 (gdb) Build Environment; GCC - gcc version 3.4.3 HP-UX omega B.11.11 U 9000/800 ./configure --prefix=/opt/iexpress/python --disable-ipv6 --with-signal-module --with-threads Earlier, I faced problem while gmake, and make changes as per the following link; https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1071597&group_… And I was able to build Python succesfully. Also, the overall result of tests are; 250 tests OK. 1 test failed: test_pty 39 tests skipped: test_aepack test_al test_applesingle test_bsddb test_bsddb185 test_bsddb3 test_bz2 test_cd test_cl test_codecmaps_cn test_codecmaps_hk test_codecmaps_jp test_codecmaps_kr test_codecmaps_tw test_curses test_dl test_gdbm test_gl test_imgfile test_largefile test_linuxaudiodev test_locale test_macfs test_macostools test_nis test_normalization test_ossaudiodev test_pep277 test_plistlib test_scriptpackages test_socket_ssl test_socketserver test_sunaudiodev test_tcl test_timeout test_urllib2net test_urllibnet test_winreg test_winsound 2 skips unexpected on hp-ux11: test_tcl test_bz2 gmake: *** [test] Error 1

3 3

args attribute of Exception objects
by S�bastien de Menten April 12, 2005

April 12, 2005

Hi, When I need to make sense of a python exception, I often need to parse the string exception in order to retrieve the data. Example: try: print foo except NameError, e: print e.args symbol = e.args[0][17:-16] ==> ("NameError: name 'foo' is not defined", ) or try: (4).foo except NameError, e: print e.args ==> ("'int' object has no attribute 'foo'",) Moreover, in the documentation about Exception, I read """Warning: Messages to exceptions are not part of the Python API. Their contents may change from one version of Python to the next without warning and should not be relied on by code which will run under multiple versions of the interpreter. """ So even args could not be relied upon ! Two questions: 1) did I miss something in dealing with exceptions ? 2) Could this be changed to .args more in line with: a) first example: e.args = ('foo', "NameError: name 'foo' is not defined") b) second example: e.args = (4, 'foo', "'int' object has no attribute 'foo'",) the message of the string can even be retrieved with str(e) so it is also redundant. BTW, the Warning in the doc enables to change this :-) To be backward compatible, the error message could also be the first element of the tuple. Seb ps: There may be problems (that I am not aware) with an exception keeping references to other objects

2 1

New style classes and operator methods
by Greg Ewing April 11, 2005

April 11, 2005

I think I've found a small flaw in the implementation of binary operator methods for new-style Python classes. If the left and right operands are of the same class, and the class implements a right operand method but not a left operand method, the right operand method is not called. Instead, two attempts are made to call the left operand method. I'm surmising this is because both calls are funnelled through the same C-level method, which is using the types of the operands to decide whether to call the left or right Python methods. I suppose this isn't really a serious problem, since it's easily worked around by always defining at least a left operand method. But I thought I'd point it out anyway. The following example illustrates the problem: class NewStyleSpam(object): def __add__(self, other): print "NewStyleSpam.__add__", self, other return NotImplemented def __radd__(self, other): print "NewStyleSpam.__radd__", self, other return 42 x1 = NewStyleSpam() x2 = NewStyleSpam() print x1 + x2 which produces: NewStyleSpam.__add__ <__main__.NewStyleSpam object at 0x4019062c> <__main__.NewStyleSpam object at 0x4019056c> NewStyleSpam.__add__ <__main__.NewStyleSpam object at 0x4019062c> <__main__.NewStyleSpam object at 0x4019056c> Traceback (most recent call last): File "/home/cosc/staff/research/greg/tmp/foo.py", line 27, in ? print x1 + x2 TypeError: unsupported operand type(s) for +: 'NewStyleSpam' and 'NewStyleSpam' Old-style classes, on the other hand, work as expected: class OldStyleSpam: def __add__(self, other): print "OldStyleSpam.__add__", self, other return NotImplemented def __radd__(self, other): print "OldStyleSpam.__radd__", self, other return 42 y1 = OldStyleSpam() y2 = OldStyleSpam() print y1 + y2 produces: OldStyleSpam.__add__ <__main__.OldStyleSpam instance at 0x4019054c> <__main__.OldStyleSpam instance at 0x401901ec> OldStyleSpam.__radd__ <__main__.OldStyleSpam instance at 0x401901ec> <__main__.OldStyleSpam instance at 0x4019054c> 42 -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing(a)canterbury.ac.nz +--------------------------------------+

2 1

threading (GilState) question
by Michael Hudson April 10, 2005

April 10, 2005

I recently redid how the readline module handled threads around callbacks into Python (the previous code was insane). This resulted in the following bug report: http://www.python.org/sf/1176893 Which is correctly assigned to me as it's clearly a result of my recent checkin. However, I think my code is correct and the fault lies elsewhere. Basically, if you call PyGilState_Release before PyEval_InitThreads you crash, because PyEval_ReleaseThread gets called while interpreter_lock is NULL. This is very simple to make go away -- the problem is that there are several ways! Point the first is that I really think this is a bug in the GilState APIs: the readline API isn't inherently multi-threaded and so it would be insane to call PyEval_InitThreads() in initreadline, yet it has to cope with being called in a multithreaded situation. If you can't use the GilState APIs in this situation, what are they for? Option 1) Call PyEval_ThreadsInitialized() in PyGilState_Release(). Non-invasive, but bleh. Option 2) Call PyEval_SaveThread() instead of PyEval_ReleaseThread()[1] in PyGilState_Release(). This is my favourite option (PyGilState_Ensure() calls PyEval_RestoreThread which is PyEval_SaveThread()s "mate") and I guess you can distill this long mail into the question "why doesn't PyGilState_Release do this already?" Option 3) Make PyEval_ReleaseThread() not crash when interpreter_lock == NULL. Easy, but it's actually documented that you can't do this. Opinions? Am I placing too much trust into PyGilState_Release()s existing choice of function? Cheers, mwh [1] The issue of having almost-but-not-quite identical variations of API functions -- here PyEval_AcquireThread/PyEval_ReleaseThread vs. PyEval_RestoreThread/PyEval_SaveThread -- is something I can rant about at length, if anyone is interested :) -- I located the link but haven't bothered to re-read the article, preferring to post nonsense to usenet before checking my facts. -- Ben Wolfson, comp.lang.python

6 13

Developer list update
by Raymond Hettinger April 9, 2005

April 9, 2005

FYI, I'm starting a project to see what has become of some of the inactive developers. Essentially, it involves sending them a note to see if they still have use for their checkin permissions. If not, then we can make the change and improve security a bit. Also, to help with institutional memory, I started a log of changes to developer permissions. The goal is to remember who was given access, by whom, and why (some folks are given access for a one-shot project for example). The file is at Misc/developers. The first entry is for Nick Coghlan who was just granted tracker permissions so he can help manage outstanding bugs and patches. Raymond Hettinger

9 16

hierarchicial named groups extension to the re library
by ottrey＠py.redsoft.be April 8, 2005

April 8, 2005

I've written an extension to the re library, to provide a more complete matching of hierarchical named groups in regular expressions. I've set up a sourceforge project for it: http://pyre2.sourceforge.net/ re2 extracts a hierarchy of named groups matches from a string, rather than the flat, incomplete dictionary that the standard re module returns. (ie. the re library only returns the ~last~ match for named groups - not a list of ~all~ the matches for the named groups. And the hierarchy of those named groups is non-existant in the flat dictionary of matches that results. ) eg. >>> import re >>> buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping' >>> regex='^((?P<verse>(?P<number>\d+) (?P<activity>[^,]+))(, )?)*$' >>> pat1=re.compile(regex) >>> m=pat1.match(buf) >>> m.groupdict() {'verse': '10 lords a-leaping', 'number': '10', 'activity': 'lords a-leaping'} >>> import re2 >>> buf='12 drummers drumming, 11 pipers piping, 10 lords a-leaping' >>> regex='^((?P<verse>(?P<number>\d+) (?P<activity>[^,]+))(, )?)*$' >>> pat2=re2.compile(regex) >>> x=pat2.extract(buf) >>> x {'verse': [{'number': '12', 'activity': 'drummers drumming'}, {'number': '11', 'activity': 'pipers piping'}, {'number': '10', 'activity': 'lords a-leaping'}]} (See http://pyre2.sourceforge.net/ for more details.) I am wondering what would be the best direction to take this project in. Firstly is it, (or can it be made) useful enough to be included in the python stdlib? (ie. Should I bother writing a PEP for it.) And if so, would it be best to merge its functionality in with the re library, or to leave it as a separate module? And, also are there any suggestions/criticisms on the library itself?

8 8

Unicode byte order mark decoding
by Evan Jones April 8, 2005

April 8, 2005

I recently rediscovered this strange behaviour in Python's Unicode handling. I *think* it is a bug, but before I go and try to hack together a patch, I figure I should run it by the experts here on Python-Dev. If you understand Unicode, please let me know if there are problems with making these minor changes. >>> import codecs >>> codecs.BOM_UTF8.decode( "utf8" ) u'\ufeff' >>> codecs.BOM_UTF16.decode( "utf16" ) u'' Why does the UTF-16 decoder discard the BOM, while the UTF-8 decoder turns it into a character? The UTF-16 decoder contains logic to correctly handle the BOM. It even handles byte swapping, if necessary. I propose that the UTF-8 decoder should have the same logic: it should remove the BOM if it is detected at the beginning of a string. This will remove a bit of manual work for Python programs that deal with UTF-8 files created on Windows, which frequently have the BOM at the beginning. The Unicode standard is unclear about how it should be handled (version 4, section 15.9): > Although there are never any questions of byte order with UTF-8 text, > this sequence can serve as signature for UTF-8 encoded text where the > character set is unmarked. [...] Systems that use the byte order mark > must recognize when an initial U+FEFF signals the byte order. In those > cases, it is not part of the textual content and should be removed > before processing, because otherwise it may be mistaken for a > legitimate zero width no-break space. At the very least, it would be nice to add a note about this to the documentation, and possibly add this example function that implements the "UTF-8 or ASCII?" logic: def autodecode( s ): if s.beginswith( codecs.BOM_UTF8 ): # The byte string s is UTF-8 out = s.decode( "utf8" ) return out[1:] else: return s.decode( "ascii" ) As a second issue, the UTF-16LE and UTF-16BE encoders almost do the right thing: They turn the BOM into a character, just like the Unicode specification says they should. >>> codecs.BOM_UTF16_LE.decode( "utf-16le" ) u'\ufeff' >>> codecs.BOM_UTF16_BE.decode( "utf-16be" ) u'\ufeff' However, they also *incorrectly* handle the reversed byte order mark: >>> codecs.BOM_UTF16_BE.decode( "utf-16le" ) u'\ufffe' This is *not* a valid Unicode character. The Unicode specification (version 4, section 15.8) says the following about non-characters: > Applications are free to use any of these noncharacter code points > internally but should never attempt to exchange them. If a > noncharacter is received in open interchange, an application is not > required to interpret it in any way. It is good practice, however, to > recognize it as a noncharacter and to take appropriate action, such as > removing it from the text. Note that Unicode conformance freely allows > the removal of these characters. (See C10 in Section3.2, Conformance > Requirements.) My interpretation of the specification means that Python should silently remove the character, resulting in a zero length Unicode string. Similarly, both of the following lines should also result in a zero length Unicode string: >>> '\xff\xfe\xfe\xff'.decode( "utf16" ) u'\ufffe' >>> '\xff\xfe\xff\xff'.decode( "utf16" ) u'\uffff' Thanks for your feedback, Evan Jones

7 34

Weekly Python Patch/Bug Summary
by Kurt B. Kaiser April 7, 2005

April 7, 2005

Patch / Bug Summary ___________________ Patches : 308 open (+11) / 2819 closed ( +7) / 3127 total (+18) Bugs : 882 open (+11) / 4913 closed (+13) / 5795 total (+24) RFE : 176 open ( +1) / 151 closed ( +1) / 327 total ( +2) New / Reopened Patches ______________________ improvement of the script adaptation for the win32 platform (2005-03-30) http://python.org/sf/1173134 opened by Vivian De Smedt unicodedata docstrings (2005-03-30) CLOSED http://python.org/sf/1173245 opened by Jeremy Yallop __slots__ for subclasses of variable length types (2005-03-30) http://python.org/sf/1173475 opened by Michael Hudson Python crashes in pyexpat.c if malformed XML is parsed (2005-03-31) http://python.org/sf/1173998 opened by pdecat hierarchical regular expression (2005-04-01) CLOSED http://python.org/sf/1174589 opened by Chris Ottrey site enhancements (2005-04-01) http://python.org/sf/1174614 opened by Bob Ippolito Export more libreadline API functions (2005-04-01) http://python.org/sf/1175004 opened by Bruce Edge Export more libreadline API functions (2005-04-01) CLOSED http://python.org/sf/1175048 opened by Bruce Edge Patch for whitespace enforcement (2005-04-01) CLOSED http://python.org/sf/1175070 opened by Guido van Rossum Allow weak referencing of classic classes (2005-04-03) http://python.org/sf/1175850 opened by Greg Chapman threading.Condition.wait() return value indicates timeout (2005-04-03) http://python.org/sf/1175933 opened by Martin Blais Make subprocess.Popen support file-like objects (win) (2005-04-03) http://python.org/sf/1175984 opened by Nicolas Fleury Implemented new 'class foo():pass' syntax (2005-04-03) http://python.org/sf/1176019 opened by logistix locale._build_localename treatment for utf8 (2005-04-05) http://python.org/sf/1176504 opened by Hye-Shik Chang Clarify unicode.(en|de)code.() docstrings (2005-04-04) CLOSED http://python.org/sf/1176578 opened by Brett Cannon UTF-8-Sig codec (2005-04-05) http://python.org/sf/1177307 opened by Walter Dörwald Complex commented (2005-04-06) http://python.org/sf/1177597 opened by engelbert gruber explicit sign variable for longs (2005-04-06) http://python.org/sf/1177779 opened by Michael Hudson Patches Closed ______________ unicodedata docstrings (2005-03-30) http://python.org/sf/1173245 closed by perky hierarchical regular expression (2005-04-01) http://python.org/sf/1174589 closed by loewis Export more libreadline API functions (2005-04-01) http://python.org/sf/1175048 closed by loewis Patch for whitespace enforcement (2005-04-01) http://python.org/sf/1175070 closed by gvanrossum ast for decorators (2005-03-21) http://python.org/sf/1167709 closed by nascheme [ast branch] unicode literal fixes (2005-03-25) http://python.org/sf/1170272 closed by nascheme Clarify unicode.(en|de)code.() docstrings (2005-04-04) http://python.org/sf/1176578 closed by bcannon New / Reopened Bugs ___________________ very minor doc bug in 'listsort.txt' (2005-03-30) CLOSED http://python.org/sf/1173407 opened by gyrof quit should quit (2005-03-30) CLOSED http://python.org/sf/1173637 opened by Matt Chaput multiple broken links in profiler docs (2005-03-30) http://python.org/sf/1173773 opened by Ilya Sandler Reading /dev/zero causes SystemError (2005-04-01) http://python.org/sf/1174606 opened by Adam Olsen subclassing ModuleType and another built-in type (2005-04-01) http://python.org/sf/1174712 opened by Armin Rigo PYTHONPATH is not working (2005-04-01) CLOSED http://python.org/sf/1174795 opened by Alexander Belchenko property example code error (2005-04-01) http://python.org/sf/1175022 opened by John Ridley import statement likely to crash if module launches threads (2005-04-01) http://python.org/sf/1175194 opened by Jeff Stearns python hangs if import statement launches threads (2005-04-01) CLOSED http://python.org/sf/1175202 opened by Jeff Stearns codecs.readline sometimes removes newline chars (2005-04-02) CLOSED http://python.org/sf/1175396 opened by Irmen de Jong poorly named variable in urllib2.py (2005-04-03) http://python.org/sf/1175848 opened by Roy Smith StringIO and cStringIO don't provide 'name' attribute (2005-04-03) http://python.org/sf/1175967 opened by logistix compiler module didn't get updated for "class foo():pass" (2005-04-03) http://python.org/sf/1176012 opened by logistix Python garbage collector isn't detecting deadlocks (2005-04-04) CLOSED http://python.org/sf/1176467 opened by Nathan Marushak Readline segfault (2005-04-05) http://python.org/sf/1176893 opened by Walter Dörwald [PyPI] Password reset problem. (2005-04-05) CLOSED http://python.org/sf/1177077 opened by Darek Suchojad random.py/os.urandom robustness (2005-04-05) http://python.org/sf/1177468 opened by Fazal Majid error locale.getlocale() with LANGUAGE=eu_ES (2005-04-06) CLOSED http://python.org/sf/1177674 opened by Zunbeltz Izaola Exec Inside A Function (2005-04-06) http://python.org/sf/1177811 opened by Andrew Wilkinson (?(id)yes|no) only works when referencing the first group (2005-04-06) http://python.org/sf/1177831 opened by André Malo Iterator on Fileobject gives no MemoryError (2005-04-06) http://python.org/sf/1177964 opened by Folke Lemaitre cgitb.py support for frozen images (2005-04-06) http://python.org/sf/1178136 opened by Barry Alan Scott urllib.py overwrite HTTPError code with 200 (2005-04-06) http://python.org/sf/1178141 opened by Barry Alan Scott urllib2.py assumes 206 is an error (2005-04-06) http://python.org/sf/1178145 opened by Barry Alan Scott cgitb.py report wrong line number (2005-04-07) http://python.org/sf/1178148 opened by Barry Alan Scott Bugs Closed ___________ The readline module can cause python to segfault (2005-03-19) http://python.org/sf/1166660 closed by mwh very minor doc bug in 'listsort.txt' (2005-03-30) http://python.org/sf/1173407 closed by rhettinger Property access with decorator makes interpreter crash (2005-03-17) http://python.org/sf/1165306 closed by mwh "cmp" should be "key" in sort doc (2005-03-29) http://python.org/sf/1172581 closed by rhettinger why should URL be required for all packages (2005-03-25) http://python.org/sf/1170424 closed by loewis Possible windows+python bug (2005-03-22) http://python.org/sf/1168427 closed by holo9 quit should quit (2005-03-30) http://python.org/sf/1173637 closed by loewis PYTHONPATH is not working (2005-04-01) http://python.org/sf/1174795 closed by bcannon python hangs if import statement launches threads (2005-04-02) http://python.org/sf/1175202 closed by loewis codecs.readline sometimes removes newline chars (2005-04-02) http://python.org/sf/1175396 closed by doerwalter Python garbage collector isn't detecting deadlocks (2005-04-04) http://python.org/sf/1176467 closed by nascheme [PyPI] Password reset problem. (2005-04-05) http://python.org/sf/1177077 closed by jafo Minor error in section 3.2 (2005-03-11) http://python.org/sf/1161595 closed by jyby error locale.getlocale() with LANGUAGE=eu_ES (2005-04-06) http://python.org/sf/1177674 closed by perky New / Reopened RFE __________________ add "reload" function (2005-04-03) http://python.org/sf/1175686 opened by paul rubin Add a settimeout to ftplib.FTP object (2005-04-06) http://python.org/sf/1177998 opened by Juan Antonio Valiño García RFE Closed __________ file() on a file (2005-03-03) http://python.org/sf/1155485 closed by loewis

1 0

inconsistency when swapping obj.__dict__ with a dict-like object...
by Alex A. Naanou April 6, 2005

April 6, 2005

Hi! here is a simple piece of code <pre> ---cut--- class Dict(dict): def __init__(self, dct={}): self._dict = dct def __getitem__(self, name): return self._dct[name] def __setitem__(self, name, value): self._dct[name] = value def __delitem__(self, name): del self._dct[name] def __contains__(self, name): return name in self._dct def __iter__(self): return iter(self._dct) class A(object): def __new__(cls, *p, **n): o = object.__new__(cls) o.__dict__ = Dict() return o a = A() a.xxx = 123 print a.__dict__._dict a.__dict__._dict['yyy'] = 321 print a.yyy --uncut-- </pre> Here there are two problems, the first is minor, and it is that anything assigned to the __dict__ attribute is checked to be a descendant of the dict class (mixing this in does not seem to work)... and the second problem is a real annoyance, it is that the mapping protocol supported by the Dict object in the example above is not used by the attribute access mechanics (the same thing that once happened in exec)... P.S. (IMHO) the type check here is not that necessary (at least in its current state), as what we need to assert is not the relation to the dict class but the support of the mapping protocol.... thanks. -- Alex.

4 3