I think that the most important simple thing with dunder/magic methods is name mangling, and that an abstraction like your proposed one makes it less clear what will happen to a name. Also, as Nick Coghlan pointed out, there are a lot of dunder/magic methods <https://docs.python.org/3/reference/datamodel.html>. Either each of those methods would need an alternate representation, or some would be left out - which would lead to inconsistent style. Maybe I'm resisting change too much, but I think that the solution to this issue is to make the magic method documentation easier to teach, as opposed to changing them.
-Ryan Birmingham On 7 November 2016 at 23:49, Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote: > Nathan Dunn writes: > > > > * the mapping protocol covers more than just __getitem__ > > > > __setitem__(self, key, value) could be def self[key] = value > > likewise > > __delitem__(self, key) def del self[key]: > > __iter__(self) iter(self) > > __len__(self) len(self) > > The template used by last two (BTW, shouldn't they be "def iter(self)" > and "def len(self)"?) seems like a really bad idea to me. This would > imply that any class that defines such methods in some arbitrary > fashion will appear to participate in the corresponding protocol > although it doesn't. That seems likely to result in bugs, that might > be hard to diagnose (haven't thought about how hard that might be, > though). It would require the programmer to know about all such > protocols when designing a public API, while with the dunder > convention, you only need to find out whether the dunders you want to > use for your new protocol are already in use somewhere, and > programmers who aren't designing protocols don't need to know about > them at all. It would also require a modification to the compiler for > every new protocol. > > I personally don't see that the other syntaxes are helpful, either, > but that's a matter of opinion and I'd be interested to hear about > experience with teaching languages that implement such "method > definitions look like invocation syntax". > > Regards, > > _______________________________________________ > 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/
