On Fri, Feb 10, 2017 at 12:11:46PM -0600, Steve Dower wrote:
> When you apply the "what if everyone did this" rule, it looks like a
> bad idea (or alternatively, what if two people who weren't expecting
> anyone else to do this did it).
When you apply that rule, Python generally fails badly. In theory,
Python is the worst possible language to be programming in, because the
introspection capabilities are so powerful, the data hiding so feeble,
the dynamicism of the language so great that almost anything written in
pure-Python can be poked and prodded, bits deleted and new bits
inserted. Python doesn't even have constants!!!
import math
math.pi = 3.0 # change the very geometry of spacetime
And yet, in practice this is a problem more in theory than in practice.
While you are right to raise this as a possible disadvantage of the
proposal ("may ever-so-slightly encourage monkey-patching, by making it
seem ever-so-slightly less mucky") I don't think you are right to weigh
it as heavily as you appear to be doing.
Python has had setattr() forever, and the great majority of Python
programmers manage to avoid abusing it.
> Monkeypatching is fairly blatantly taking advantage of the object
> model in a way that is not "supported" and cannot behave well in the
> context of everyone doing it, whereas inheritance or mixins are safe.
That's an extremely optimistic view of things.
Guido has frequently eluded to the problems with inheritance (you can't
just inherit from anything and expect your code to work), and he's
hardly the only one that has pointed out that inheritance and OOP hasn't
turned out to be the panacea that people hoped. As for mixins, Michele
Simionato has written a series of blog posts about the dangers of mixins
and multiple inheritance, and suggesting traits as a more restricted and
safer alternative. Start here:
http://www.artima.com/weblogs/viewpost.jsp?thread=246488
> Making a dedicated syntax or decorator for patching is saying that we
> (the language) think you should do it.
We already have that syntax:
anything.name = thing
> (The extension_method decorator
> sends exactly the wrong message about what it's doing.)
Are you refering to a decorator something like this?
@extend(TheClass)
def method(self, arg):
...
assert TheClass.method is method
Arguments about what it should be called aside, what is the wrong
message you see here?
> Enabling a __class__ variable within the scope of the definition would
> also solve the motivating example,
Can you elaborate on that a bit more?
Given the current idiom for injecting a method:
class MyClass:
...
# Later on...
def method(self, arg):
...
MyClass.method = method
del method
where does the __class__ variable fit into this?
--
Steve
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
