On Fri, Jul 04, 2014 at 08:20:18PM +0200, Oleg Broytman wrote:
On Fri, Jul 04, 2014 at 08:10:51PM +0200, Stefano Borini stefano.borini@ferrara.linux.it wrote:
C1. a[Z=3] -> idx = {"Z": 3} C2. a[Z=3, R=4] -> idx = {"Z"=3, "R"=4}Huh? Shouldn't it be C2. a[Z=3, R=4] -> idx = {"Z": 3, "R": 4}
yes. typo. already fixed in the PEP
Cons: - degeneracy of a[{"Z": 3, "R": 4}] with a[Z=3, R=4], but the same degeneracy exists for a[(2,3)] and a[2,3].
There is no degeneration in the second case. Tuples are created by commas, not parentheses (except for an empty tuple), hence (2,3) and 2,3 are simply the same thing.
We discussed this point above in the thread, and you are of course right in saying so, yet it stresses the fact that no matter what you pass inside those square brackets, they always end up funneled inside a single object, which happens to be a tuple that you just created
While Z=3, R=4 is far from being the same as {"Z": 3, "R": 4}.
but dict(Z=3, R=4) is the same as {"Z": 3, "R": 4}. this is exactly like tuple((2,3)) is the same as (2,3) See the similarity? the square brackets "call a constructor" on its content. This constructor is tuple if entries are not key=values (except for the single index case, of course), and dict if entries are key=values.
On Fri, Jul 04, 2014 at 08:34:24PM +0200, Stefano Borini stefano.borini@ferrara.linux.it wrote:
On Fri, Jul 04, 2014 at 08:20:18PM +0200, Oleg Broytman wrote:
Z=3, R=4 is far from being the same as {"Z": 3, "R": 4}.
but dict(Z=3, R=4) is the same as {"Z": 3, "R": 4}. this is exactly like tuple((2,3)) is the same as (2,3) See the similarity? the square brackets "call a constructor" on its content. This constructor is tuple if entries are not key=values (except for the single index case, of course), and dict if entries are key=values.
I didn't like the idea from the beginning and I am still against it.
d = dict a[d(Z=3, R=4)]
looks good enough for me without adding any magic to the language.
Oleg.
On Fri, Jul 04, 2014 at 08:34:24PM +0200, Stefano Borini wrote:
but dict(Z=3, R=4) is the same as {"Z": 3, "R": 4}. this is exactly like tuple((2,3)) is the same as (2,3) See the similarity? the square brackets "call a constructor" on its content. This constructor is tuple if entries are not key=values (except for the single index case, of course), and dict if entries are key=values.
On this regard, one can of course do
idx=(2,3) print(a[idx])
idx={"x":2, "y":3} print(a[idx])
the above syntax is already legal today, and calls back to a comment from a previous post. keywords would just be a shorthand for it.
1. I think you absolutely *must* address the option of purely syntactic sugar in the PEP. It will come up on python-dev, so address it now.
a[b, c=f, e=f:g:h] -> a[b, 'c':d, 'e':slice(f, g, h)]
The rationale is readability and being both backwards and forwards compatible - existing __getitem__ designed to abuse slices will continue to work, and __getitem__ designed to work with the new syntax will work by abusing slices in older versions of Python.
Pandas could be cited as an example of an existing library that could potentially benefit. It would be good if there were precise examples of Pandas syntax that would benefit immediately, but I don't know it beyond a cursory glance over the docs. My gut feeling from that is that if the syntax were available Pandas might be able to use it effectively.
2. I think you're at the point that you need to pick a single option as your preferred option, and everything else needs to be in the alternatives.
FWIW, I would vote:
+1 for syntax-sugar only (zero backwards-compatibility concerns). If I were starting from scratch this would not be my preferred option, but I think compatibility is important.
+0 for a keyword(key, value) parameter object i.e.
a[b, c=d, e=f:g:h] -> a[b, keyword('c', d), keyword('e', slice(f, g, h))]
My objection is that either __getitem__ will be more complicated if you want to support earlier versions of Python (abuse slices for earlier versions, use keyword object for current) or imposes an additional burden on the caller in earlier versions (need to create a keyword-equivalent object to call with). If we were starting from scratch this would be one of my preferred options.
-1 to any option that loses the order of the parameters (I'm strongly in favour of bringing order to keyword arguments - let's not take a backwards step here).
-0 to any option that doesn't allow arbitrary ordering of positional and keyword arguments i.e. any option where the following is not legal:
a[b, c=d, e]
This is something we can do now (albeit in a fairly verbose way at times) and I think restricting this is likely to remove options for DSLs, etc.
-0 for namedtuple (BTW you might want to mention that collections.namedtuple() already has precedent for _X positional parameter names)
My objection is that it's not possible to determine definitively in __getitem__ if the the call was:
a[b, c]
or
a[_0=b, _1=c]
which might be important in some use cases. The same objection would apply to passing an OrderedDict (but that's got additional compatibility issues).
Cheers,
Tim Delaney
On 07/04/2014 01:10 PM, Tim Delaney wrote:
- I think you absolutely *must* address the option of purely syntactic
sugar in the PEP. It will come up on python-dev, so address it now.
a[b, c=f, e=f:g:h] -> a[b, 'c':d, 'e':slice(f, g, h)]
+1 for syntax-sugar only (zero backwards-compatibility concerns).
Also +1 for this approach.
-- ~Ethan~
On Fri, Jul 4, 2014 at 9:10 PM, Tim Delaney timothy.c.delaney@gmail.com wrote:
- I think you absolutely *must* address the option of purely syntactic
sugar in the PEP. It will come up on python-dev, so address it now.
a[b, c=f, e=f:g:h] -> a[b, 'c':d, 'e':slice(f, g, h)]The rationale is readability and being both backwards and forwards compatible - existing __getitem__ designed to abuse slices will continue to work, and __getitem__ designed to work with the new syntax will work by abusing slices in older versions of Python.
I don't know of any existing code that abuses slices in this way (so worrying about compatibility with it seems odd?).
Pandas could be cited as an example of an existing library that could potentially benefit. It would be good if there were precise examples of Pandas syntax that would benefit immediately, but I don't know it beyond a cursory glance over the docs. My gut feeling from that is that if the syntax were available Pandas might be able to use it effectively.
Your hack (aside from being pointlessly ugly) would actually prevent pandas from using this feature. In pandas, slices like foo["a":"b"] already have a meaning (i.e., take all items from the one labeled "a" to the one labeled "b").
-n
On 5 July 2014 06:39, Nathaniel Smith njs@pobox.com wrote:
On Fri, Jul 4, 2014 at 9:10 PM, Tim Delaney timothy.c.delaney@gmail.com wrote:
- I think you absolutely *must* address the option of purely syntactic
sugar in the PEP. It will come up on python-dev, so address it now.
a[b, c=f, e=f:g:h] -> a[b, 'c':d, 'e':slice(f, g, h)]The rationale is readability and being both backwards and forwards compatible - existing __getitem__ designed to abuse slices will continue
to
work, and __getitem__ designed to work with the new syntax will work by abusing slices in older versions of Python.
pandas from using this feature. In pandas, slices like foo["a":"b"] already have a meaning (i.e., take all items from the one labeled "a" to the one labeled "b").
If that's the case then it should be listed as a reason in the PEP for a change larger than syntax sugar, otherwise this important information will be lost.
One of the first suggestions when this PEP came up was to just (ab)use slices - people will use the syntax they have available to them.
Tim Delaney
On 07/04/2014 01:39 PM, Nathaniel Smith wrote:
On Fri, Jul 4, 2014 at 9:10 PM, Tim Delaney wrote:
Your hack (aside from being pointlessly ugly) would actually prevent pandas from using this feature. In pandas, slices like foo["a":"b"] already have a meaning (i.e., take all items from the one labeled "a" to the one labeled "b").
Isn't that the standard way slices are supposed to be used though? Instead of integers Panda is allowing strings. How would Pandas use the new feature?
-- ~Ethan~
On 5 July 2014 07:07, Ethan Furman ethan@stoneleaf.us wrote:
On 07/04/2014 01:39 PM, Nathaniel Smith wrote:
On Fri, Jul 4, 2014 at 9:10 PM, Tim Delaney wrote:
Your hack (aside from being pointlessly ugly) would actually prevent pandas from using this feature. In pandas, slices like foo["a":"b"] already have a meaning (i.e., take all items from the one labeled "a" to the one labeled "b").
Isn't that the standard way slices are supposed to be used though? Instead of integers Panda is allowing strings. How would Pandas use the new feature?
I think Nathaniel is saying that pandas is already using string slices in an appropriate way (rather than abusing them), and so if this was just syntax sugar they wouldn't be able to use the new syntax for new functionality (since you couldn't distinguish the two).
It would be possible to make both approaches "work" by having an object that had all of .start, .stop, .step, .key and .value (and trying .key/.value first), but IMO that's going too far - I'd rather have a separate object with just .key and .value to test for.
Tim Delaney
On 7/4/14 11:07 PM, Ethan Furman wrote:
Isn't that the standard way slices are supposed to be used though? Instead of integers Panda is allowing strings. How would Pandas use the new feature?
It would not. Pandas is using it to use labels as indexes. adding keywords would allow to name the axes. These are two completely different use cases.
For example, one could have a table containing the temperature with the city on one axis and the time on the other axis.
So one could have
temperature["London", 12]
Pandas would have text indexes for "London", "New York", "Chicago" and so on. One could say
temperature["London":"Chicago", 12]
to get the temperature of the cities between "London" and "Chicago" at noon.
The PEP would allow instead to name the axes in the query
temperature[city="London":"Chicago", hour=12]
-
Ethan Furman -
Nathaniel Smith -
Oleg Broytman -
Stefano Borini -
Tim Delaney