> Why not?
What if I want a getitem that only has keyword arguments? I have to take
the empty tuple as a positional argument, instead of just ensuring that the
key is a dict.
> Now, assuming you want to allow ** in getitem lookups
I don't. *args are not allowed in subscripts either. However, that would
make the syntax pretty much useless (in the keyword version) as indices
could not be passed to a function.
While I agree, not using a keywords create a certain class of bugs, those
bugs already exists. At least in the sense that if I pass a dictionary as
index things are going to get weird. However, I'd rather not have all the
special casing that comes with keyword arguments.
On Mon, Oct 7, 2019 at 7:57 PM Andrew Barnert <abarn...@yahoo.com> wrote:
> On Oct 7, 2019, at 14:56, Caleb Donovick <donov...@cs.stanford.edu> wrote:
> >
> > > I think it might be better if it actually passed them as keyword
> arguments.
> >
> > If only keyword arguments are passed what happens to the positional
> index? Is it the empty tuple?
>
> That seems like the obvious, and also most useful, answer.
>
> > Currently subscript with no index (`dict()[]`) is a syntax error should
> it continue to be?
>
> Why not? If you want to look up the empty tuple today, you can, you just
> have to be explicit: `d[()]`. This rarely comes up, but when it does, this
> reads pretty obvious (especially given that when people are using tuples as
> dict keys, they usually wrap them in parens anyway, even if it’s not
> necessary, because it looks clearer). I don’t see any reason to change that.
>
> Now, assuming you want to allow ** in getitem lookups, this would add
> another way to write the same thing: `d[**{}]`. I suppose this should be
> legal (since it could easily come up with a dynamic `d[**kw]` when there
> happen to be no keywords), but I don’t think anyone will ever be tempted to
> write it, and I don’t think anyone would be confused for more than a few
> seconds if they did, and I don’t think that allowing it requires us to
> start allowing `d[]`. That’s a restriction on the syntax for readability,
> not a limitation on the semantics, and the same readability issue still
> applies.
>
> > > Also, I think there are user implementations that accept any iterable,
> whether to treat it as a tuple or as an array-like, and a dict is an
> iterable of its keys, so it might do the wrong thing rather than raising at
> all.
> >
> > I had not thought about this. I have a lot of code in the form:
> > ```
> > if not isinstance(key, iterable):
> > key = key,
> > # do stuff assuming key is an iterable
> > ```
> > Which would have very strange behavior if a dict was passed.
>
> Exactly. And I think what you want to happen here is a `TypeError:
> Spam.__getitem__ takes no keyword arguments` or similar, not treating the
> keywords as an iterable and ignoring their values. That’s why I think
> passing kwargs separately rather than just making key a dict might make
> more sense.
>
> But then I haven’t put a huge amount of thought into this. Given that
> there’s an existing abandoned PEP, I’ll bet this was already hashed our in
> more detail, and you probably want to go back to that, come up with answers
> to the objections and open questions, and start over
>
_______________________________________________
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/GSFCYPOWVQNTYNLFJWOOUMW2M2HDA6JQ/
Code of Conduct: http://python.org/psf/codeofconduct/
