On Sat, Aug 22, 2020 at 11:22 AM Guido van Rossum wrote:
> The worst that could happen would be that some user figures out they can
> access the hidden functionality by writing a[key, extra=“stuff”], whereas
> previously they would have to call a.__getitem__(key, extra=“stuff”).
>
> Doesn’t
The worst that could happen would be that some user figures out they can
access the hidden functionality by writing a[key, extra=“stuff”], whereas
previously they would have to call a.__getitem__(key, extra=“stuff”).
Doesn’t sound like a big deal, and not breakage either.
On Sat, Aug 22, 2020 at
On Thu, Aug 20, 2020 at 9:16 PM Random832 wrote:
> On Thu, Aug 20, 2020, at 20:09, Steven D'Aprano wrote:
> > This is likely to be a rare and unusual case, but we don't want to break
> > anyone who already has a dunder something like this:
> >
> > def __getitem__(self, index, extra=None)
>
>
On Thu, Aug 20, 2020, at 20:09, Steven D'Aprano wrote:
> This is likely to be a rare and unusual case, but we don't want to break
> anyone who already has a dunder something like this:
>
> def __getitem__(self, index, extra=None)
People do similar things with regular arguments to regular
On Thu, Aug 20, 2020, at 09:46, Steven D'Aprano wrote:
> And what about all the objects that don't have a .value attribute?
> What's so special about that attribute that subscripting with a missing
> subscript should return that attribute rather than some other?
er, I meant "it should, on
On Thu, Aug 20, 2020 at 5:11 PM Steven D'Aprano wrote:
> On Thu, Aug 20, 2020 at 10:41:42AM -0700, Christopher Barker wrote:
> > Current indexing behavior is an oddball now:
>
> > The signature of __getitem__ is always:
> >
> > def __getitem__(self, index):
>
> Mostly correct -- you can still
On Thu, Aug 20, 2020 at 5:16 PM Steven D'Aprano wrote:
> > If xarray supports keyword arguments, this would assign to the
> > corresponding values. If it didn't, it would create a new element of the
> > Dataset containing "y[a=2, b=3]". But "y" would continue working as it
> > would, only with
On Thu, Aug 20, 2020 at 02:58:28PM -0400, Todd wrote:
> If xarray supports keyword arguments, this would assign to the
> corresponding values. If it didn't, it would create a new element of the
> Dataset containing "y[a=2, b=3]". But "y" would continue working as it
> would, only with different
On Thu, Aug 20, 2020 at 10:41:42AM -0700, Christopher Barker wrote:
> Current indexing behavior is an oddball now:
>
> ( you all know this, but I think it’s helpful to lay it out)
Correct.
> The signature of __getitem__ is always:
>
> def __getitem__(self, index):
Mostly correct -- you can
Hmmm, sorry, there was an encoding issue with my previous email. Somehow
my attempted U+2091 LATIN SUBSCRIPT SMALL LETTER E got turned into the
^J control character.
--
Steve
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe
Jonathan, you’re getting awfully close to “not knowing when to stop”.
On Thu, Aug 20, 2020 at 11:20 Jonathan Fine wrote:
> Hi Todd
>
> I still don't see how testing it will help anything at this point.
>>
>
> Well, you and I have a difference of opinion here. I don't think it's
> worth
On Thu, Aug 20, 2020 at 2:28 PM Jonathan Fine wrote:
> Hi Todd
>
> You wrote:
>
> I think this is a bad idea, since it would mean classes could seem to
>> support keyword arguments but silently do the completely wrong thing,
>> especially if someone accidentally uses an older version.
>>
>
> I
Hi Todd
You wrote:
I think this is a bad idea, since it would mean classes could seem to
> support keyword arguments but silently do the completely wrong thing,
> especially if someone accidentally uses an older version.
>
I don't see this happening, and certainly don't see it as a new problem.
On Thu, Aug 20, 2020 at 1:58 PM Christopher Barker
wrote:
> On Thu, Aug 20, 2020 at 12:55 PM Jonathan Fine
> wrote:
>
>> In addition, I would like
>>> >>> d = dict()
>>> >>> d[x=1, y=2] = 5
>>> to work. It works out-of-the-box for my scheme.
>>>
>>
> 1) it does? could you explain that,
On Thu, Aug 20, 2020 at 2:13 PM Jonathan Fine wrote:
> Hi Todd
>
> I still don't see how testing it will help anything at this point.
>>
>
> Well, you and I have a difference of opinion here. I don't think it's
> worth discussing this further now. Perhaps next month it will be.
>
This is an
Hi Todd
I still don't see how testing it will help anything at this point.
>
Well, you and I have a difference of opinion here. I don't think it's
worth discussing this further now. Perhaps next month it will be.
--
Jonathan
___
Python-ideas mailing
On Thu, Aug 20, 2020 at 1:43 PM Sebastian Kreft wrote:
>
>
> On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine
> wrote:
>
>> Todd wrote:
>>
>> It has the same capabilities, the question is whether it has any
>>> additional abilities that would justify the added complexity.
>>>
>>
>> The most
This has been discussed. The current consensus approach would be to keep
the index argument as a single value, while making keyword indices as
keyword arguments. So something like:
def __getitem__(self, index, **kwargs):
Classes that don't want to handle keyword indices just don't have to
On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine wrote:
> Todd wrote:
>
> It has the same capabilities, the question is whether it has any
>> additional abilities that would justify the added complexity.
>>
>
> The most obvious additional ability is that always
> >>> d[SOME_EXPRESSION]
> is
On Thu, Aug 20, 2020 at 12:55 PM Jonathan Fine wrote:
> In addition, I would like
>> >>> d = dict()
>> >>> d[x=1, y=2] = 5
>> to work. It works out-of-the-box for my scheme.
>>
>
1) it does? could you explain that, I can't see it.
2) so what? -- it would still only work with the next
On Thu, Aug 20, 2020 at 12:54 PM Jonathan Fine wrote:
> Todd wrote:
>
> It has the same capabilities, the question is whether it has any
>> additional abilities that would justify the added complexity.
>>
>
> The most obvious additional ability is that always
> >>> d[SOME_EXPRESSION]
> is
I have not fully thought this out yet, but while my first instinct was to
agree with others to “just use the calling conventions we already have”,
there is a wrinkle:
Current indexing behavior is an oddball now:
( you all know this, but I think it’s helpful to lay it out)
The signature of
On Thu, Aug 20, 2020 at 12:55 PM Jonathan Fine wrote:
> In addition, I would like
> >>> d = dict()
> >>> d[x=1, y=2] = 5
> to work. It works out-of-the-box for my scheme. It can be made to work
> with a subclass of dict for the D'Aprano scheme.
>
This raises the question about this
Todd wrote:
It has the same capabilities, the question is whether it has any additional
> abilities that would justify the added complexity.
>
The most obvious additional ability is that always
>>> d[SOME_EXPRESSION]
is equivalent to
>>> d[key]
for a suitable key.
This is a capability
On Thu, Aug 20, 2020, 11:03 Jonathan Fine wrote:
> Todd wrote:
>
> Only Jonathan seems to want to do it differently. We are trying to find
>> out exactly why he prefers this approach. So far the only advantage I have
>> seen is that it is easier to experiment with.
>>
>
> I think it's good to
No, I am saying it is important to distinguish between "d[3, 4]" and
"d[day=3, detector=4]". In xarray there can be label-only dimensions, that
is dimensions with no corresponding position. So having all labelled
dimensions necessarily mapped onto positional dimensions wouldn't work.
On Sat,
On Thu, Aug 20, 2020 at 11:01 AM Ricky Teachey wrote:
> On Thu, Aug 20, 2020 at 10:31 AM Guido van Rossum
> wrote:
>
>>
>>
> That may not be in the PEP, but apart from the edge cases for d[] and
>> d[x=0] it’s exactly what I and Steven have been proposing for quite a while.
>>
>> —Guido
>> --
Todd wrote:
Only Jonathan seems to want to do it differently. We are trying to find
> out exactly why he prefers this approach. So far the only advantage I have
> seen is that it is easier to experiment with.
>
I think it's good to make experiments before making a decision. That's
where I'd
On Thu, Aug 20, 2020 at 10:31 AM Guido van Rossum wrote:
>
>
> On Thu, Aug 20, 2020 at 05:57 Random832 wrote:
>
>>
>> I have an implementation proposal that I believe is distinct from any of
>> the ones mentioned in the PEP currently.
>>
>>
>>
>> Pass keyword arguments as ordinary keyword
On Thu, Aug 20, 2020, 09:01 Random832 wrote:
> On Fri, Aug 14, 2020, at 06:03, Jonathan Fine wrote:
> > I'd like to sound out consensus regarding mapping access, where none of
> > the keys are positional. In particular, I suggest that PEP 472 allow
> > syntax and semantics such as
> > >>>
On Thu, Aug 20, 2020 at 05:57 Random832 wrote:
>
> I have an implementation proposal that I believe is distinct from any of
> the ones mentioned in the PEP currently.
>
>
>
> Pass keyword arguments as ordinary keyword arguments [which any particular
> __getitem__ implementation is free to handle
On Thu, Aug 20, 2020 at 09:03:40AM -0400, Random832 wrote:
> On Mon, Aug 17, 2020, at 14:00, Christopher Barker wrote:
> > From an implementation perspective, the [] operator is another way to
> > call __getitem__ and __setitem__. And from that perspective, why not
> > have it act like a
On Thu, Aug 20, 2020, at 08:56, Random832 wrote:
> I have an implementation proposal that I believe is distinct from any
> of the ones mentioned in the PEP currently.
on further reflection, this seems mostly equivalent to the "kwargs argument"
strategy [which I had wrongly read as
On Mon, Aug 17, 2020, at 14:00, Christopher Barker wrote:
> From an implementation perspective, the [] operator is another way to
> call __getitem__ and __setitem__. And from that perspective, why not
> have it act like a function call: no arguments, positional arguments,
> keyword arguments,
On Fri, Aug 14, 2020, at 06:03, Jonathan Fine wrote:
> I'd like to sound out consensus regarding mapping access, where none of
> the keys are positional. In particular, I suggest that PEP 472 allow
> syntax and semantics such as
> >>> d[x=1, y=2] = 42
> >>> d[x=1, y=2]
> 42
> and
On Sat, Aug 15, 2020, at 01:55, Steven D'Aprano wrote:
> Of course we would not. So why are we even considering a language change
> to force every single subscriptable object to accept arbitrary
> keyword-only arguments unless the maintainer changes their class to
> explicitly reject them?
On 18/08/20 6:37 am, Jonathan Fine wrote:
if
>>> something[*argv]
is allowed, then what was a syntax error becomes a run-time error.
I don't think so. If argv is empty, this is more akin to
x = ()
something(x)
which we presumably still want to allow.
Opponents of a[] aren't
On 18/08/20 6:00 am, Christopher Barker wrote:
But from a language design perspective, the [] operator is a way to
"index" a container -- get part of the container's contents. And from
this perspective, no index makes no sense.
It can make sense if you have a zero-dimensional array. Or as
Ugh. It is becoming gradually clear to me that obj[] should be a syntax
error. We should definitely not indulge in obj[-] or {-}.
On Mon, Aug 17, 2020 at 11:41 AM Jonathan Fine wrote:
> Here's a few words on whether we should allow and whether we can forbid:
> >>> something[]
>
> First, in
Here's a few words on whether we should allow and whether we can forbid:
>>> something[]
First, in
>>> something[x=1]
what I call the argv is empty, as it is with
>>> something[]
If we represent an empty argv by passing the empty tuple () to __getitem__,
then how are
>>>
RE: empty subscripts:
Should something[] be allowed syntax?
TL;DR: no
In a way this comes down to design philosophy vs implementation.
>From an implementation perspective, the [] operator is another way to call
__getitem__ and __setitem__. And from that perspective, why not have it act
like a
On Mon, 17 Aug 2020 22:54:32 +1200
Greg Ewing wrote:
> On 17/08/20 9:58 pm, Antoine Pitrou wrote:
> > Probably because exploiting Python abstraction facilities to build DSLs
> > has/had long been frown upon in this community? That was the leitmotiv
> > back when people were marvelling over
On 17/08/20 9:58 pm, Antoine Pitrou wrote:
Probably because exploiting Python abstraction facilities to build DSLs
has/had long been frown upon in this community? That was the leitmotiv
back when people were marvelling over Ruby's flexibility in the area.
As far as I remember, what was
On Sat, 15 Aug 2020 19:27:24 -0700
Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 7:14 PM Caleb Donovick
> wrote:
>
> > > To me, the main weakness here is that you couldn't move forward with
> > this unless you also got the various static type checkers on board. But I
> > don't think
On Sun, Aug 16, 2020 at 11:18:40AM -0700, Guido van Rossum wrote:
> > Just to clarify here, I assume you mean that if xarray cares about
> > order-preserving keywords, they should write their methods this way:
> >
> > def __getitem__(self, index=None, **kwargs):
> >
> > rather than mandating
On Sun, Aug 16, 2020 at 12:07:47PM -0700, Guido van Rossum wrote:
[...]
> So I probably would be okay with allowing `obj[]` syntactically, as long as
> the dict type could be made to reject it.
I don't absolutely hate the idea, but I do feel that it's semantically
rather dubious. `obj` with no
On 17/08/20 8:19 am, Sebastian Berg wrote:
[1] The difference is that `arr[()]` extracts a scalar, while
`arr[...]` returns the array (container) unchanged. This difference
only matters for zero dimensional arrays. There may be reasons to
prefer one over the other, but I can't think of any
*unconcerned
(sorry for the spam)
On Sun, Aug 16, 2020 at 3:57 PM Caleb Donovick
wrote:
> > Fine, so the use case you claimed was fiction. If you had just said
> "DSL" instead of "anonymous protocols and dataclasses" you would have
> gotten straight to the point and we would have been talking
> Fine, so the use case you claimed was fiction. If you had just said "DSL"
instead of "anonymous protocols and dataclasses" you would have gotten
straight to the point and we would have been talking about whether extended
subscription would be useful for DSLs (I can see various use cases), rather
On Sun, 2020-08-16 at 12:07 -0700, Guido van Rossum wrote:
> On Sun, Aug 16, 2020 at 5:45 AM Steven D'Aprano
> wrote:
>
> > On Mon, Aug 17, 2020 at 12:32:08AM +1200, Greg Ewing wrote:
> > > On 16/08/20 11:49 am, Guido van Rossum wrote:
> > > >SEMANTICS OF NO ARGUMENTS
> > > >I can see
On Sun, Aug 16, 2020 at 5:45 AM Steven D'Aprano wrote:
> On Mon, Aug 17, 2020 at 12:32:08AM +1200, Greg Ewing wrote:
> > On 16/08/20 11:49 am, Guido van Rossum wrote:
> > >SEMANTICS OF NO ARGUMENTS
> > >I can see two basic ways of allowing no arguments. One is for the
> > >
On Sat, Aug 15, 2020 at 10:00 PM Steven D'Aprano
wrote:
> On Sat, Aug 15, 2020 at 08:26:10PM -0700, Guido van Rossum wrote:
>
> > Are you saying that for xarray it is important to distinguish between
> > `d[day=3, detector=4]` and `d[detector=4, day=3]`? If we just passed the
> > keyword args to
On Mon, Aug 17, 2020 at 12:32:08AM +1200, Greg Ewing wrote:
> On 16/08/20 11:49 am, Guido van Rossum wrote:
> >SEMANTICS OF NO ARGUMENTS
> >I can see two basic ways of allowing no arguments. One is for the
> >interpreter to construct an object that is the argument passed to
> >
On 16/08/20 11:49 am, Guido van Rossum wrote:
SEMANTICS OF NO ARGUMENTS
I can see two basic ways of allowing no arguments. One is for the
interpreter to construct an object that is the argument passed to
__getitem__ and so forth. The other is to not pass an argument at
all. I
On Sat, Aug 15, 2020 at 08:26:10PM -0700, Guido van Rossum wrote:
> Are you saying that for xarray it is important to distinguish between
> `d[day=3, detector=4]` and `d[detector=4, day=3]`? If we just passed the
> keyword args to `__getitem__` as an extra `**kwds` argument (which
> preserves
On Sat, Aug 15, 2020 at 09:25:00PM -0700, Stephan Hoyer wrote:
> One question that comes up: should d[**kwargs] be valid syntax? d[*args]
> currently is not, but that's OK since d[tuple(args)] is identical.
If we're going to support keyword arguments, what reason would we have
for not
On Sat, Aug 15, 2020 at 8:27 PM Guido van Rossum wrote:
> On Sat, Aug 15, 2020 at 8:02 PM Todd wrote:
>
>> On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
>> wrote:
>>
>>> > QUESTION
>>> > Suppose we have
>>> > >>> d[x=1, y=2] = 42
>>> > >>> d[x=1, y=2]
>>> > 42
>>> > where d is an
On Sat, Aug 15, 2020 at 8:02 PM Todd wrote:
> On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
> wrote:
>
>> > QUESTION
>> > Suppose we have
>> > >>> d[x=1, y=2] = 42
>> > >>> d[x=1, y=2]
>> > 42
>> > where d is an instance of a suitable class X that has no special
>> knowledge of
On Sat, Aug 15, 2020 at 7:26 PM Stefano Borini
wrote:
> > QUESTION
> > Suppose we have
> > >>> d[x=1, y=2] = 42
> > >>> d[x=1, y=2]
> > 42
> > where d is an instance of a suitable class X that has no special
> knowledge of keywords.
>
> Initially, when I wrote the pep, the idea was
On Sat, Aug 15, 2020 at 7:14 PM Caleb Donovick
wrote:
> > To me, the main weakness here is that you couldn't move forward with
> this unless you also got the various static type checkers on board. But I
> don't think those care much about this use case (an inline notation for
> what you can
> Hmm... OK, that's an interesting desire. How do square brackets get you
any closer to that?
I use `__class_getitem__` as a memoized type factory that builds a new
subtype when it's called or returns the cached type.
You are correct I could name it as something else, there is nothing special
> To me, the main weakness here is that you couldn't move forward with
this unless you also got the various static type checkers on board. But I
don't think those care much about this use case (an inline notation for
what you can already do with a class definition and annotations). And
without
On Fri, Aug 14, 2020 at 3:05 AM Jonathan Fine wrote:
> I'd like to sound out consensus regarding mapping access, where none of
> the keys are positional. In particular, I suggest that PEP 472 allow syntax
> and semantics such as
> >>> d[x=1, y=2] = 42
> >>> d[x=1, y=2]
> 42
> and ask
On Fri, 14 Aug 2020 at 11:07, Jonathan Fine wrote:
> NO ARGUMENTS
>
> I'd like d[] to become valid syntax.
This makes me a bit uncomfortable.
> SEMANTICS OF NO ARGUMENTS
> I can see two basic ways of allowing no arguments. One is for the interpreter
> to construct an object that is the
On Fri, Aug 14, 2020 at 4:38 PM Caleb Donovick
wrote:
> My own personal use for this would be for generating anonymous protocols
> and dataclasses:
>
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T ==
On Sat, Aug 15, 2020 at 4:38 PM Caleb Donovick
wrote:
> > Why would it require a metaclass? Rather than just: ...
>
> Because I want the following to be true:
> x = Struct[x=int, y=str](...)
> assert isinstance(x, Struct)
> assert isinstance(x, Struct[x=int, y=str])
> assert not isinstance(x,
> Why would it require a metaclass? Rather than just: ...
Because I want the following to be true:
```
x = Struct[x=int, y=str](...)
assert isinstance(x, Struct)
assert isinstance(x, Struct[x=int, y=str])
assert not isinstance(x, Struct[x=int, y=int])
```
On Fri, Aug 14, 2020 at 5:27 PM David
> I don't know how to interpret these examples. What's Protocol and where
does it come from? What's Struct?
`Protocol` comes from `typing`
`Struct` is my own class which generates anonymous dataclasses and
protocols as you gathered (unfortunately I currently have two versions one
for building
Hi Steven
You wrote:
why are we even considering a language change to force every single
> subscriptable object to accept arbitrary keyword-only arguments unless the
> maintainer changes their class to
> explicitly reject them?
I think there might be a misunderstanding here. I'd like to see an
Message below sent in error. Please ignore. I'll send a replacement in a
few minutes. Please accept my apologies.
On Sat, Aug 15, 2020 at 4:30 PM Jonathan Fine wrote:
> Hi Steven
>
>
> Recall that my proposal implies
> >>> d = dict()
> >>> d[a=1, b=2] = 42
> >>> d[a=1, b=2]
> 42
Hi Steven
Recall that my proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
>>> d[a=1, b=2]
42
Recall that your proposal implies
>>> d = dict()
>>> d[a=1, b=2] = 42
TypeError: wrapper __setitem__ doesn't take keyword arguments
>
On Fri, Aug 14, 2020 at 08:58:36PM -0400, Ricky Teachey wrote:
> One problem is type hint creation has been extended to built-ins in python
> 3.9, so that you do not have to import Dict, List, et al anymore.
>
> Without kwd args inside [ ], you would not be able to do this:
>
> Vector =
On Fri, Aug 14, 2020 at 04:07:33PM -0700, Caleb Donovick wrote:
> My own personal use for this would be for generating anonymous protocols
> and dataclasses:
>
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T ==
On Fri, Aug 14, 2020 at 08:45:44AM -0400, Ricky Teachey wrote:
> It seems very obvious to me that kwd args only should be valid, as Greg
> Ewing said, if kwd args are added.
Absolutely. We shouldn't even need to debate this. Would we consider a
language change that forced every single function
On Fri, Aug 14, 2020, 7:45 PM David Mertz wrote:
> On Fri, Aug 14, 2020, 7:39 PM Caleb Donovick
>
>> class T(Protocol):
>> x: int
>> y: str
>> # with some abuse of notation obviously these would generate unique
>> typesassert T == Struct[x=int, y=str]
>>
>> I don't see what that can
On Fri, Aug 14, 2020, 7:53 PM Caleb Donovick
wrote:
> > I don't see what that can possible get you that `Struct(x=int, y=str)`
> doesn't.
>
> Using `Struct(x=int, y=str)` requires a metaclass, where `Struct[x=int,
> y=str]` does not.
>
Why would it require a metaclass? Rather than just:
class
> I don't see what that can possible get you that `Struct(x=int, y=str)`
doesn't.
Using `Struct(x=int, y=str)` requires a metaclass, where `Struct[x=int,
y=str]` does not.
On Fri, Aug 14, 2020 at 4:45 PM David Mertz wrote:
> On Fri, Aug 14, 2020, 7:39 PM Caleb Donovick
>
>> class T(Protocol):
On Fri, Aug 14, 2020, 7:39 PM Caleb Donovick
> class T(Protocol):
> x: int
> y: str
> # with some abuse of notation obviously these would generate unique
> typesassert T == Struct[x=int, y=str]
>
> I don't see what that can possible get you that `Struct(x=int, y=str)`
doesn't.
I'm +0 on
My own personal use for this would be for generating anonymous protocols
and dataclasses:
class T(Protocol):
x: int
y: str
# with some abuse of notation obviously these would generate unique
typesassert T == Struct[x=int, y=str]
# similarly @dataclassclass S:
x: int
y: str
assert S
On Fri, 14 Aug 2020 at 13:12, Jonathan Fine wrote:
> Anyone who is experimenting with keyword keys would, I think, appreciate
> having something they can use straight away. Thus, I think, any use case for
> PEP 472 is also a use case for the general keyword class I'm suggesting. No
> use cases
It seems very obvious to me that kwd args only should be valid, as Greg
Ewing said, if kwd args are added.
I'm less sure about no arguments, but perhaps.
On Fri, Aug 14, 2020, 8:11 AM Jonathan Fine wrote:
> Storing function call results would be a use case. For this, look at the
>
Hi Greg
Thank you, for your support for d[x=1, y=2] being valid syntax.
You ask if I have any use cases in mind for a general keyword key class
being part of standard Python. Good question.
Anyone who is experimenting with keyword keys would, I think, appreciate
having something they can use
On 14/08/20 10:03 pm, Jonathan Fine wrote:
NO POSITIONAL ARGUMENTS
I'd like
>>> d[x=1, y=2]
to be valid syntax. It's not clear to me that all agree with this.
If keywords are to be allowed, it seems reasonable to me
that this should be legal.
>>> d[x=1, y=2] = 42
>>> d[x=1,
83 matches
Mail list logo
