Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 8:31 PM, Eric V. Smith wrote: On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would use C.__gt__

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 29 November 2017 at 04:31, Eric V. Smith wrote: > On 11/28/17 7:02 AM, Nick Coghlan wrote: >> So in the above example, you would have: >> >>>>> B.__field_layout__ is B >>True >>>>> C1.__field_layout__ is B >>True >>>>> C2.__field_layout__ is B >>True >> >> It would then

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 4:14 PM, Guido van Rossum wrote: Hm. Maybe for the ordering comparisons we could defer to the class with the longest list of fields, as long as there's a subtype relationship? That way bb would be equivalent, and both would use C.__gt__. Which had better not reject this on the bas

Re: [Python-Dev] Second post: PEP 557, Data Classes

On Tue, Nov 28, 2017 at 12:56 PM, Eric V. Smith wrote: > On 11/28/2017 1:57 PM, Guido van Rossum wrote: > >> I would also be happy with a retreat, where we define `__eq__` to insist >> that the classes are the same, and people can override this to their >> hearts' content. >> > > I agree. And I g

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/2017 1:57 PM, Guido van Rossum wrote: I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content. I agree. And I guess we could always add it later, if there's a huge demand and someone

Re: [Python-Dev] Second post: PEP 557, Data Classes

I would also be happy with a retreat, where we define `__eq__` to insist that the classes are the same, and people can override this to their hearts' content. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pytho

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/28/17 7:02 AM, Nick Coghlan wrote: On 28 November 2017 at 17:41, Eric V. Smith wrote: One thing this doesn't let you do is compare instances of two different subclasses of a base type: @dataclass class B: i: int @dataclass class C1(B): pass @dataclass class C2(B): pass You can't c

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 28 November 2017 at 17:41, Eric V. Smith wrote: > One thing this doesn't let you do is compare instances of two different > subclasses of a base type: > > @dataclass > class B: > i: int > > @dataclass > class C1(B): pass > > @dataclass > class C2(B): pass > > You can't compare C1(0) and C2(

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). Didn't we at one point have something like isinstance(other, self.__class__) and fields(other) == fields(self) and (plus some optimization if the types are identical)? That feels ideal, because

Re: [Python-Dev] Second post: PEP 557, Data Classes

Sounds good. On Nov 27, 2017 8:00 AM, "Eric V. Smith" wrote: > On 11/27/17 10:51 AM, Guido van Rossum wrote: > >> Following up on this subthread (inline below). >> >> On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith > > wrote: >> >> On 11/27/2017 1:04 AM, Nick Coghla

Re: [Python-Dev] Second post: PEP 557, Data Classes

Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith wrote: > On 11/27/2017 1:04 AM, Nick Coghlan wrote: > >> On 27 November 2017 at 15:04, Greg Ewing >> wrote: >> >>> Nick Coghlan wrote: >>> Perhaps the check could be: (type(lhs)

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/17 10:51 AM, Guido van Rossum wrote: Following up on this subthread (inline below). On Mon, Nov 27, 2017 at 2:56 AM, Eric V. Smith mailto:e...@trueblade.com>> wrote: On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing mailto:greg.ew.

Re: [Python-Dev] Second post: PEP 557, Data Classes

Chris Angelico wrote: I'm not sure there's any distinction between a "point" and a "vector from the origin to a point". They transform differently. For example, translation affects a point, but makes no difference to a vector. There are two ways of dealing with that. One is to use vectors to r

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:26 AM, Sebastian Rittau wrote: On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From w

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 7:31 AM, Sebastian Rittau wrote: On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns with

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 13:23, Eric V. Smith wrote: I had something like your suggestion half coded up, except I inspected the args to __post_init__() and added them to __init__, avoiding the API-unfriendly *args and **kwargs. I understand your concerns with *args and **kwargs. I think we need to find a

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27.11.2017 12:01, Sebastian Rittau wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From what I understand, we are supposed to use the fi

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 6:01 AM, Sebastian Rittau wrote: On 25.11.2017 22:06, Eric V. Smith wrote: The major changes from the previous version are: - Add InitVar to specify initialize-only fields. This is the only feature that does not sit right with me. It looks very obscure and "hacky". From what

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 25.11.2017 22:06, Eric V. Smith wrote: The updated version should show up at https://www.python.org/dev/peps/pep-0557/ shortly. This PEP looks very promising and will make my life quite a bit easier, since we are using a pattern involving data classes. Currently, we write the constructor b

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/27/2017 1:04 AM, Nick Coghlan wrote: On 27 November 2017 at 15:04, Greg Ewing wrote: Nick Coghlan wrote: Perhaps the check could be: (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all (individual fields match) I think the types should *always* have to match, or at lea

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27 November 2017 at 15:04, Greg Ewing wrote: > Nick Coghlan wrote: >> >> Perhaps the check could be: >> >> (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all >> (individual fields match) > > > I think the types should *always* have to match, or at least > one should be a subclass

Re: [Python-Dev] Second post: PEP 557, Data Classes

Nick Coghlan wrote: Perhaps the check could be: (type(lhs) == type(rhs) or fields(lhs) == fields(rhs)) and all (individual fields match) I think the types should *always* have to match, or at least one should be a subclass of the other. Consider: @dataclass class Point3d: x: float y

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 27 November 2017 at 06:22, Eric V. Smith wrote: > On 11/26/2017 1:04 PM, Brett Cannon wrote: >> >> The only open issues I know of are: >> - Should object comparison require an exact match on the type? >> https://github.com/ericvsmith/dataclasses/issues/51 >> >> >> I say don't requir

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 1:04 PM, Brett Cannon wrote: The only open issues I know of are: - Should object comparison require an exact match on the type? https://github.com/ericvsmith/dataclasses/issues/51 I say don't require the type comparison for duck typing purposes. The problem with that

Re: [Python-Dev] Second post: PEP 557, Data Classes

On Sat, Nov 25, 2017, 14:00 Eric V. Smith, wrote: > The updated version should show up at > https://www.python.org/dev/peps/pep-0557/ shortly. > > The major changes from the previous version are: > > - Add InitVar to specify initialize-only fields. > - Renamed __dataclass_post_init__() to __post_

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 3:48 AM, Eric V. Smith wrote: While creating an issue for this (https://github.com/ericvsmith/dataclasses/issues/88), it occurs to me that the class-level parameter really should be "order" or "orderable", not "compare". It made more sense when it was called "cmp", but "compare"

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 3:35 AM, Eric V. Smith wrote: On 11/26/2017 12:23 AM, Carl Meyer wrote: A couple minor questions: If compare is True, then eq is ignored, and __eq__ and __ne__ will be automatically generated. IMO it's generally preferable to make nonsensical parameter combinations an immediate

Re: [Python-Dev] Second post: PEP 557, Data Classes

On 11/26/2017 12:23 AM, Carl Meyer wrote: Hi Eric, Really excited about this PEP, thanks for working on it. Thanks, Carl. A couple minor questions: If compare is True, then eq is ignored, and __eq__ and __ne__ will be automatically generated. IMO it's generally preferable to make nonsen

Re: [Python-Dev] Second post: PEP 557, Data Classes

Hi Eric, Really excited about this PEP, thanks for working on it. A couple minor questions: > If compare is True, then eq is ignored, and __eq__ and __ne__ will be automatically generated. IMO it's generally preferable to make nonsensical parameter combinations an immediate error, rather than si

Re: [Python-Dev] Second post: PEP 557, Data Classes

One more change: - Per-field metadata, for use by third parties. Also, thanks to Guido and Ivan for all of their feedback on the various issues that got the PEP to this point. Eric. On 11/25/2017 4:06 PM, Eric V. Smith wrote: The updated version should show up at https://www.python.org/dev