Re: [Python-Dev] cpython (merge 3.3 - default): merge from 3.3
On Thu, 12 Sep 2013 07:57:25 +0200 (CEST) senthil.kumaran python-check...@python.org wrote: + local Optional argument random is a 0-argument function returning a random float in [0.0, 1.0); if it is the default None, the standard random.random will be used. +=== +Optional arg random is a 0-argument function returning a random +float in [0.0, 1.0); by default, the standard random.random. + +Do not supply the 'int' argument. + other Can you fix this? Thanks Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 09/11/2013 02:39 PM, Tim Delaney wrote: I would think that retrieving the keys from the dict would return the transformed keys (I'd call them canonical keys). The more I think about this the more I agree. A canonicaldict with a key function that simply stored the transformed key and it's value would seem to be a lot simpler: - no need to store a separate presentation key - no confusion about which of the first key/last key seen is stored - no mistakes with the first key not being added before real data and getting the presentation key wrong Further, in order to store the non-canonical keys a separate list must be kept of the keys to preseed the canonicaldict; if we store the canonical keys a separate list must be kept for presentation purposes -- so worst case scenario we're keeping the same amount of information and best-case scenario the presentation of the keys doesn't matter and we just saved ourselves an extra data structure. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
Le Thu, 12 Sep 2013 07:08:47 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/11/2013 02:39 PM, Tim Delaney wrote: I would think that retrieving the keys from the dict would return the transformed keys (I'd call them canonical keys). The more I think about this the more I agree. A canonicaldict with a key function that simply stored the transformed key and it's value would seem to be a lot simpler: And it wouldn't solve the use cases. What's the point? Further, in order to store the non-canonical keys a separate list must be kept of the keys to preseed the canonicaldict; Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl wrote: Is '__locallookup__' a really good name? In Python, *local* -- especially in context of *lookups* -- usually associates with locals() i.e. a namespace of a function/method execution frame or a namespace of a class, during *definition* of that class... So '__locallookup__' can be confusing. Why not just '__getclassattribute__' or '__classlookup__', or '__classattribute__'...? I don't particularly like __locallookup__ either, but haven't found a better name yet. __lookup_in_class__ was the best alternative I could come up with, and that feels different than other special methods. The name in the PEP is more or less derived from _PyType_Lookup, with local meaning only in this class, don't recurse in the rest of the MRO. Ronald ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On 9 Sep, 2013, at 17:43, Mark Shannon m...@hotpy.org wrote: I would like time to investigate this further, but at the moment I think it will either make attribute lookup poorly defined or slow. Of the top of my head, the problem as a I see it is basically this: Currently, type.__getattribute__() is a fixed point in the lookup of attributes. The proposal means that a fixed point is not reached until the cls parameter of type.__getattribute__() is either object or type, otherwise type.__getattribute__() and type.__locallookup__ must bounce back and forth. This will slow down *every* attribute lookup for what is a fairly obscure use case. I did a benchmark run (see the pep for details) and that seems to indicate that the performance impact is very small, possibly because the patch keeps the attribute lookup cache used by _PyType_Lookup. Anyway, I'm glad that there is now some real discussion on the proposal. Not unsurprisingly I'd love to have this, or something simular, in 3.4. I had hoped to repost the PEP a while back with more information on how the API would affect PyObjC (code removal, performance impact), but haven't had time to move forward on that front :-( Ronald Cheers, Mark. On 09/09/13 16:27, Guido van Rossum wrote: Let's just accept this PEP. It looks like a nice addition to the metaclass machinery and I don't think we'll get much more useful feedback by waiting. On Mon, Sep 9, 2013 at 7:30 AM, Ethan Furman et...@stoneleaf.us mailto:et...@stoneleaf.us wrote: On 07/30/2013 11:17 PM, Ronald Oussoren wrote: And something I forgot to ask: is anyone willing to be the BDFL-Delegate for PEP 447? *Bump*. It would be nice if this could make into 3.4. -- ~Ethan~ _ Python-Dev mailing list Python-Dev@python.org mailto:Python-Dev@python.org https://mail.python.org/__mailman/listinfo/python-dev https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/__mailman/options/python-dev/__guido%40python.org https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido http://python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/mark%40hotpy.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren ronaldousso...@mac.com wrote: On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl wrote: Is '__locallookup__' a really good name? In Python, *local* -- especially in context of *lookups* -- usually associates with locals() i.e. a namespace of a function/method execution frame or a namespace of a class, during *definition* of that class... So '__locallookup__' can be confusing. Why not just '__getclassattribute__' or '__classlookup__', or '__classattribute__'...? I don't particularly like __locallookup__ either, but haven't found a better name yet. __lookup_in_class__ was the best alternative I could come up with, and that feels different than other special methods. The name in the PEP is more or less derived from _PyType_Lookup, with local meaning only in this class, don't recurse in the rest of the MRO. Why is __getclassattribute__ worse than __locallookup__? --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] f_lineno accessors
In issues 7238 [1], 16482 [2], 17697 [3] and 17277 [4], the line number may be incorrect when the global trace function has been removed but not the frame f_trace function. A simple test (see below) in issue 17288 [5] crashes the interpreter when setting f_lineno in a generator from a return trace function. All those issues are few months old. There is a patch at issue 17277 [4] that fixes the first 4 issues. There is also a patch for issue 17288 [5]. ## Setting f_lineno in a generator ## $ cat jump.py def gen(): for i in range(1): yield i lineno = 4 for i in gen(): pass $ python -m pdb jump.py /tmp/jump.py(1)module() - def gen(): (Pdb) import sys; print(sys.version) 3.4.0a1+ (default:975d1e180689, Sep 6 2013, 09:26:12) [GCC 4.3.2] (Pdb) break 3 Breakpoint 1 at /tmp/jump.py:3 (Pdb) continue /tmp/jump.py(3)gen() - yield i (Pdb) step --Return-- /tmp/jump.py(3)gen()-0 - yield i (Pdb) jump 2 /tmp/jump.py(2)gen()-0 - for i in range(1): (Pdb) continue Segmentation fault [1] http://bugs.python.org/issue7238 [2] http://bugs.python.org/issue16482 [3] http://bugs.python.org/issue17697 [4] http://bugs.python.org/issue17277 [5] http://bugs.python.org/issue17288 Xavier ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
Le Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. That's assuming there is an a priori correct version. But there might not be any. Keeping the original key is important for different reasons depending on the use case: - for case-insensitive dicts, you want to keep the original key for presentation, logging and debugging purposes (*) - for identity dicts, the original key is mandatory because the id() value in itself is completely useless, it's just used for matching (*) For a well-known example of such behaviour, think about Windows filesystems. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 09/12/2013 08:40 AM, Antoine Pitrou wrote: Le Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. That's assuming there is an a priori correct version. But there might not be any. Keeping the original key is important for different reasons depending on the use case: - for case-insensitive dicts, you want to keep the original key for presentation, logging and debugging purposes (*) - for identity dicts, the original key is mandatory because the id() value in itself is completely useless, it's just used for matching (*) For a well-known example of such behaviour, think about Windows filesystems. Ah, I see. Thank you for explaining. -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 9/12/2013 8:40 AM, Antoine Pitrou wrote: Le Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. That's assuming there is an a priori correct version. But there might not be any. Keeping the original key is important for different reasons depending on the use case: - for case-insensitive dicts, you want to keep the original key for presentation, logging and debugging purposes (*) - for identity dicts, the original key is mandatory because the id() value in itself is completely useless, it's just used for matching - for dict with non-hashable key, but a transform function that can derive a hashable key from it, the presentation key value may be much more complex than the actual key value. (*) For a well-known example of such behaviour, think about Windows filesystems. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman et...@stoneleaf.us wrote: On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. No, in the *(original use case* (and many other use cases, such as the identity dict) we *do* trust the user data. It is more trustworthy than the key forms used to look up the data inside the program. That's the whole point. (Don't be distracted by Eric's particular use case.) But even for the general case...well, let me repost here what I said on the tracker: In our view, this data structure is for cases where the original key is the most important piece of information (about the keys). The transformation in the lookup process is entirely in the service of looking up the value paired with that original key when there is more than one possible representation of that key. It is the original key that is critical when re-serializing the data or otherwise making use of the keys for anything other than lookup. So this is about making the data structure succinctly model the problem domain, which is what OO is supposed to be good at :) --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On 9 Sep, 2013, at 23:18, Mark Shannon m...@hotpy.org wrote: On 09/09/13 15:30, Ethan Furman wrote: On 07/30/2013 11:17 PM, Ronald Oussoren wrote: And something I forgot to ask: is anyone willing to be the BDFL-Delegate for PEP 447? *Bump*. It would be nice if this could make into 3.4. IMO, there are some issues that need to be addressed before PEP 447 should be accepted. 1. Is there even a problem at all, or is this just a bug in super? Why doesn't super() respect the __getattribute__ method of the superclass? Because __getattribute__ looks in the instance __dict__ before walking the MRO, while super does not. 2. Is this the best way to solve the problem (if there is a problem)? Would a __super__ special method be sufficient and less intrusive. One reason for the __locallookup__ method is to make normal and super attribute lookup more simular, adding a __super__ special method would lead to code duplication: both __getattribute__ and __super__ would either contain simular code, or would call out to a shared method anyway. 3. Are the proposed semantics OK? I think they are, but very low level changes such as these can have unforeseen consequences. For example, PEP 3135 and issue 12370. 4. What is the performance impact. pybench really doesn't count as a benchmark. What kind of benchmark would you like to see? BTW. I ran more than pybench, I also ran the part of the performance benchmark that worked on py3k at the time. Ronald ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 13 September 2013 07:29, Tim Delaney timothy.c.dela...@gmail.com wrote: In this case though, there are two pieces of information: 1. A canonical key (which may or may not equal the original key); 2. The original key. It seems to me then that TransformDict is a specialised case of CanonicalDict, where the canonical key is defined to be the first key inserted. It would in fact be possible (though inefficient) to implement that using a canonicalising callable that maintained state - something like (untested): class OriginalKeys: def __init__(self):: self.keys = CanonicalDict(str.lower) def __call__(self, key): return self.keys.setdefault(key, key) class OriginalKeyDict(CanonicalDict): def __init__(self):: super().__init__(OriginalKeys()) Bah - got myself mixed up with original key and case preserving there ... try this: class OriginalKeys: def __init__(self, func):: self.keys = CanonicalDict(func) def __call__(self, key): return self.keys.setdefault(key, key) class OriginalKeyDict(CanonicalDict): def __init__(self, func):: super().__init__(OriginalKeys(func)) class IdentityDict(OriginalKeyDict): def __init__(self): super().__init__(id) class CasePreservingDict(OriginalKeyDict): def __init__(self): super().__init__(str.lower) Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
On 13 September 2013 01:40, Antoine Pitrou solip...@pitrou.net wrote: Le Thu, 12 Sep 2013 08:05:44 -0700, Ethan Furman et...@stoneleaf.us a écrit : On 09/12/2013 07:43 AM, Antoine Pitrou wrote: Yeah, so this is totally silly. What you're basically saying is we don't need TransformDict since people can re-implement it themselves. No, what I'm saying is that the case-preserving aspect of transformdict is silly. The main point of transformdict is to enable, for example, 'IBM', 'Ibm', and 'ibm' to all match up as the same key. But why? Because you don't trust the user data. And if you don't trust the user data you have to add the correct version of the key yourself before you ever process that data, which means you already have the correct version stored somewhere. That's assuming there is an a priori correct version. But there might not be any. Keeping the original key is important for different reasons depending on the use case: - for case-insensitive dicts, you want to keep the original key for presentation, logging and debugging purposes (*) - for identity dicts, the original key is mandatory because the id() value in itself is completely useless, it's just used for matching (*) For a well-known example of such behaviour, think about Windows filesystems. In this case though, there are two pieces of information: 1. A canonical key (which may or may not equal the original key); 2. The original key. It seems to me then that TransformDict is a specialised case of CanonicalDict, where the canonical key is defined to be the first key inserted. It would in fact be possible (though inefficient) to implement that using a canonicalising callable that maintained state - something like (untested): class OriginalKeys: def __init__(self):: self.keys = CanonicalDict(str.lower) def __call__(self, key): return self.keys.setdefault(key, key) class OriginalKeyDict(CanonicalDict): def __init__(self):: super().__init__(OriginalKeys()) Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote: I don't particularly like __locallookup__ either, but haven't found a better name yet. __lookup_in_class__ was the best alternative I could come up with, and that feels different than other special methods. The name in the PEP is more or less derived from _PyType_Lookup, with local meaning only in this class, don't recurse in the rest of the MRO. How about __typelookup__ ? Surely that's the obvious name to derive from _PyType_Lookup :-) -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Add a transformdict to collections
2013/9/12 Ethan Furman et...@stoneleaf.us: On 09/11/2013 02:39 PM, Tim Delaney wrote: I would think that retrieving the keys from the dict would return the transformed keys (I'd call them canonical keys). The more I think about this the more I agree. A canonicaldict with a key function that simply stored the transformed key and it's value would seem to be a lot simpler: - no need to store a separate presentation key - no confusion about which of the first key/last key seen is stored - no mistakes with the first key not being added before real data and getting the presentation key wrong If original keys aren't stored then d = TransformDict(transfunc, ...) for k in d: dosomething(k, d[k]) will break if transfunc(transfunc(x)) != transfunc(x) -- 闇に隠れた黒い力 弱い心を操る ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On 12 sep. 2013, at 17:30, R. David Murray rdmur...@bitdance.com wrote: On Thu, 12 Sep 2013 16:42:39 +0200, Ronald Oussoren ronaldousso...@mac.com wrote: On 9 Sep, 2013, at 20:23, Jan Kaliszewski z...@chopin.edu.pl wrote: Is '__locallookup__' a really good name? In Python, *local* -- especially in context of *lookups* -- usually associates with locals() i.e. a namespace of a function/method execution frame or a namespace of a class, during *definition* of that class... So '__locallookup__' can be confusing. Why not just '__getclassattribute__' or '__classlookup__', or '__classattribute__'...? I don't particularly like __locallookup__ either, but haven't found a better name yet. __lookup_in_class__ was the best alternative I could come up with, and that feels different than other special methods. The name in the PEP is more or less derived from _PyType_Lookup, with local meaning only in this class, don't recurse in the rest of the MRO. Why is __getclassattribute__ worse than __locallookup__? Getclassattribute feels like it is related to classmethod, or fetches an attribute of a class. The method does however fetch a value from the class that is transformed to the actual attribute value through the descriptor protocol. Ronald --David ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
What about __getlocalattribute__ or __getattributenorecurse__? Long, but this isn't going to be used often. Putting type or class in the name would be misleading. It's an instance method (that is most useful when implemented on a metaclass). (Apologies for the top post.) Sent from my Windows Phone From: Steven D'Apranomailto:st...@pearwood.info Sent: 9/12/2013 16:09 To: python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__ On Thu, Sep 12, 2013 at 04:42:39PM +0200, Ronald Oussoren wrote: I don't particularly like __locallookup__ either, but haven't found a better name yet. __lookup_in_class__ was the best alternative I could come up with, and that feels different than other special methods. The name in the PEP is more or less derived from _PyType_Lookup, with local meaning only in this class, don't recurse in the rest of the MRO. How about __typelookup__ ? Surely that's the obvious name to derive from _PyType_Lookup :-) -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
On Fri, Sep 13, 2013 at 03:04:49AM +, Steve Dower wrote: What about __getlocalattribute__ or __getattributenorecurse__? Long, but this isn't going to be used often. This has nothing to do with locals, nor does it have anything to do with recursion, so both those names are misleading. Putting type or class in the name would be misleading. It's an instance method (that is most useful when implemented on a metaclass). Regardless of whether it is an instance method or not, by default it performs the lookup on the type. Hence the C function _PyType_Lookup and hence my suggestion __typelookup__. But I think that __typelookup__ does describe quite well what the method does. It looks up on the type. The PEP is fairly clear on how this is supposed to work, e.g. the default type.__whatever__ method will look up in the class/type dict. PEP 447 includes an example of how you might implement this in Python: class MetaType(type): def __locallookup__(cls, name): try: return cls.__dict__[name] except KeyError: raise AttributeError(name) from None local lookup doesn't even come close to describing what the method does or why you would use it. It suggests something to do with locals, which is not the case. Neither does __getattributenorecurse__, which suggests looking up an attribute on an object without following the inheritance hierarchy, e.g. looking in the instance __dict__ but not the class __dict__. So the complete opposite of what it actually does. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 447: add type.__locallookup__
Last I checked, looking up in the instance dict us exactly what it does. Even the example you posted is doing that. And the only difference from __getattribute__ is that it throws instead of following the MRO, which is intended to allow base classes (via super, and another call to this method) to dynamically respond to a getattr without the cooperation of subclasses. Consider class A, which knows it has a method F, but will not create it until the first __getattribute__ call. Now class B derives from A, and someone calls super(B).F(obj). Currently, super only looks in __dict__ for F, which will fail to invoke A.__getattribute__. Because super is used to provide MRO traversal, it can't rely on B.__getattribute__ to perform the traversal, so it currently has no choice. The PEP was originally adding a special class method to provide a __getattribute__ equivalent that would not traverse the MRO, so that super could use it and people can create dynamic classes that can act as base classes. I pointed out that this could be an instance method (thereby avoid automatic-classmethod magic) and implemented on a metaclass for the class behavior. Unless the PEP has changed recently, this is still an instance method that will look up members defined directly on the type and not on base classes. There may still be valid questions to answer (such as, should overrides if this method on base classes be inherited), but whether it is a type/class method is no longer one of those. Cheers, Steve Sent from my Windows Phone From: Steven D'Apranomailto:st...@pearwood.info Sent: 9/12/2013 21:00 To: python-dev@python.orgmailto:python-dev@python.org Subject: Re: [Python-Dev] PEP 447: add type.__locallookup__ On Fri, Sep 13, 2013 at 03:04:49AM +, Steve Dower wrote: What about __getlocalattribute__ or __getattributenorecurse__? Long, but this isn't going to be used often. This has nothing to do with locals, nor does it have anything to do with recursion, so both those names are misleading. Putting type or class in the name would be misleading. It's an instance method (that is most useful when implemented on a metaclass). Regardless of whether it is an instance method or not, by default it performs the lookup on the type. Hence the C function _PyType_Lookup and hence my suggestion __typelookup__. But I think that __typelookup__ does describe quite well what the method does. It looks up on the type. The PEP is fairly clear on how this is supposed to work, e.g. the default type.__whatever__ method will look up in the class/type dict. PEP 447 includes an example of how you might implement this in Python: class MetaType(type): def __locallookup__(cls, name): try: return cls.__dict__[name] except KeyError: raise AttributeError(name) from None local lookup doesn't even come close to describing what the method does or why you would use it. It suggests something to do with locals, which is not the case. Neither does __getattributenorecurse__, which suggests looking up an attribute on an object without following the inheritance hierarchy, e.g. looking in the instance __dict__ but not the class __dict__. So the complete opposite of what it actually does. -- Steven ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/steve.dower%40microsoft.com ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
