On Tue, Aug 04, 2020 at 10:58:51AM -0400, Todd wrote:
> My main issue with this is that, in my opinion, dunders are not something a
> beginner should be messing with anyway. By the time someone is experienced
> enough to start working on this, they are also experienced enough to
> understand that special cases like this exist for historical reasons.
Define "beginner".
I'm serious -- beginners to Python vary from eight year olds who have
never programmed before, to people with fifty years of programming
experience in a dozen different languages aside from Python.
I'm not going to teach newcomers to programming object oriented
techniques in the first day, but as soon as a programmer wants to create
their own class, they will surely need to understand how to write
dunders.
> > Another reason: it could make writing code for specialized libraries that
> > tend to abuse (for the good of us all!) item dunders, like pandas, much
> > easier. Right now such libraries have to rely on their own efforts to break
> > up a key:
> >
> > def __getitem__(self, key):
> > try:
> > k1, k2 = key
> > except TypeError:
> > raise TypeError("two tuple key required")
[...]
> But this is still a pretty simple piece of code. Is it worth having
> everyone start over from scratch to avoid dealing with 4 lines of code?
This proposal doesn't say anything about reversing the decision made all
those years ago to bundle all positional arguments in a subscript into a
single positional parameter. What's done is done, that's not going to
change.
Nobody has to start over from scratch. Nobody needs to change a single
line of code unless they want to add support for keyword arguments to
their class, and only some classes will do that. This proposal is
completely 100% backwards compatible except that what was a SyntaxError
turns into a TypeError:
obj[param=value]
TypeError: __getitem__ got an unexpected keyword argument 'param'
(or something like that).
--
Steven
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/COBN6JPXGUPMIZYOOKEC4T4L2UT6B2SD/
Code of Conduct: http://python.org/psf/codeofconduct/
