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 8/20/20 6:06 PM, Christopher Barker wrote:
But for a while is was painful to use, 'cause there was som much code
that still used strings for paths. That was made a lot better when we
introduced the __fspath__ protocol, and then updated the standard
library to use it (everywhere?).
For the specific case of `__file__`, yes, I think that would be too
disruptive. This isn't a function that *consumes* a path -- it's a path
that is consumed by innumerable other modules, most of which aren't under
active maintenance, and a sizable fraction of those would break if this
turned into
I have no idea how hard/bad/maintenance heavy this would be, but wouldn't
the easy way be simply to provide another attribute (e.g. __path__) with
what you want and maintain __file__?
I've never used a Path object (directly), I feel like I'm missing out now!
On Fri, 21 Aug 2020 at 02:09,
What about code that depends on __file__ to add installation dependent import
paths to sys.path? I have written code like that myself, and I've seen it
elsewhere too.
--Edwin
On 8/20/2020 9:06 PM, Christopher Barker wrote:
> I really like pathlib.
>
> But for a while is was painful to use,
I really like pathlib.
But for a while is was painful to use, 'cause there was som much code that
still used strings for paths. That was made a lot better when we introduced
the __fspath__ protocol, and then updated the standard library to use it
(everywhere?).
But there are still a few that bug
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?
38 matches
Mail list logo
