On 12/12/05, Guido van Rossum <guido at python.org> wrote:
> Unfortunately that fails one of the other requirements, which (at the
> time of implementation) was minimal impact on the rest of the
> interpreter. Since __private isn't limited to self, and attribute
> lookup doesn't always result in a dict lookup, this would require a
> complete overhaul of the getattr API, both at the C and at the Python
> level.
I hate to flog a dead horse but I feel it's important to clarify my
intentions here. I don't see why it couldn't require a dict.
Immutable builtins will fail either way, and so will classes using
slots (unless they hardcode the required private name). The only
problematic use-case I can think of is a proxy class, but is that
enough to dictate the entire design of the feature?
> But I guess you already said that when you said """Obviously it
> doesn't handle backwards compatibility, so it's more of a "if I could
> do it again.." suggestion."""
I was referring to code which already hardcodes the format of the
current approach, i.e.:
class Foo(object):
def __init__(self):
self.__private = 42
f = Foo()
print f._Foo__private
--
Adam Olsen, aka Rhamphoryncus
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4