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>