Brendan Barnwell writes:
> So, to give an example, the iterator protocol should be documented
> right where the `for` statement is documented, and it should be
> explicitly framed as "this is the definition of what the `for` statement
> does", not something separate.
But for the
On Thu, Dec 31, 2020 at 3:13 PM Brendan Barnwell wrote:
>
> On 2020-12-29 15:01, Christopher Barker wrote:
> > along with a COMPLETE list of
> > the language features that make use of that protocol.
> >
> >
> > That is pretty much impossible -- that's kind of the point of a protocol
> >
On 2020-12-29 15:01, Christopher Barker wrote:
along with a COMPLETE list of
the language features that make use of that protocol.
That is pretty much impossible -- that's kind of the point of a protocol
-- it can be used in arbitrary places in arbitrary code.
would you expect a
On 2020-12-30 19:26, Christopher Barker wrote:
The trick here, in this context, is that something doesn't need to be a
fully functioning Mapping to be unpacked.
But there are a handful of places where a subset of the Mapping API is
needed (apparently .keys() and __getitem__, with a particular
On Tue, Dec 29, 2020 at 4:24 PM Greg Ewing
wrote:
> The library reference doesn't seem to use the terms "sequence protocol"
> and "mapping protocol". It talks about "sequence types" and "mapping
> types", but doesn't use the word "protocol" in relation to them.
>
The only one I've really seen
On 2020-12-29 16:18, Steven D'Aprano wrote:
On Tue, Dec 29, 2020 at 02:20:05PM -0800, Brendan Barnwell wrote:
So, to give an example, the iterator protocol should be documented
right where the `for` statement is documented, and it should be
explicitly framed as "this is the definition
On 30/12/20 11:20 am, Brendan Barnwell wrote:
So, to give an example, the iterator protocol should be documented
right where the `for` statement is documented, and it should be
explicitly framed as "this is the definition of what the `for` statement
does",
Not sure about that -- there
On 30/12/20 9:44 am, Christopher Barker wrote:
So there are dunders, and protocols, and ABCs, and
they all overlap a bit in purpose. And "protocols" seem to be the least
clearly specified.
> there are various protocols described in the C API docs, including
> the Mapping protocol:
>
>
On Tue, Dec 29, 2020 at 02:20:05PM -0800, Brendan Barnwell wrote:
> So, to give an example, the iterator protocol should be documented
> right where the `for` statement is documented, and it should be
> explicitly framed as "this is the definition of what the `for` statement
> does", not
On Tue, Dec 29, 2020 at 10:30:16AM -0800, Guido van Rossum wrote:
[Christopher]
> > Does there need to be a single defined "protocol" for a mapping (other
> > than the ABC)? -- that is, would **unpacking be able to use .items() and
> > keys() be used in other contexts?
Yes, I think there should
On 2020-12-29 13:54, Chris Angelico wrote:
Documentation bugs are bugs to be fixed, just like any other. Rather
than complaining that this should have prevented the feature from
being released, just propose an improvement. Where should this be
documented? How should it be worded?
Well, I did
On Tue, Dec 29, 2020 at 1:51 PM Brendan Barnwell
wrote:
> > they all overlap a bit in purpose. And "protocols" seem to be the least
> > clearly specified. Indeed, the "iteration protocol" is well known and
> > talked about, but not well documented in the standard docs:
>
> No offense to
On Wed, Dec 30, 2020 at 8:49 AM Brendan Barnwell wrote:
> To my mind, every time a change is made to Python behavior there must
> be a corresponding change to the main documentation describing the
> change. I would go so far as to say that the lack of such documentation
> updates should
On 2020-12-29 12:44, Christopher Barker wrote:
On Tue, Dec 29, 2020 at 11:18 AM Brendan Barnwell mailto:brenb...@brenbarn.net>> wrote:
On 2020-12-29 10:30, Guido van Rossum wrote:
> Long ago we decided that the distinctive
> feature is that mappings have a `keys()` method whereas
On Tue, Dec 29, 2020 at 10:30 AM Guido van Rossum wrote:
> Interesting -- thanks for taking up the challenge. I still suspect that if
> we ran the corresponding benchmark at the C level, the first form would win,
>
I was thinking that might be the case -- but either way, there is little
On Tue, Dec 29, 2020 at 11:18 AM Brendan Barnwell
wrote:
> On 2020-12-29 10:30, Guido van Rossum wrote:
> > Long ago we decided that the distinctive
> > feature is that mappings have a `keys()` method whereas sequences don't
>
It seems the real issue here is one of documentation.
On 2020-12-29 10:30, Guido van Rossum wrote:
I don't understand why LBYL is considered such an anti-pattern. It helps
produce much clearer error messages in this case for users who are
exploring this feature, and distinguishing *early* between sequences and
mappings is important for that. Long
On Mon, Dec 28, 2020 at 11:36 PM Christopher Barker
wrote:
> On Mon, Dec 28, 2020 at 12:33 PM Guido van Rossum
> wrote:
>
>> On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker
>> wrote:
>>
>>> Though frankly, I would rather have had it use .items() -- seems more
>>> efficient to me, and you
So, I’m ready to admit that I was mistaken in considering `**` as an operator.
Therefore, my further reasoning and suggestions were not correct.
If I had the right to vote, I would vote for `dict.update()` like behaviour.
Thanks for your attention and clarification.
I think it is worth creating
On Tue, Dec 29, 2020 at 8:11 AM Steven D'Aprano wrote:
> On Mon, Dec 28, 2020 at 11:36:55PM -0800, Christopher Barker wrote:
>
> > Side Question: when should one use __dict__ vs vars() vs getattr() ???
> all
> > three work in this case, but I'm never quite sure which is prefered, and
> > why.
>
On Mon, Dec 28, 2020 at 11:36:55PM -0800, Christopher Barker wrote:
> Side Question: when should one use __dict__ vs vars() vs getattr() ??? all
> three work in this case, but I'm never quite sure which is prefered, and
> why.
`vars(obj)` is defined as returning `obj.__dict__` so technically it
On Mon, Dec 28, 2020 at 12:33 PM Guido van Rossum wrote:
> On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker
> wrote:
>
>> Though frankly, I would rather have had it use .items() -- seems more
>> efficient to me, and you do need both the keys and the values, and items()
>> is just as much
2020-12-28 Christopher Barker dixit:
> I don't know about the OP, but all I wanted was a clear definition of
> the part of the API needed to support **, and apparently it's a
> keys() method that returns an iterator of the keys, and a __getitem__
[...]
To be more precise: an *iterable* of the
On Mon, Dec 28, 2020 at 12:15 PM Christopher Barker
wrote:
>
> I don't know about the OP, but all I wanted was a clear definition of the
> part of the API needed to support **, and apparently it's a keys() method
> that returns an iterator of the keys, and a __getitem__ that then returns
> the
On Mon, Dec 28, 2020 at 3:54 AM Steven D'Aprano wrote:
> > Steven D'Aprano wrote:
> > > Why do you want something that isn't a mapping to be usable with
> mapping
> > > unpacking?
> >
> > I think mapping is not `abc.Mapping` class only.
>
> You don't have to inherit from Mapping for this to
On Mon, Dec 28, 2020 at 08:44:07AM -, Anton Abrosimov wrote:
> Steven D'Aprano wrote:
> > Why do you want something that isn't a mapping to be usable with mapping
> > unpacking?
>
> I think mapping is not `abc.Mapping` class only.
You don't have to inherit from Mapping for this to work.
Steven D'Aprano wrote:
> On Mon, Dec 28, 2020 at 09:06:40AM -, Anton Abrosimov wrote:
> > Steven D'Aprano wrote:
> > You contradict yourself:
> > "I can implement any behaviour"
> > "I can't realize any other behaviour ..."
> > Which is correct?
> > I apologize for my english, I meant that I
On Mon, Dec 28, 2020 at 09:06:40AM -, Anton Abrosimov wrote:
> Steven D'Aprano wrote:
> > You contradict yourself:
> > "I can implement any behaviour"
> > "I can't realize any other behaviour ..."
> > Which is correct?
>
> I apologize for my english, I meant that I cannot implement the
>
Chris Angelico wrote:
> Allow me to rephrase what I think you're arguing here, and you can
> tell me if I'm close to the mark.
You close to the mark. :)
Chris Angelico wrote:
> Given an object of a custom class C, you can make it usable as "x, y,
> z = C()" or "f(*C())" or anything else by
Steven D'Aprano wrote:
> On Sun, Dec 27, 2020 at 02:05:38PM -, Anton Abrosimov wrote:
> >
> > *, ** are operators, but behaviorally they are methods or
> > functions. I think this is the main problem.
> >
> > No they aren't operators. They aren't in the operator precedence table,
> and
On Mon, Dec 28, 2020 at 7:45 PM Anton Abrosimov wrote:
>
> Steven D'Aprano wrote:
> > Why do you want something that isn't a mapping to be usable with mapping
> > unpacking?
>
> I think mapping is not `abc.Mapping` class only.
>
> What about:
> `Iterator[Tuple[str, int]]`
>
> ```
> @dataclass
>
Steven D'Aprano wrote:
> Why do you want something that isn't a mapping to be usable with mapping
> unpacking?
I think mapping is not `abc.Mapping` class only.
What about:
`Iterator[Tuple[str, int]]`
```
@dataclass
class MyMap:
x: int
y: int
```
Is this "mapping"?
In Python I can use
On Sun, Dec 27, 2020 at 02:05:38PM -, Anton Abrosimov wrote:
> 1. `*`, `**` are operators, but behaviorally they are methods or
> functions. I think this is the main problem.
No they aren't operators. They aren't in the operator precedence table,
and they don't have dunders associated with
On Sat, Dec 26, 2020 at 11:23:16AM -, Anton Abrosimov wrote:
> I am trying to release comfortable dataclass unpacking using `**`
> operator. Now I have 5 different ways to do it. But not a single good
> one. Confused by the implementation of the unpacking operator.
>
> So when I try to
On Sat, Dec 26, 2020 at 09:18:09PM -0800, Brendan Barnwell wrote:
> >Yes it is documented:
> >
> > help(dict.update)
> >
> >and it was intentionally the inspiration for the behaviour of dict
> >augmented assignment.
>
> I see. It's rather disturbing that that isn't mentioned in the
Christopher Barker wrote:
> My first thought is that for dataclasses, you can use the asdict() method,
> and you're done.
I thought in a similar way. I'll ask another (7K wtf in 2 years, 3 month)
question about converting a dataclass to dict.
___
0. I believe that the `dict` behavior needs to be frozen. The change will break
a lot of existing code, it's too much damage.
0.1. Yes, `keys` is not a good name for internal use, but that's okay.
0.2. If I want to make a class look like a `dict`, I understand that I will get
`keys`, `items`...
26.12.20 13:23, Anton Abrosimov пише:
> I am trying to release comfortable dataclass unpacking using `**` operator.
> Now I have 5 different ways to do it.
> But not a single good one. Confused by the implementation of the unpacking
> operator.
>
> So when I try to unpack any custom class, I
On Sun, Dec 27, 2020 at 4:30 PM Brendan Barnwell wrote:
> That said. . . I'm starting to wonder why not just create a new dunder
> called __items__ and have dict alias that to .items(). Then the
> **-unpacking protocol could use that and everything would be fine, right?
>
+0.95.
If we
On 2020-12-26 21:02, Steven D'Aprano wrote:
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
On 2020-12-26 18:44, Steven D'Aprano wrote:
>I think if we were designing mapping protocols now, that would be an
>excellent idea, but we aren't, we have decades of history
On Sat, Dec 26, 2020 at 06:52:46PM -0800, Brendan Barnwell wrote:
> On 2020-12-26 18:44, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And
On Sun, Dec 27, 2020 at 1:45 PM Greg Ewing wrote:
>
> On 27/12/20 3:03 pm, Chris Angelico wrote:
> > But that would mean that a lot of iterables would look like mappings
> > when they're not.
>
> In the context of ** you're expecting a mapping, not a sequence.
>
Exactly; and under the proposal I
On 2020-12-26 18:44, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And protocols from dict use `keys()` and getitem. E.g.
> >update.
>
>What do you mean by
On 27/12/20 3:03 pm, Chris Angelico wrote:
But that would mean that a lot of iterables would look like mappings
when they're not.
In the context of ** you're expecting a mapping, not a sequence.
--
Greg
___
Python-ideas mailing list --
On Sat, Dec 26, 2020 at 06:09:42PM -0800, Brendan Barnwell wrote:
> On 2020-12-26 18:00, Steven D'Aprano wrote:
> >I think if we were designing mapping protocols now, that would be an
> >excellent idea, but we aren't, we have decades of history from `dict`
> >behind us. And protocols from dict
On Sun, Dec 27, 2020 at 1:15 PM Brendan Barnwell wrote:
>
> On 2020-12-26 18:03, Chris Angelico wrote:
> > On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing
> > wrote:
> >>
> >> On 27/12/20 10:15 am, Christopher Barker wrote:
> >> > It does seem like ** could be usable with any iterable that returns
On 2020-12-26 16:34, Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
It does seem like ** could be usable with any iterable that returns
pairs of objects. However the trick is that when you iterate a dict, you
get the keys, not the items, which makes me think that the only
On 2020-12-26 18:03, Chris Angelico wrote:
On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
> It does seem like ** could be usable with any iterable that returns
> pairs of objects. However the trick is that when you iterate a dict, you
> get
On 2020-12-26 18:00, Steven D'Aprano wrote:
On Sun, Dec 27, 2020 at 01:34:02PM +1300, Greg Ewing wrote:
On 27/12/20 10:15 am, Christopher Barker wrote:
>It does seem like ** could be usable with any iterable that returns
>pairs of objects. However the trick is that when you iterate a dict, you
On Sun, Dec 27, 2020 at 11:36 AM Greg Ewing wrote:
>
> On 27/12/20 10:15 am, Christopher Barker wrote:
> > It does seem like ** could be usable with any iterable that returns
> > pairs of objects. However the trick is that when you iterate a dict, you
> > get the keys, not the items, which makes
On Sun, Dec 27, 2020 at 01:34:02PM +1300, Greg Ewing wrote:
> On 27/12/20 10:15 am, Christopher Barker wrote:
> >It does seem like ** could be usable with any iterable that returns
> >pairs of objects. However the trick is that when you iterate a dict, you
> >get the keys, not the items, which
On Sat, Dec 26, 2020 at 4:35 PM Greg Ewing
wrote:
> On 27/12/20 10:15 am, Christopher Barker wrote:
> > ... the only thing
> > you should *need* is an items() method that returns an iterable (pf
> > pairs of objects).
>
> It seems to me it would be more fundamental to use iteration to get
> the
On 27/12/20 10:15 am, Christopher Barker wrote:
It does seem like ** could be usable with any iterable that returns
pairs of objects. However the trick is that when you iterate a dict, you
get the keys, not the items, which makes me think that the only thing
you should *need* is an items()
My first thought is that for dataclasses, you can use the asdict() method,
and you're done.
But sure -- why not make it more generic.
It does seem like ** could be usable with any iterable that returns pairs
of objects. However the trick is that when you iterate a dict, you get the
keys, not the
54 matches
Mail list logo
