On Mon, 7 Oct 2019 at 19:19, Cameron Simpson <cs@cskk.id.au> wrote:

On 07Oct2019 10:56, Joao S. O. Bueno <jsbueno@python.org.br> wrote:
>So, in short, your idea is to allow "=" signs inside `[]` get notation to
>be translated
>to dicts on the call,

Subjectively that seems like a tiny tiny win. I'm quite -1 on this idea;
language spec bloat to neglible gain.

>in the same way comma separated values are translated to tuples?

Chris pointed out to me recently that tuples don't need commas, the
commas alone suffice. You see brackets _around_ tuples a lot because of
precedence.

But in the case of index-contents, there _is_ a translation, as the slice syntax
is allowed in any comma separated value inside the `[ ] `, and parsed to a

slice object in the argument received by __getitem__.

So, mixing single values and "named indexes", and slice-parsing apart,

just parsing the "="s in df[axis="y"] to df.__getitem__({"axis": "y"}) seems

to be quite usefull - not only to facilitate slicing and selection in dataframe, or multidimensional

data structures, but also for ORMs, allowing a simple syntax to have filter

expression as data.

I agree that to maximise usability, ideally the syntax should get to the

point of allowing combining "positional" and "named" index parts, and

I think the object that would be passed to __getitem__ in this case

have to be discussed further. But the dictionary idea seems straightforward,

and won't complicate the language specs, as you say - it would just

remoce redundant mark signals in image[{"x": 10, "y": 30] when on types

"image[x=10, y=30]", just as you demonstrate tuples benefit from this

in the continuation of your message.

Now, on another line of though, I think a valid objection is that indeed, when calling a function we get this

and the whole "*" and "**" mechanisms on the calling side and callee side -

and rebuilding all expressiveness of function signatures in index would be too much.

So, maybe, people thinking they need this feature could simply put together

a ".get" method to accepted the named indexes, and all other features

possible with function signatures.

Tuple assignment:

x, y = y, x

Tuple iteration (tuple assignment in a loop):

for x, y in some_dict.items():

Store a tuple in a variable:

t = x, y

Call a function with an int, a tuple and an int:

r = f(1, (2, 3), 4)

Here we put some brakcets in to bind 2,3 as a tuple rather than as
parameters, _no_ different to:

r = 4 * (5 + 7)

here we use brakcets to bind 5+7 together in preference to 4*5.

>I see no backwards syntax incompatibility in that, and the
>tuple-translation is
>indeed quite a helper in many cases.

It isn't a translator, it is merely a situation where a tuple does not
need surrounding brackets to avoid precedence giving a different result.

Cheers,
Cameron Simpson <cs@cskk.id.au>