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

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. 

Cameron Simpson <cs@cskk.id.au>