Had not this been discussed here earlier this year? (And despite there being perceived dangers to readability in the long term, was accepted?)
Here it is on an archive: https://mail.python.org/pipermail/python-ideas/2017-February/044551.html And anyway - along that discussion, despite dislikng the general idea, I got convinced that creating an outside method that makes "super" or "__class__" work was rather complicated. Maybe we could just have a decorator for that, that would properly create the __class__ cell? js -><- On 4 August 2017 at 08:32, Steven D'Aprano <st...@pearwood.info> wrote: > Hi Paul, and welcome! > > > On Fri, Aug 04, 2017 at 07:39:56AM +0000, Paul Laos wrote: > > Hi folks > > I was thinking about how sometimes, a function sometimes acts on > classes, and > > behaves very much like a method. > > I'm not really sure what you mean by "acts on classes". I can only think > of a function which takes a class as a parameter, and modifies the > class. Like a class decorator. Or possibly a classmethod. But that's not > what you seem to mean below. So I'm not quite certain I understand your > proposal. > > > > Adding new methods to classes existing classes > > is currently somewhat difficult, > > If the class is written in Python, it isn't difficult at all, it is > trivially easy. First define your method: > > def method(self, arg): > pass > > > Then inject it onto the class using ordinary attribute assignment: > > TheClass.method = method > > And we're done! > > If the class is a built-in, or otherwise written in C, then "somewhat > difficult" is an understatement. I think it can't be done at all. > > > > and having pseudo methods would make that easier. > > I'm not sure that "easier" in this case would be better. > > > > Code example: (The syntax can most likely be improved upon) > > def has_vowels(self: str): > > for vowel in ["a", "e,", "i", "o", "u"]: > > if vowel in self: return True > > > How does Python, and for that matter the human reader, know which > class or classes that method is injected into? My guess is it looks at > the annotation. But that's a big change: annotations are currently > guaranteed to have no runtime semantics (apart from being stored in the > function's __annotation__ attribute). I'm not saying that can't be done, > but there may be consequences we haven't thought of. > > If we say dir(str), will "has_vowels" show up? > > How about vars(str)? > > How does this interact with metaclasses? > > > > > This allows one to wring `string.has_vowels()` instead of > `has_vowels(string)`, > > which would make it easier to read, > > Well that's one opinion. > > > > and would make it easier to add > > functionality to existing classes, without having to extend them. This > would be > > useful for builtins or imported libraries, so one can fill in "missing" > methods. > > http://www.virtuouscode.com/2008/02/23/why-monkeypatching- > is-destroying-ruby/ > > I think monkeypatching is great, so long as I'm the only one that does > it. When other people do it, invariably they introduce bugs into my code > by monkeypatching other things I didn't expect to be monkeypatched. > > > > * Simple way to extend classes > > * Improves readability > > * Easy to understand > > I'll agree with the first one of those, if by "simple" you mean > "somebody else did all the work to make this syntax do > what I want it to do". > > The work behind the scenes is not likely to be simple: for starters, > allowing monkeypatching of built-ins is likely going to require a rather > big re-design of the Python interpreter. > > > -- > 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/ >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
