[ python-Bugs-1168746 ] frame.f_exc_type,value,traceback
Bugs item #1168746, was opened at 2005-03-23 00:07 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&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: None >Status: Closed >Resolution: Fixed Priority: 4 Submitted By: Armin Rigo (arigo) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: frame.f_exc_type,value,traceback Initial Comment: The frame object attributes f_exc_type, f_exc_value, f_exc_traceback are misdocumented. They are not the last exception caught by the frame, nor the one currently handled, or anything reasonable like that. They give the last exception raised in the parent frame, and only if another exception was ever raised in the current frame (in all other cases they are None). I very much doubt this is useful to anyone, so maybe un-publishing the attributes would be sensible, but in any case the doc needs a small fix (ref/types.html and the doc about and in inspect.py). -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:29 Message: Logged In: YES user_id=1188172 Okay, checked in patch #1230615 as Doc/ref/ref3.tex r1.125, r1.121.2.4. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1168746&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1204734 ] __getattribute__ documentation error?
Bugs item #1204734, was opened at 2005-05-19 07:21 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1204734&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: None >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: John Eikenberry (zhar) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: __getattribute__ documentation error? Initial Comment: >From http://www.python.org/dev/doc/devel/ref/new-style-attribute-access.html "Called unconditionally to implement attribute accesses for instances of the class. If the class also defines __getattr__, it will never be called (unless called explicitly)." But I'm not seeing this behaviour in python-2.3.5 and python-2.4.1 on Linux. class A(object): def __getattr__(self,key): print '__getattr__',key raise AttributeError,key def __getattribute__(self,key): print '__getattribute__',key raise AttributeError,key a = A() a.foo $ python test.py __getattribute__ foo __getattr__ foo Traceback (most recent call last): File "test.py", line 14, in ? a.foo File "test.py", line 7, in __getattr__ raise AttributeError(key) AttributeError: foo It seems to be calling __getattribute__ as it should, but then it falls back on __getattr__ even though the docs specifically say it shouldn't. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:30 Message: Logged In: YES user_id=1188172 Checked in my patch as Doc/ref/ref3.tex r1.125, r1.121.2.4. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-06-04 12:03 Message: Logged In: YES user_id=1188172 Attached a documentation patch, following Terry's wording. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 19:42 Message: Logged In: YES user_id=593130 If I understand correctly, this revision of the consequent of the second sentence (after ',') matches the implementation. [If the class also defines __getattr__, ] the latter will not be called unless __getattribute__ either calls it explicitly or raises an AttributeError. -- Comment By: Guido van Rossum (gvanrossum) Date: 2005-05-26 18:18 Message: Logged In: YES user_id=6380 The implementation works as expected. The documentation is flawed. -- Comment By: John Eikenberry (zhar) Date: 2005-05-26 17:52 Message: Logged In: YES user_id=322022 Terry, I started with a much longer subject but decided I didn't want to overload it to much. Guess I went to far the other way. I'll try to strike a better balance next time. Thanks. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:43 Message: Logged In: YES user_id=593130 John E: A general title like 'Documentation Error?' discourages attention from people with the specialized knowledge needed to answer such a question. I have taken the liberty of trying to add '__getattribute__'. We'll see if the edit works when I, not the OP, submits it. -- Comment By: Terry J. Reedy (tjreedy) Date: 2005-05-26 17:33 Message: Logged In: YES user_id=593130 If the default __getattribute__ explicitly calls __getattr__ (but I don't know which source file to check), then the second sentence above *would* make some sense. Guido (or deputy): what is your design intention? Note: if the second sentence is kept, replacing 'it' with 'the latter' would make it clearer. I first read 'it' as referring to __getattribute__. -- Comment By: Armin Rigo (arigo) Date: 2005-05-24 11:08 Message: Logged In: YES user_id=4771 I'll wait for an "authorized" confirmation, but so far I think that the current implementation is really how it is supposed to work. The method 'object.__getattribute__' must be there, given that it is a common technique to use it directly in overridden __getattribute__ implementations. As a consequence, __getattribute__ cannot completely shadow __getattr__, or __getattr__ would never be called. -- Comment By: John Eikenberry (zhar) Date: 2005-05-23 20:43 Message: Logged In: YES user_id=322022 Please specify in the documentation whether this is how it is supposed to work or whether this is a side-effect of the implementation. To make ex
[ python-Bugs-1228904 ] weakref example broken
Bugs item #1228904, was opened at 2005-06-28 12:32 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&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: Fixed Priority: 5 Submitted By: paolo veronelli (paolo_veronelli) >Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: weakref example broken Initial Comment: Surely the example in python2.4/lib/weakref-objects.html is untested .Bad story. Attached a working version which I suppose correct it . -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:45 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1. -- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 21:46 Message: Logged In: YES user_id=174455 I can confirm this (in 2.5a0). It seems untested as it contains several small errors. I have submitted a doc-patch with working code that is also a simplified version. See patch #1229935. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1229646 ] httplib error checking.
Bugs item #1229646, was opened at 2005-06-29 13:39 Message generated for change (Comment added) made by birkenfeld You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&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: Chris Johns (cjohns) Assigned to: Nobody/Anonymous (nobody) Summary: httplib error checking. Initial Comment: The httplib does not seem to handle error codes cleanly or in a portable way. The socket could return a ECONNRESET and does on the RTEMS platform. Also value 32 is normally EPIPE, but ECONNRESET is different so the Python errno should be used. [please excuse the manual diff :-)] line 657: < if v[0] == 32: # Broken pipe line 657: > if v[0] == errno.EPIPE or v[0] == errno.ECONNRESET: line 803: > if v[0] != 32 or not self.auto_open: line 803: >if (v[0] != errno.EPIPE and v[0] != errno.ECONNRESET) or not self.auto_open: I can provide a patch if this change make sense. -- >Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 12:50 Message: Logged In: YES user_id=1188172 Can someone judge if this makes sense? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1229646&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1231488 ] chr() returns ? when input > 127 in OS X
Bugs item #1231488, was opened at 2005-07-02 09:52 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=1231488&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: Craig Howard (craighoward) Assigned to: Nobody/Anonymous (nobody) Summary: chr() returns ? when input > 127 in OS X Initial Comment: When using macpython in OS X Tiger, chr(130) should return an "e" with an accent symbol above it. Instead it returns a "?", as it does with any number above 127. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1231488&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1228904 ] weakref example broken
Bugs item #1228904, was opened at 2005-06-28 05:32 Message generated for change (Comment added) made by rhettinger You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&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: Fixed Priority: 5 Submitted By: paolo veronelli (paolo_veronelli) Assigned to: Reinhold Birkenfeld (birkenfeld) Summary: weakref example broken Initial Comment: Surely the example in python2.4/lib/weakref-objects.html is untested .Bad story. Attached a working version which I suppose correct it . -- >Comment By: Raymond Hettinger (rhettinger) Date: 2005-07-02 12:49 Message: Logged In: YES user_id=80475 It would be useful to add a testcase cover the examples in the docs. See test_itertools.py for an example of how that is done. -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-07-02 05:45 Message: Logged In: YES user_id=1188172 Fixed in Doc/lib/libweakref.py r1.28, r1.27.4.1. -- Comment By: Peter van Kampen (pterk) Date: 2005-06-29 14:46 Message: Logged In: YES user_id=174455 I can confirm this (in 2.5a0). It seems untested as it contains several small errors. I have submitted a doc-patch with working code that is also a simplified version. See patch #1229935. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1228904&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
