keyword-only args in __getitem__
I propose to allow to define keyword-only arguments for __getitem__. The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
Default value is not the only use case. One could for example define a subclass of list computing an interpolation if a float is given as a parameter instead of truncating it, and the keword argument would define which kind of interpolation (nearest, linear, spline...). Or it could define if the value returned are in degrees or radians. (Yes, I have a scientific background.) I use something similar for a dictionary-like interface where the keys are strings and only numbers are stored. The second argument, if given, is the default:
data["key", 0] It would be clearer to use: data["key", default=0] (Of course I could use a get method for this purpose, but bracket for indexing seems always more clear).
The keyword would be keywords-only because right now when many arguments are passed to __getitem__, they are grouped in a tuple and this tuple is passed to __getitem__ as a unique argument. Also it is more clear: ordered arguments are the indexes, keyword arguments are the options. To be perfectly honest I don't think that this proposal is that great, it's main selling point is that a "default" keyword in indexing would be a good alternative for some of the problems raised in PEP 463. Joseph ML --- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
On 4/12/2014 3:28 PM, Joseph Martinot-Lagarde wrote:
I propose to allow to define keyword-only arguments for __getitem__.
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
The problem with this is, as you note below, that everything between [ and ] is turned into a single object passed on to __getitem__. That includes slice notation I:J:I, which is currently only valid in this context. Syntactically, collection indexing is quite different from function calling. (Python could have been defined so that they were the same.) I think it would be better if the key were syntactically separated from a default, say with ;. value = lst[3; 0] I believe any proposal along this line would make dict.getitem obsolete, and eliminate any call for list.getitem.
Default value is not the only use case. One could for example define a subclass of list computing an interpolation if a float is given as a parameter instead of truncating it, and the keword argument would define which kind of interpolation (nearest, linear, spline...).
I think interp should be a method of the subclass.
Or it could define if the value returned are in degrees or radians. (Yes, I have a scientific background.)
.setunit('degrees') with radians the default.
I use something similar for a dictionary-like interface where the keys are strings and only numbers are stored. The second argument, if given, is the default:
data["key", 0] It would be clearer to use: data["key", default=0]
I see data['key'; 0] as an in between compromise. The 0 is separated from the key but without the heavy 'default='.
(Of course I could use a get method for this purpose, but bracket for indexing seems always more clear).
-- Terry Jan Reedy
On 04/12/2014 06:30 PM, Terry Reedy wrote:
On 4/12/2014 3:28 PM, Joseph Martinot-Lagarde wrote:
I propose to allow to define keyword-only arguments for __getitem__.
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
The problem with this is, as you note below, that everything between [ and ] is turned into a single object passed on to __getitem__.
The comma in slice notation does support passing multiple objects to get item. It's used in numpy for multidimensional lookups. I believe there is interest for adding that feature to python, so it may cause an issue with those proposals if the comma is used. But it seems to me a better way to do this may be with default method that returns a view or wrapped object that supplies a default rather than raise an index or key error. lst.default_view(0)[3] Generally you won't use different defaults with the same object that often, so it makes sense to set it early, and then not to have to do anything special in other places the object is used. Cheers, Ron
Le 13/04/2014 19:21, Ron Adam a écrit :
On 04/12/2014 06:30 PM, Terry Reedy wrote:
On 4/12/2014 3:28 PM, Joseph Martinot-Lagarde wrote:
I propose to allow to define keyword-only arguments for __getitem__.
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
The problem with this is, as you note below, that everything between [ and ] is turned into a single object passed on to __getitem__.
The comma in slice notation does support passing multiple objects to get item. It's used in numpy for multidimensional lookups. I believe there is interest for adding that feature to python, so it may cause an issue with those proposals if the comma is used.
But it seems to me a better way to do this may be with default method that returns a view or wrapped object that supplies a default rather than raise an index or key error.
lst.default_view(0)[3]
Generally you won't use different defaults with the same object that often, so it makes sense to set it early, and then not to have to do anything special in other places the object is used.
It may be true for lists as they are supposed to hold objects of the same kind. But for dictionnaries, you may want to have different defaults for each key. For example a dictionary containing the keys 'START', 'STOP' and 'STEP' would have something like 0, None and 1 as defaults.
Cheers, Ron
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
On Sun, Apr 13, 2014 at 5:28 AM, Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> wrote:
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
An interesting idea, but that looks far too much like a function call. Square brackets and then more and more a function call inside... may fail the grit test. Part of the point of except expressions was that the implementation of __getitem__ wouldn't need to have two branches in it. Currently, you need to write __getitem__ (which raises an exception on finding a problem) plus something else, eg get(), which returns a default instead. By your proposal, both branches would go inside __getitem__, which means they could share code; but there still need to be two branches. That's two branches that need to be written, tested, etc, and if the author hasn't thought to handle default=, there's no way to get that functionality, same as if there's no get() method. And just as with the get method, there'll be an ad-hoc and fairly arbitrary puddle of names (some will go "default=", others will say that's way too long and go "def=", except that that's a keyword so they'll use "dflt=" or something...), unless there's a strong force pushing people to one consistent name. Terry's suggestion solves that part of it, but also restricts the feature to just default values; with a more general keyword argument system, it would make sense to also use this with __setitem__ and __delitem__, and I'm not sure how "default value" should be interpreted there. Which is better is, of course, a matter of opinion! :) ChrisA
On 12 Apr 2014 20:54, "Chris Angelico" <rosuav@gmail.com> wrote:
On Sun, Apr 13, 2014 at 5:28 AM, Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> wrote:
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions),
this
would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
An interesting idea, but that looks far too much like a function call. Square brackets and then more and more a function call inside... may fail the grit test.
Part of the point of except expressions was that the implementation of __getitem__ wouldn't need to have two branches in it. Currently, you need to write __getitem__ (which raises an exception on finding a problem) plus something else, eg get(), which returns a default instead. By your proposal, both branches would go inside __getitem__, which means they could share code; but there still need to be two branches. That's two branches that need to be written, tested, etc, and if the author hasn't thought to handle default=, there's no way to get that functionality, same as if there's no get() method. And just as with the get method, there'll be an ad-hoc and fairly arbitrary puddle of names (some will go "default=", others will say that's way too long and go "def=", except that that's a keyword so they'll use "dflt=" or something...), unless there's a strong force pushing people to one consistent name. Terry's suggestion solves that part of it, but also restricts the feature to just default values; with a more general keyword argument system, it would make sense to also use this with __setitem__ and __delitem__, and I'm not sure how "default value" should be interpreted there. Which is better is, of course, a matter of opinion! :)
A getitem() builtin seems like a more obvious parallel with getattr(), and pairs up nicely with operator.itemgetter. Proposals of additional special cases like this is a reasonable outcome of the rejection of the except expressions PEP. Cheers, Nick.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Le 13/04/2014 02:45, Chris Angelico a écrit :
On Sun, Apr 13, 2014 at 5:28 AM, Joseph Martinot-Lagarde <joseph.martinot-lagarde@m4x.org> wrote:
The main use case is to be able to set a default value for indexing. I though about it after reading PEP 463 (Exception-catching expressions), this would be an alternative for one of the problem this PEP is trying to solve. Compare these solutions:
lst = [1, 2, 3] value = lst[3] Traceback (most recent call last): File "<stdin>", line 1, in <module> IndexError: list index out of range try: # Python .... value = lst[3] .... except IndexError: .... value = 0 value = lst[3] except IndexError: 0 # PEP 463 value = lst[3, default=0] # My proposal
An interesting idea, but that looks far too much like a function call. Square brackets and then more and more a function call inside... may fail the grit test.
I tend to see square brackets as a function call but "indexing oriented". Using parenthesis would correspond to calling __call__ while using brackets corresponds to calling __getitem__. And sometimes I'd like to be able to use I:J:K notation for slices in function calls...
Part of the point of except expressions was that the implementation of __getitem__ wouldn't need to have two branches in it. Currently, you need to write __getitem__ (which raises an exception on finding a problem) plus something else, eg get(), which returns a default instead. By your proposal, both branches would go inside __getitem__, which means they could share code; but there still need to be two branches. That's two branches that need to be written, tested, etc, and if the author hasn't thought to handle default=, there's no way to get that functionality, same as if there's no get() method.
Yes the code would be included by the author rather than by the user. Part of the success of python is that it comes with batteries included !
And just as with the get method, there'll be an ad-hoc and fairly arbitrary puddle of names (some will go "default=", others will say that's way too long and go "def=", except that that's a keyword so they'll use "dflt=" or something...), unless there's a strong force pushing people to one consistent name.
Well, this argument would hold against using keywords arguments in any function call.
Terry's suggestion solves that part of it, but also restricts the feature to just default values; with a more general keyword argument system, it would make sense to also use this with __setitem__ and __delitem__, and I'm not sure how "default value" should be interpreted there. Which is better is, of course, a matter of opinion! :)
setitem and delitem don't look like function calls at all IMHO. Keywords arguments for them would be less useful than for getitem.
ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
--- Ce courrier électronique ne contient aucun virus ou logiciel malveillant parce que la protection avast! Antivirus est active. http://www.avast.com
účastníci (5)
-
Chris Angelico -
Joseph Martinot-Lagarde -
Nick Coghlan -
Ron Adam -
Terry Reedy