4 ms·

probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypat

probably needs written in C because built-in types are closed "Everything is an object" does not necessarily imply "all objects are always infinitely monkeypatchable at all times". It also doesn't necessarily imply "you can change how the parser interprets literals". You're also going to be really mad when you learn about __init_subclass__ and the fact that Python lets you write a class that can't be subclassed!

brudgers 8y ago
Python doesn't make me mad. It's frustrating because it's design never makes any sense to me. __init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is not the name in the source, and the name is not anonomized. I can see a rationale for making some methods private. I can see a rationale for making no methods private. Python doesn't make methods private and then deliberately makes it hard to reap the benefits of this design decision. Instead of implementing the design intent of private methods, what gets implemented are impediments to utilizing the absence of private methods.
- ubernostrum 8y ago
  Mangling of double-underscore names isn't there to provide access control like in Java or C++. Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from. That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway. Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.

brudgers 8y ago

Python doesn't make me mad. It's frustrating because it's design never makes any sense to me. __init_subclass__ is a perfect example. Not at the level of what __init_subclass__ does. But that instead of implementing private methods, there's are rules around double underscore methods and double underscore methods have different behavior (name mangling). They don't actually make the method private, the actual name is not the name in the source, and the name is not anonomized. I can see a rationale for making some methods private. I can see a rationale for making no methods private. Python doesn't make methods private and then deliberately makes it hard to reap the benefits of this design decision. Instead of implementing the design intent of private methods, what gets implemented are impediments to utilizing the absence of private methods.

ubernostrum 8y ago
Mangling of double-underscore names isn't there to provide access control like in Java or C++. Mangling of double-underscore names is explicitly documented as existing "to avoid name clashes of names with names defined by subclasses". The use case there is a parent class defines a method called, say, "foo". Other methods of the parent call self.foo(). Then a subclass overrides foo() but changes the signature (say, by adding a new non-optional argument), and doesn't override the other methods that call self.foo(). Without name mangling or something like it, this breaks. If the parent class either names the method "__foo" or aliases a copy of the parent class' implementation to "__foo", and calls self.__foo(), name mangling ensures those calls will find the right (as in, compatible) implementation of the method based on where the call came from. That's it. That's the one and only use case for invoking name mangling in Python, and it's a thing that generally you shouldn't be doing anyway. Name mangling also isn't invoked for leading + trailing double underscore -- a "__foo__()" method would not get mangled.