On Mon, 7 Oct 2019 at 19:19, Cameron Simpson <c...@cskk.id.au> wrote:
> On 07Oct2019 10:56, Joao S. O. Bueno <jsbu...@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 <c...@cskk.id.au>
>
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@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/RZMWU5IOJT5TVYJ3AGBXVVJOQLY4C4H5/
Code of Conduct: http://python.org/psf/codeofconduct/
