Re: [Python-Dev] 2.3.5 and 2.4.1 release plans
On 2005 Feb 06, at 08:34, Tim Peters wrote: ... The easy fix: instead of cls.__mro__ use inspect.getmro which deals with that specifically. ... Since the original bug report came from Zopeland, chances are good (although the report is too vague to be sure) that the problem involves ExtensionClass. That's complicated C code in Zope predating True, of course. Still, any type w/o an __mro__ that's not recorded in the dispatch table will tickle the same bug -- give the same traceback, at least (if the original submitter would then proceed to tickle more bugs once this one's solved, I can't know, of course -- but this one does need fixing). Unsure whether this is enough, but at least inspect.getmro() isn't phased by an EC-derived class: I'm pretty sure it's enough -- at least for SOME "types w/o __mro__". Thanks to a suggestion from John Lenton on c.l.py, I was able to make a unit test based on: class C(type): def __getattribute__(self, attr): if attr == '__mro__': raise AttributeError, "What, *me*, a __mro__? Nevah!" return super(C, self).__getattribute__(attr) class D(object): __metaclass__ = C Cheating, maybe, but it does show that the 2.3.5rc1 copy.py breaks and moving to inspect.mro repairs the break, which is all one really asks of a tiny unit test;-). So, I've committed test and fix on the 2.3 maintenance branch and marked the bug as fixed. (H, is it only me, or is sourceforce bug browsing broken for bugs with 7-digits numbers? This one was 1114776 -- first one w/a 7-digit number I had yet seen -- and in no way could I get the browser to list it, it kept listing only 6-digit ones...). Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] 2.3.5 and 2.4.1 release plans
[Anthony Baxter] >> Ok, so here's the state of play: 2.3.5 is currently aimed for next >> Tuesday, but there's an outstanding issue - the new copy code appears >> to have broken something, see www.python.org/sf/1114776 for the gory >> details. ... [Alex Martelli] > The problem boils down to: deepcopying an instance of a type that > doesn't have an __mro__ (and is not one of the many types explicitly > recorded in the _deepcopy_dispatch dictionary, such as types.ClassType, > types.InstanceType, etc, etc). > > The easy fix: instead of cls.__mro__ use inspect.getmro which deals > with that specifically. > > Before I commit the fix: can anybody help out with an example of a type > anywhere in the standard library that should be deepcopyable, used to > be deepcopyable in 2.3.4, isn't one of those which get explicitly > recorded in copy._deepcopy_dispatch, AND doesn't have an __mro__? Even > the _testcapi.Copyable type magically grows an __mro__; I'm not sure > how to MAKE a type w/o one... Since the original bug report came from Zopeland, chances are good (although the report is too vague to be sure) that the problem involves ExtensionClass. That's complicated C code in Zope predating new-style classes, making it possible to build Python-class-like objects in C code under old Pythons. In general, EC-derived classes don't play well with newer Python features (well, at least not until Zope 2.8, where ExtensionClass is recoded as a new-style Python class -- but still keeping some semantics from old-style classes ... ). Anyway, I expect that instances of any EC-derived class would have the problem in the bug report. For example, the base Persistent class in ZODB 3.2.5 is an ExtensionClass: $ \python23\python.exe Python 2.3.5c1 (#61, Jan 25 2005, 19:52:06) [MSC v.1200 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import ZODB # don't ask -- it's necessary to import this first >>> from Persistence import Persistent >>> p = Persistent() >>> import copy >>> copy.deepcopy(p) # deepcopy() barfs on __mro__ Traceback (most recent call last): File "", line 1, in ? File "C:\Python23\lib\copy.py", line 200, in deepcopy copier = _getspecial(cls, "__deepcopy__") File "C:\Python23\lib\copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ >>> copy.copy(p) # copy() does too Traceback (most recent call last): File "", line 1, in ? File "C:\Python23\lib\copy.py", line 86, in copy copier = _getspecial(cls, "__copy__") File "C:\Python23\lib\copy.py", line 66, in _getspecial for basecls in cls.__mro__: AttributeError: __mro__ Unsure whether this is enough, but at least inspect.getmro() isn't phased by an EC-derived class: >>> inspect.getmro(Persistent) (,) More info from the bug report filer is really needed. A problem is that this stuff doesn't appear "to work" under Python 2.3.4 either: $ ../Python-2.3.4/python Python 2.3.4 (#1, Aug 9 2004, 17:15:36) [GCC 3.2.2 20030222 (Red Hat Linux 3.2.2-5)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import ZODB >>> from Persistence import Persistent >>> p = Persistent() >>> import copy >>> copy.deepcopy(p) Traceback (most recent call last): File "", line 1, in ? File "/home/tim/Python-2.3.4/Lib/copy.py", line 206, in deepcopy y = _reconstruct(x, rv, 1, memo) File "/home/tim/Python-2.3.4/Lib/copy.py", line 338, in _reconstruct y = callable(*args) TypeError: ExtensionClass object argument after * must be a sequence >>> copy.copy(p) Traceback (most recent call last): File "", line 1, in ? File "/home/tim/Python-2.3.4/Lib/copy.py", line 95, in copy return _reconstruct(x, rv, 0) File "/home/tim/Python-2.3.4/Lib/copy.py", line 338, in _reconstruct y = callable(*args) TypeError: ExtensionClass object argument after * must be a sequence >>> ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] list of constants -> tuple of constants
In a python-checkins message, Raymond stated: Raymond> Replace list of constants with tuples of constants. I understand the motivation here (the peephole optimizer can convert a tuple of constants into a single constant that need not be constructed over and over), but is the effort worth the cost of changing the logical nature of the data structures used? If lists are conceptually like vectors or arrays in other languages and tuples are like C structs or Pascal records, then by converting from list to tuple form you've somehow muddied the data structure water just to take advantage of tuples' immutability. Wouldn't it be better to have the peephole optimizer recognize the throwaway nature of lists in these contexts: for elt in [1, 2, 4, 8, 16]: ... if foo in [list, tuple]: ... (anywhere a list of constants immediately follows the "in" or "not in" keywords) and convert them into constants? The cases you converted all matched that usage. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list of constants -> tuple of constants
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: > > In a python-checkins message, Raymond stated: > > Raymond> Replace list of constants with tuples of constants. > > I understand the motivation here (the peephole optimizer can convert a tuple > of constants into a single constant that need not be constructed over and > over), but is the effort worth the cost of changing the logical nature of > the data structures used? If lists are conceptually like vectors or arrays > in other languages and tuples are like C structs or Pascal records, then by > converting from list to tuple form you've somehow muddied the data structure > water just to take advantage of tuples' immutability. > > Wouldn't it be better to have the peephole optimizer recognize the throwaway > nature of lists in these contexts: > > for elt in [1, 2, 4, 8, 16]: > ... > > if foo in [list, tuple]: > ... > > (anywhere a list of constants immediately follows the "in" or "not in" > keywords) and convert them into constants? The cases you converted all > matched that usage. I'm with Skip, *unless* the change is in a PROVEN TIME-CRITICAL PIECE OF CODE. Let's not hand-micro-optimize code just because we can. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list of constants -> tuple of constants
On Sun, 6 Feb 2005 10:49:05 -0600, Skip Montanaro <[EMAIL PROTECTED]> wrote: > > Wouldn't it be better to have the peephole optimizer recognize the throwaway > nature of lists in these contexts: > > for elt in [1, 2, 4, 8, 16]: > ... > > if foo in [list, tuple]: > ... > > (anywhere a list of constants immediately follows the "in" or "not in" > keywords) and convert them into constants? The cases you converted all > matched that usage. I think I implemented this once. I'll try to see if I can find a patch. It wasn't too difficult, but I'm not sure if the patch was clean. Neal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] list of constants -> tuple of constants
[Skip] > If lists are conceptually like vectors or > arrays > in other languages and tuples are like C structs or Pascal records, then > by > converting from list to tuple form you've somehow muddied the data > structure > water just to take advantage of tuples' immutability. In the context of literals used with the "in" operator, practices are widely divergent within the standard library and within the tutorial. Even within a single module, there were arbitrary switches between "x in [1,2,3]" and "x in (1,2,3)" and "x in 1,2,3". It seems that the list-as-arrays-tuple-as-records guideline is not meaningful or applicable in the context of the "in" operator. Proscribing tuple.__contains__ and tuple.__iter__ carrys the notion a bit too far. > Wouldn't it be better to have the peephole optimizer recognize the > throwaway > nature of lists That's a good idea. Implementing it will be more straight-forward after the AST branch gets completed. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] list of constants -> tuple of constants
[Neal] > I think I implemented this once. I'll try to see if I can find a > patch. It wasn't too difficult, but I'm not sure if the patch was > clean. If the opportunity arises, another worthwhile peepholer buildout would be to recognize if-elif chains that can be transformed to a single lookup and dispatch (see MAL's note in pep 275). Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RE: [Python-checkins] python/dist/src/Lib/test test_copy.py, 1.11.8.1, 1.11.8.2
> Modified Files: > Tag: release23-maint > test_copy.py > Log Message: > fix bug 1114776 Don't forget release24-maint. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
RE: [Python-Dev] list of constants -> tuple of constants
Raymond> [Skip] >> If lists are conceptually like vectors or arrays in other languages >> and tuples are like C structs or Pascal records, then by converting >> from list to tuple form you've somehow muddied the data structure >> water just to take advantage of tuples' immutability. Raymond> In the context of literals used with the "in" operator, Raymond> practices are widely divergent within the standard library and Raymond> within the tutorial. Then perhaps we should strive to make the standard library and tutorial more consistent. Answers to questions on c.l.py often advocate the standard library as a good source for example code. Raymond> It seems that the list-as-arrays-tuple-as-records guideline is Raymond> not meaningful or applicable in the context of the "in" Raymond> operator. Proscribing tuple.__contains__ and tuple.__iter__ Raymond> carrys the notion a bit too far. I agree that the presence of __contains__ and __iter__ kind of blurs the distinction between the concept of sequence and struct. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Other library updates
Any objections to replacing the likes of types.IntType and types.ListType with int and list? Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
