I haven't agreed to anything. Though last time I thought about this I was in favor of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into `x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__` would do with that is a different issue -- probably it would be an error. On Mon, Aug 3, 2020 at 10:32 AM Todd <toddrjen@gmail.com> wrote:

On Mon, Aug 3, 2020, 13:11 Jonathan Fine <jfine2358@gmail.com> wrote:

...

SUMMARY: Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.

This package is about PEP 472 -- Support for indexing with keyword arguments See: https://www.python.org/dev/peps/pep-0472/

As a result, I think we're now in a good position to try this idea out, using present day Python. This includes building some clients that can use the new feature, should it become available. It also includes exploring the design of the API.

The crucial idea is writing >>> from kwkeys import o >>> d[o(1, 2, a=3, b=4)] as a stopgap, until >>> d[1, 2, a=3, b=4] is available.

If you're interested, please do try it out.

IN MORE DETAIL:

On 3 May 2020, Andras Tontas reopened discussion of the PEP. This PEP was created in June 2014, and closed in March 2019, due to lack of interest. See: https://mail.python.org/pipermail/python-dev/2019-March/156693.html

This time round, things went better. On 16 July, Guido wrote (substitute PEP for PRP)

I think it’s a reasonable idea and encourage you to start working on a

...

design for the API and then a PRP. It would help if someone looked into a prototype implementation as well (once a design has been settled on).

See: https://mail.python.org/archives/list/python-ideas@python.org/message/7MHQYE...

Later on 16 July, I wrote

...

I'll now state some goals.

...

1. Define 'o' and Protocol so that NOW gives the semantics you wish for. 2. Extend Python so that FUTURE give the semantics you wish for. 3. And the NOW syntax continues to work as expected (without changing 'o' and Protocol). 4. And all current use of container[key] continues to work as before.

...

I believe that it is possible to achieve these goals. My previous posts to this discussion outline some of the key ideas. My next step, when I have time, is to implement and publish general purpose code for the NOW part of this list of goals.

See: https://mail.python.org/archives/list/python-ideas@python.org/message/3IWL42...

On 18 July I wrote that by the end of July I would implement and publish general purpose code for the NOW part of these goals See: https://mail.python.org/archives/list/python-ideas@python.org/message/YW3JXK...

Earlier today, 3 days overdue, I fulfilled my commitment. I hope it helps some of you, and does no harm to others. -- Jonathan

Do we have an agreement on the API as Guido requested? From my understanding, and please correct me if I am wrong, you are still talking about implementing this using a new class. However, most people who support the use of labelled indexing.and expressed an opinion support a keyword argument-based approach. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VCFLB4... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

One potential issue with this approach just occurred to me. I apologise if my thinking on this is wrong. Say a project implements __getitem__ with the signature __getitem__(self, index, **kwargs) Doesn't that mean that a "index" will not be an allowable index label, and that this conflict will depend on knowing the particular implementation details of the dunder methods? On Mon, Aug 3, 2020, 13:43 Guido van Rossum <guido@python.org> wrote:

I haven't agreed to anything. Though last time I thought about this I was in favor of Steven D'Aprano's idea of translating `x[1, 2, p=3, q=4]` into `x.__getitem__((1, 2), p=3, q=4)`. What the dict class's `__getitem__` would do with that is a different issue -- probably it would be an error.

On Mon, Aug 3, 2020 at 10:32 AM Todd <toddrjen@gmail.com> wrote:

...

On Mon, Aug 3, 2020, 13:11 Jonathan Fine <jfine2358@gmail.com> wrote:

...

SUMMARY: Some news. I've just published https://pypi.org/project/kwkey/0.0.1/.

This package is about PEP 472 -- Support for indexing with keyword arguments See: https://www.python.org/dev/peps/pep-0472/

As a result, I think we're now in a good position to try this idea out, using present day Python. This includes building some clients that can use the new feature, should it become available. It also includes exploring the design of the API.

The crucial idea is writing >>> from kwkeys import o >>> d[o(1, 2, a=3, b=4)] as a stopgap, until >>> d[1, 2, a=3, b=4] is available.

If you're interested, please do try it out.

IN MORE DETAIL:

On 3 May 2020, Andras Tontas reopened discussion of the PEP. This PEP was created in June 2014, and closed in March 2019, due to lack of interest. See: https://mail.python.org/pipermail/python-dev/2019-March/156693.html

This time round, things went better. On 16 July, Guido wrote (substitute PEP for PRP)

I think it’s a reasonable idea and encourage you to start working on a

...

design for the API and then a PRP. It would help if someone looked into a prototype implementation as well (once a design has been settled on).

See: https://mail.python.org/archives/list/python-ideas@python.org/message/7MHQYE...

Later on 16 July, I wrote

...

I'll now state some goals.

...

1. Define 'o' and Protocol so that NOW gives the semantics you wish for. 2. Extend Python so that FUTURE give the semantics you wish for. 3. And the NOW syntax continues to work as expected (without changing 'o' and Protocol). 4. And all current use of container[key] continues to work as before.

...

I believe that it is possible to achieve these goals. My previous posts to this discussion outline some of the key ideas. My next step, when I have time, is to implement and publish general purpose code for the NOW part of this list of goals.

See: https://mail.python.org/archives/list/python-ideas@python.org/message/3IWL42...

On 18 July I wrote that by the end of July I would implement and publish general purpose code for the NOW part of these goals See: https://mail.python.org/archives/list/python-ideas@python.org/message/YW3JXK...

Earlier today, 3 days overdue, I fulfilled my commitment. I hope it helps some of you, and does no harm to others. -- Jonathan

Do we have an agreement on the API as Guido requested? From my understanding, and please correct me if I am wrong, you are still talking about implementing this using a new class. However, most people who support the use of labelled indexing.and expressed an opinion support a keyword argument-based approach. _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VCFLB4... Code of Conduct: http://python.org/psf/codeofconduct/

-- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>

Yes, that would be correct. However, the function could instead be defined as:

def __getitem__(self, index, /, **kwargs): ...

and then there'd be no conflict (as "self" and "index" must be passed positionally). In effect, the naive spelling (which permits self and index to be passed as keywords) would be a subtle bug that could easily be corrected.

sure, but it would be a bug in a LOT of existing code! I wonder, if this were to be introduced, if the interpreter could have a special case that would call __getitem__ in a special way to avoid this bug in old code. -CHB -- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On Mon, Aug 3, 2020, 17:13 Guido van Rossum <guido@python.org> wrote:

On Mon, Aug 3, 2020 at 1:49 PM Christopher Barker <pythonchb@gmail.com> wrote:

...

Yes, that would be correct. However, the function could instead be

...

defined as:

def __getitem__(self, index, /, **kwargs): ...

and then there'd be no conflict (as "self" and "index" must be passed positionally). In effect, the naive spelling (which permits self and index to be passed as keywords) would be a subtle bug that could easily be corrected.

sure, but it would be a bug in a LOT of existing code!

I wonder, if this were to be introduced, if the interpreter could have a special case that would call __getitem__ in a special way to avoid this bug in old code.

Good edge case to consider. But would it really be such a problem? If you have an existing class like this:

class C: def __getitem__(self, index): ...

c = C()

then presumably calling `c[1, index=2]` would just be an error (since it would be like attempting to call the method with two values for the `index` argument), and ditto for `c[1, 2, 3, index=4]`. The only odd case might be `c[index=1]` -- but presumably that would be equivalent to `c[(), index=1]` so it would still fail.

The problem is that knowing what labels are not allowed would require knowing the implementation details of the dunder methods of each individual class, which I don't think is typically considered public API as far as I am aware.

On 4/08/20 9:12 am, Guido van Rossum wrote:

then presumably calling `c[1, index=2]` would just be an error (since it would be like attempting to call the method with two values for the `index` argument),

Hmmm, does this mean that classes providing index notation would now need to document the name of the parameter they use for the index? -- Greg

Another approach could be too simply pass the labelled indices in a dict as a third/fourth positional argument. So for indexing b = arr[1, 2, a=3, b=4] Instead of __getitem__(self, (1, 2), a=3, b=4) Just do __getitem__(self, (1, 2), {'a': 3, 'b': 4}) On Mon, Aug 3, 2020, 16:46 Christopher Barker <pythonchb@gmail.com> wrote:

Yes, that would be correct. However, the function could instead be defined

...

as:

def __getitem__(self, index, /, **kwargs): ...

and then there'd be no conflict (as "self" and "index" must be passed positionally). In effect, the naive spelling (which permits self and index to be passed as keywords) would be a subtle bug that could easily be corrected.

sure, but it would be a bug in a LOT of existing code!

I wonder, if this were to be introduced, if the interpreter could have a special case that would call __getitem__ in a special way to avoid this bug in old code.

-CHB

-- Christopher Barker, PhD

Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/GL3ZVH... Code of Conduct: http://python.org/psf/codeofconduct/

On Mon, Aug 03, 2020 at 05:51:58PM -0400, Ricky Teachey wrote:

However I'll also point out that another idea from Jonathan Fine has the potential to fix both this problem and the key object signature problem, which is what he called a "SIGNATURE CHANGING ADAPTER".

...

Here's how it goes. First we write class D: @wibble def __setitem__(self, val, u, v, x, y): pass # Or do something.

Next, we define wibble. It will be a SIGNATURE CHANGING ADAPTER. Those who know how to make decorators will, I hope, have little difficulty in defining wibble to do what is required. For this exercise, assume that k.argv = (1, 2), and k.kwargs = dict(x=3, y=4).

Good news! Thanks to Guido's time machine, Python already supports this signature changing adapter for functions and methods. All you have to do is *leave the decorator out*. In fact you don't even have to define it at all. The Python interpreter already knows how to match up keyword arguments like `u=35` and their associated parameters `u`. So we don't have to duplicate the argument parsing logic of the interpret in a decorator. We just have to let the interpreter do its thing like it already does. This is (almost) as flexible as you want: Want your keyword arguments to be optional? Define them with a default. Want them to be mandatory? No default. Want to accept arbitrary keyword arguments? Include a `**kwargs` parameter. Want all of your keywords bundled together? Use only a `**kwargs` parameter. The only limitation is that subscripting syntax bundles all positional arguments into a single parameter, for reasons lost deep in the mists of time. But that doesn't affect keyword parameters. -- Steven

On 4/08/20 1:16 pm, Steven D'Aprano wrote:

Why would we want to even consider a new approach to handling keyword arguments which applies only to three dunder methods, `__getitem__`, `__setitem__` and `__delitem__`, instead of handling keyword arguments in the same way that every other method handles them?

These methods are already kind of screwy in that they don't handle *positional* arguments in the usual way -- packing them into a tuple instead of passing them as individual arguments. I think this is messing up everyone's intuition on how indexing should be extended to incorporate keyword args, or even whether this should be done at all. -- Greg

Thank you all for your posts. I'm busy now and for the next few days, so have little time to respond. Here's some comments and suggestions. I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan will take a special interest in this post. In the previous thread, these people saw that the proposed new syntax d[1, 2, a=3, b=4] would bring benefits to their own particular use of Python. (Apologies for any omitted names or misunderstanding of posts). I hope the package kwkey shows that it is possible now to write from kwkey import o d[o(1, 2, a=3, b=4)] as a workable present day substitute for the proposed syntax d[1, 2, a=3, b=4] I think using this can safely go ahead, even though there may be disagreements on the meaning of 'o' and the implementation of classes that take advantage of the new syntax. Indeed, I think going ahead now will contribute to understanding and resolving the disagreements, by creating a shared experience. I suggest that those who previously suggested uses for the proposed syntax now implement some examples. (I give a list below.) They can do this using my API, Steven's API, or any other API. Or indeed now, using the return value of 'o' directly. I've started this process with a toy example: https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py Here are three aspects to the proposed syntax. They are all important, and good design will balance between the various parts and interests. First, ordinary programmers, who perhaps want d[1, 2] d[x=1, y=2] d[1, y=2] d[y=2, x=1] to all be equivalent, for d a mapping of whose domain is points in the x-y plane. More complicated examples might be found in function annotations (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini), networkx (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd, Stephan Hoyer). Second, there are those who implement classes that make use of the proposed syntax. Third, there are those who implement the extension of Python that allows d[o(1, 2, a=3, b=4)] to be replaced by d[1, 2, 3, 4] I suggest that those who see benefits in feature produce experimental implementations via kwkey, just as I did in my kwkey.example_jfine. It is possible to do this now, and so have benefits now, in a way that is reasonably future proof regarding implementation of the proposed new syntax. If you're a user of kwkey, I will have some time available to help you if you want it. I hope this helps some, and harms none. -- Jonathan

On Wed, Aug 5, 2020 at 3:01 PM Stefano Borini <stefano.borini@gmail.com> wrote:

Maybe I should open a new PEP?

I"ll let teh PEP editors decide, but it look slike it was "rejected"m with this comment: "The idea never seemed to gain any traction over its near 5 years in existence as a PEP." So I'd think re-opening it would be fine -- rather than clutter up the PEP namespace... Maybe we could use a "suspended" status for PEPs? -CHB On Tue, 4 Aug 2020 at 14:26, Jonathan Fine <jfine2358@gmail.com> wrote:

...

Thank you all for your posts. I'm busy now and for the next few days, so

have little time to respond. Here's some comments and suggestions.

...

I hope that Andras, Caleb, Stefano, Neil, Joao Bueno, Todd and Stephan

will take a special interest in this post. In the previous thread, these people saw that the proposed new syntax

...

d[1, 2, a=3, b=4] would bring benefits to their own particular use of Python. (Apologies

for any omitted names or misunderstanding of posts).

...

I hope the package kwkey shows that it is possible now to write from kwkey import o d[o(1, 2, a=3, b=4)] as a workable present day substitute for the proposed syntax d[1, 2, a=3, b=4]

I think using this can safely go ahead, even though there may be

disagreements on the meaning of 'o' and the implementation of classes that take advantage of the new syntax. Indeed, I think going ahead now will contribute to understanding and resolving the disagreements, by creating a shared experience.

...

I suggest that those who previously suggested uses for the proposed

syntax now implement some examples. (I give a list below.) They can do this using my API, Steven's API, or any other API. Or indeed now, using the return value of 'o' directly.

...

I've started this process with a toy example:

https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py

...

Here are three aspects to the proposed syntax. They are all important,

and good design will balance between the various parts and interests.

...

First, ordinary programmers, who perhaps want d[1, 2] d[x=1, y=2] d[1, y=2] d[y=2, x=1] to all be equivalent, for d a mapping of whose domain is points in the

x-y plane. More complicated examples might be found in function annotations (Andras Tantos, Caleb Donovick), quantum chemistry (Stefano Borini), networkx (Neil Girdhar), numpy and pandas (Joao Bueno), xarrary (Todd, Stephan Hoyer).

...

Second, there are those who implement classes that make use of the

proposed syntax.

...

Third, there are those who implement the extension of Python that allows d[o(1, 2, a=3, b=4)] to be replaced by d[1, 2, 3, 4]

I suggest that those who see benefits in feature produce experimental

implementations via kwkey, just as I did in my kwkey.example_jfine. It is possible to do this now, and so have benefits now, in a way that is reasonably future proof regarding implementation of the proposed new syntax.

...

If you're a user of kwkey, I will have some time available to help you

if you want it.

...

I hope this helps some, and harms none. -- Jonathan

-- Kind regards,

Stefano Borini _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QK3YV3... Code of Conduct: http://python.org/psf/codeofconduct/

-- Christopher Barker, PhD Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython

On 4/08/20 9:20 am, Todd wrote:

Another approach could be too simply pass the labelled indices in a dict as a third/fourth positional argument.

Has anyone suggested attaching the keyword args as attributes on the slice object? This would avoid changing the signature of __getitem__, and existing __getitem__ methods would just ignore the keyword args. -- Greg

Hi Todd You wrote:

Do we have an agreement on the API as Guido requested? From my understanding, and please correct me if I am wrong, you are still talking about implementing this using a new class. However, most people who support the use of labelled indexing.and expressed an opinion support a keyword argument-based approach.

Thank you for your prompt and close interest. For clarity, I don't think we have agreement on the API. (While I was writing this message, Guido posted a similar view.) I see my kwargs package as a way of exploring the design of the API. To help, let me give you a guided tour of some of the files in the package. You'll find the following code from .jfine import key_to_jfine Point = namedtuple('Point', ('x', 'y')) class PointMap(dict): @key_to_jfine def __setitem__(self, val, x, y): pnt = Point(x, y) dict.__setitem__(self, pnt, val) in https://github.com/jfine2358/python-kwkey/blob/master/kwkey/example_jfine.py The decorator key_to_jfine comes from the kwkey.jfine submodule. It implements the API that I favour. This is my first contribution to the exploration of the API. The kwkey.sdaprano implements, I believe, the API that Steven D'Aprano favours. I believe that from this he (or anyone else such as you) can similarly implement example_sdaprano, example_todd and so forth. Also implemented are kwkeys.test_jfine and kwkey.test_sdaprano submodules. Although a bit cryptic, they do show what is going on. For example, jfine gives # Arguments passed to setitem. >>> d[o(1, 2, a=3, b=4)] = 'val' (('val', 1, 2), {'a': 3, 'b': 4}) while sdaprano gives # Arguments passed to setitem. >>> d[o(1, 2, a=3, b=4)] = 'val' ((1, 2), 'val', {'a': 3, 'b': 4}) In case it's needed, the current tree, referred to above, is https://github.com/jfine2358/python-kwkey/tree/81817ec01a3f0dbb46897df3f6d81... Many thanks to Ricky Teachey, who discovered the resources above, and who kindly wrote I'm really interested in this and it's very helpful that you included two

versions of the proposed API for people to try out: the jfine version (with the kw object) and the stevedaprano version (with kwd arguments passed directly to the dunder methods).

This is I think nicely explained. (Nitpick. I called it sdaprano.py, to align with jfine.py.) I think it would be really helpful if Steven could confirm or correct my implementation of his proposed API. I think it would also be really helpful to have an example that uses his API. It needn't be the same example as the one I've written. I hope this helps (and does no harm). -- Jonathan

Hi Todd You wrote: I guess the thing I don't understand is why you favor that API. Could you

please explain what you think are the advantages of your approach, ideally with some examples where you think your approach is clearer?

I've created a github issue for this, which I'll answer here. https://github.com/jfine2358/python-kwkey/issues/1 In kwkey, I provide 3 interfaces, namely the 'o' and 'K' interface, the jfine interface, and the sdaprano interface. I will explain my reasons, in that order. Recall that we wish to emulate d[1, 2, a=3, b=4] in current Python. I use d[o(1, 2, a=3, b=4)] as a present day syntax that emulates the future syntax. I think this is sufficiently obvious, as to not require explanation. When there are keyword arguments, 'o' gives an object of a new type, namely 'K'. The reason is backwards compatibility. Suppose instead >>> key = o(1, 2, a=3, b=4) >>> key == ((1, 2), dict(a=3, b=4)) True Now suppose that the expression d[(1, 2), dict(a=3, b=4)] appears in legacy code. Because it's legacy code, it can't represent d[1, 2, a=3, b=4] in the new syntax. But how can I distinguish it? That's why I introduce a new class 'K'. It's worth saying that 'o' used the K class only when it has to. This is to give legacy compatibility. Today, d[1, 2] d[(1, 2)] are equivalent. To finish on 'o' and 'K', so far as I can see, what I've done 1. Provides all information that would be available from a minimal syntax extension. 2. Doesn't provide any information beyond that (hence K used only when necessary). 3. It continues to work with an ordinary dict. 4. The C-Python implementation is minimal (provided adding K isn't too hard). Now for the jfine interface, implemented by key_to_jfine signature changing decorator. Here I give what I think is a straightforward interface (for the function wrapped by the decorator) that will provide many programmers with an interface that is straightforward to use. In particular, for setitem the signature is fn(self, val, *key.argv, **dict(key.kwargs)) If you don't like the signatures you provide, choose your own signatures, and then if you wish to write a signature changing decorator. Now for the sdaprano interface, implemented by the key_to_sdaprano signature changing decorator. Here I provide an interface to what is my understanding of Steven's proposal. This is so he and others can use it if they wish. By the way, as previously noted d[1, 2] d[(1, 2)] are at present equivalent. However, in the new syntax d[1, 2, a=3] d[(1, 2), a=3] are not equivalent. (The first has three arguments, the second two, the first of which is a tuple.) Finally, as to which interface is the better, I have as the implementer of kwkey tried to be neutral as to the various interfaces. I hope this helps. If you wish, please ask for more information or help. -- Jonathan

On 2020-08-06 14:16, Stestagg wrote:

I was following you right up till this bit:

By the way, as previously noted     d[1, 2]     d[(1, 2)] are at present equivalent. However, in the new syntax     d[1, 2, a=3]     d[(1, 2), a=3] are not equivalent. (The first has three arguments, the second two, the first of which is a tuple.)

In the "New syntax", wouldn't these examples map to:

d[1, 2, a=3]  =>  d.__getitem__((1, 2), a=3) and d[(1, 2), a=3]  =>  d.__getitem__((1, 2), a=3)

Not quite. The second should be: d[(1, 2), a=3] => d.__getitem__(((1, 2),), a=3)

I.e. My understanding was that the existing conversion of all positional parameters in a subscript would be packed into a tuple (strictly for consistency with legacy behaviour) while any keywords would be passed as kwargs?

On Thu, Aug 06, 2020 at 02:46:01PM +0100, MRAB wrote:

On 2020-08-06 14:16, Stestagg wrote:

...

In the "New syntax", wouldn't these examples map to:

d[1, 2, a=3]  =>  d.__getitem__((1, 2), a=3) and d[(1, 2), a=3]  =>  d.__getitem__((1, 2), a=3)

That is certainly what I would expect. All positional arguments are packed into a single positional parameter, and any keyword arguments passed separately. Any current subscript dunder is likely to look like this: def __getitem__(self, index): # or key, whatever i.e. it will only have a single positional argument. (Aside from self of course.)

Not quite. The second should be:

d[(1, 2), a=3] => d.__getitem__(((1, 2),), a=3)

Aside from the keyword argument, which is a syntax error, that's not what happens now. py> class Demo: ... def __getitem__(self, index): ... print(index, type(index)) ... py> d = Demo() py> d[(1, 2)] # Tuple single arg. (1, 2) <class 'tuple'> py> d[1, 2] # Still a tuple. (1, 2) <class 'tuple'> Adding a keyword arg should not change this. [Stestagg]

...

I.e. My understanding was that the existing conversion of all positional parameters in a subscript would be packed into a tuple (strictly for consistency with legacy behaviour) while any keywords would be passed as kwargs?

To be clear, a single argument is not packed into a tuple. I think that what is actually going on is a matter of precedence. Commas do double duty, separating arguments in calls and creating tuples. Inside a function call, the argument separate takes priority: func(1, 2, 3) is interpreted as three arguments separated by commas. If you want a tuple, you need to change the priority by using round brackets: func((1, 2, 3)) But inside a subscript, there is currently no concept of multiple arguments. There's always only one item, and commas just have their normal meaning of creating a tuple. I think that's how it works, but I'm not quite good enough at reading the grammar specs to be sure. https://docs.python.org/3/reference/grammar.html -- Steven

On Fri, 7 Aug 2020 at 14:14, Jonathan Fine <jfine2358@gmail.com> wrote:

At present d[1, 2] d[(1, 2)] are semantically equivalent.

There is a proposal, that d[1, 2, a=3, b=4] d[(1, 2), a=3, b=4] be semantically equivalent.

I find this troubling, for example because fn(1, 2, a=3, b=4) fn((1, 2), a=3, b=4) are semantically different.

I think I've understood your point. To be sure, what's the Steven proposal?

On 2020-08-07 13:13, Jonathan Fine wrote:

We are discussing a proposal to extend Python's syntax to allow     d[1, 2, a=3, b=4]

We are also discussing the associated semantics. At present     d[1, 2]     d[(1, 2)] are semantically equivalent.

Python behaves as though it's wrapping parentheses around the index: d[1, 2] => d[(1, 2)] d[(1, 2)] => d[((1, 2))] == d[(1, 2)]

There is a proposal, that     d[1, 2, a=3, b=4]     d[(1, 2), a=3, b=4] be semantically equivalent.

Will adding keyword arguments break existing code? No, because they're currently not allowed. Python doesn't even allow you to unpack with *, so that won't break existing code either. [snip]