Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/4/2017 5:19 PM, Ivan Levkivskyi wrote: Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-) Thanks for all of your help, Ivan, especially for design decisions that help interoperability with mypy. I'm looking forward to mypy support,

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Congratulations, Eric! This is a great PEP and I am looking forward to implement support for it in mypy ;-) -- Ivan On 4 December 2017 at 18:17, Guido van Rossum wrote: > And with this, I'm accepting PEP 557, Data Classes. > > Eric, congrats with your efforts in proposing and implementing this

Re: [Python-Dev] PEP 557 Data Classes 5th posting

> On Dec 4, 2017, at 9:17 AM, Guido van Rossum wrote: > > And with this, I'm accepting PEP 557, Data Classes. Woohoo! I think everyone was looking forward to this moment. Raymond ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyt

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Thanks, Guido. And indeed, thanks to everyone else who provided inspiration and feedback. I too would like to thank Hynek and the other authors of “attrs”. I’ll get the implementation committed in the next day or so. -- Eric. > On Dec 4, 2017, at 12:17 PM, Guido van Rossum wrote: > > And wi

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/04/2017 09:17 AM, Guido van Rossum wrote: And with this, I'm accepting PEP 557, Data Classes. Congratulations, Eric! Data Classes will be a handy thing to have. :) -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.pyt

Re: [Python-Dev] PEP 557 Data Classes 5th posting

And with this, I'm accepting PEP 557, Data Classes. Eric, congrats with your efforts in proposing and implementing this PEP and guiding it through the discussion! It's been great to see this idea come to fruition. Thanks also to the many people who reviewed drafts or implementation code, including

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 9:07 PM, Eric V. Smith wrote: On 12/3/2017 8:31 PM, Guido van Rossum wrote: On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith > wrote:     On 12/3/2017 3:33 PM, Antoine Pitrou wrote:     Thanks.  I have to ask: why don't "asdict" and "astuple" respec

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 9:07 PM, Eric V. Smith wrote: It also matches `attrs.asdict()`, which is what originally inspired it. Make that `attr.asdict()`. So easy to get that wrong. Eric. ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 8:31 PM, Guido van Rossum wrote: On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith > wrote: On 12/3/2017 3:33 PM, Antoine Pitrou wrote: Thanks.  I have to ask: why don't "asdict" and "astuple" respect PEP 8 naming? I gues

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On Sun, Dec 3, 2017 at 1:28 PM, Eric V. Smith wrote: > On 12/3/2017 3:33 PM, Antoine Pitrou wrote: > >> On Sat, 2 Dec 2017 09:02:37 -0500 >> "Eric V. Smith" wrote: >> >>> I've pushed another version of PEP 557. The only difference is changing >>> the default value of "order" to False instead of

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 3:33 PM, Antoine Pitrou wrote: On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality,

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Me, either. So I'm going to leave it as a tuple. Unless I find something while reviewing it tonight, I'm done. Eric. On 12/3/2017 3:02 PM, Guido van Rossum wrote: On second thought I don't care that much. On Dec 3, 2017 9:07 AM, "Eric V. Smith" > wrote: On 12/

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On Sat, 2 Dec 2017 09:02:37 -0500 "Eric V. Smith" wrote: > I've pushed another version of PEP 557. The only difference is changing > the default value of "order" to False instead of True. This matches > regular classes: instances can be tested for equality, but are unordered. > > Discussion at

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On second thought I don't care that much. On Dec 3, 2017 9:07 AM, "Eric V. Smith" wrote: > On 12/3/2017 11:56 AM, Guido van Rossum wrote: > >> Not sure I like that better. It's an open-ended sequence of homogeneous >> types. What's the advantage of a tuple? I don't want to blindly follow >> exis

Re: [Python-Dev] PEP 557 Data Classes 5th posting

On 12/3/2017 11:56 AM, Guido van Rossum wrote: Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs. So people don't modify it, but consenting adults would say "don't do that". I currently

Re: [Python-Dev] PEP 557 Data Classes 5th posting

Not sure I like that better. It's an open-ended sequence of homogeneous types. What's the advantage of a tuple? I don't want to blindly follow existing APIs. On Sun, Dec 3, 2017 at 6:55 AM, Eric V. Smith wrote: > I've made a minor change: the return type of fields() is now a tuple, it > was a li

Re: [Python-Dev] PEP 557 Data Classes 5th posting

I've made a minor change: the return type of fields() is now a tuple, it was a list. Eric. On 12/2/2017 9:02 AM, Eric V. Smith wrote: I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: in

[Python-Dev] PEP 557 Data Classes 5th posting

I've pushed another version of PEP 557. The only difference is changing the default value of "order" to False instead of True. This matches regular classes: instances can be tested for equality, but are unordered. Discussion at https://github.com/ericvsmith/dataclasses/issues/104 It's already

Re: [Python-Dev] PEP 557: Data Classes

> On Oct 12, 2017, at 7:46 AM, Guido van Rossum wrote: > > I am still firmly convinced that @dataclass is the right name for the > decorator (and `dataclasses` for the module). +1 from me. The singular/plural pair has the same nice feel as "from fractions import Fraction", "from itertools im

Re: [Python-Dev] PEP 557: Data Classes

On 10/12/2017 03:44 PM, Chris Barker wrote: I think we've drifted into a new topic, but... I was thinking about this last spring, when I tried to cram all sorts of python metaprogramming into one 3hr class... Trying to come up with a an exam[ple for metclasses, I couldn't come up with anyth

Re: [Python-Dev] PEP 557: Data Classes

On 10/12/2017 6:33 PM, Chris Barker wrote: On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden > wrote:  The reason I liked "row" as a name is because it resembles "vector" and hence is loosely assocaited with the concept of a tuple as well as being familiar

Re: [Python-Dev] PEP 557: Data Classes

I think we've drifted into a new topic, but... I was astonished to see them > implemented using decorators, and I was not the only one. ... > Python is at a weird point here. At about every new release of Python, > a new idea shows up that could be easily solved using metaclasses, yet > ever

Re: [Python-Dev] PEP 557: Data Classes

On Thu, Oct 12, 2017 at 3:20 AM, Steve Holden wrote: > The reason I liked "row" as a name is because it resembles "vector" and > hence is loosely assocaited with the concept of a tuple as well as being > familiar to database users. In fact the answer to a relational query was, I > believe, ori

Re: [Python-Dev] PEP 557: Data Classes

You're right that if it were easier to combine metaclasses we would not shy away from them so easily. Perhaps you and others interested in this topic can try to prototype an implementation and see how it would work in practice (with some realistic existing metaclasses)? Then the next step would be

Re: [Python-Dev] PEP 557: Data Classes

Hi list, first, a big thanks to the authors of PEP 557! Great idea! For me, the dataclasses were a typical example for inheritance, to be more precise, for metaclasses. I was astonished to see them implemented using decorators, and I was not the only one, citing Guido: > I think it would be usef

Re: [Python-Dev] PEP 557: Data Classes

On 2017-10-11 23:05, Nick Coghlan wrote: It's akin to "static method", "class method", and "instance method" for function definitions (although the last one isn't a typical decorator, since it's the default behaviour for functions placed inside a class). Thanks, I'm still thinking of it as i

Re: [Python-Dev] PEP 557: Data Classes

On Thu, Oct 12, 2017 at 10:20 AM, Mike Miller wrote: > > On 2017-10-12 00:36, Stéfane Fermigier wrote: > >> "An object that is not defined by its attributes, but rather by a thread >> of continuity and its identity." (from https://en.wikipedia.org/wiki/ >> Domain-driven_design#Building_blocks) >>

Re: [Python-Dev] PEP 557: Data Classes

On Wed, Oct 11, 2017 at 10:33 PM, Mike Miller wrote: > (Apologies for reviving a dead horse, but may not be around at the blessed > time.) > > As potential names of this concept, I liked record and row, but agreed > they were a bit too specific and not quite exact. In my recent (unrelated) > rea

Re: [Python-Dev] PEP 557: Data Classes

On Oct 12, 2017, at 10:46, Guido van Rossum wrote: > > I am still firmly convinced that @dataclass is the right name for the > decorator (and `dataclasses` for the module). Darn, and I was going to suggest they be called EricTheHalfABees, with enums being renamed to EricTheHalfNotBees. -Barry

Re: [Python-Dev] PEP 557: Data Classes

I am still firmly convinced that @dataclass is the right name for the decorator (and `dataclasses` for the module). -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/pyth

Re: [Python-Dev] PEP 557: Data Classes

On 12 October 2017 at 11:20, Steve Holden wrote: > On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller > wrote: > >> >> On 2017-10-12 00:36, Stéfane Fermigier wrote: >> >>> "An object that is not defined by its attributes, but rather by a thread >>> of continuity and its identity." (from https://en.wik

Re: [Python-Dev] PEP 557: Data Classes

On Thu, Oct 12, 2017 at 9:20 AM, Mike Miller wrote: > > On 2017-10-12 00:36, Stéfane Fermigier wrote: > >> "An object that is not defined by its attributes, but rather by a thread >> of continuity and its identity." (from https://en.wikipedia.org/wiki/ >> Domain-driven_design#Building_blocks) >>

Re: [Python-Dev] PEP 557: Data Classes

On 2017-10-12 00:36, Stéfane Fermigier wrote: "An object that is not defined by its attributes, but rather by a thread of continuity and its identity." (from https://en.wikipedia.org/wiki/Domain-driven_design#Building_blocks) Not sure I follow all this, but Python objects do have identities o

Re: [Python-Dev] PEP 557: Data Classes

On 12 October 2017 at 14:49, Mike Miller wrote: > > On 2017-10-11 19:56, Nick Coghlan wrote: > >> From my perspective, the main benefit of a compound name like "data >> class" is that it emphasises a deliberate behavioural choice (adopted from >> attrs): data classes are just regular classes, wi

Re: [Python-Dev] PEP 557: Data Classes

On 2017-10-11 19:56, Nick Coghlan wrote: From my perspective, the main benefit of a compound name like "data class" is that it emphasises a deliberate behavioural choice (adopted from attrs): data classes are just regular classes, with some definition time logic to help define data fields.

Re: [Python-Dev] PEP 557: Data Classes

On 12 October 2017 at 06:33, Mike Miller wrote: > (Apologies for reviving a dead horse, but may not be around at the blessed > time.) > > As potential names of this concept, I liked record and row, but agreed > they were a bit too specific and not quite exact. In my recent (unrelated) > reading

Re: [Python-Dev] PEP 557: Data Classes

(Apologies for reviving a dead horse, but may not be around at the blessed time.) As potential names of this concept, I liked record and row, but agreed they were a bit too specific and not quite exact. In my recent (unrelated) reading however, I came across another term and think it might fi

Re: [Python-Dev] PEP 557: Data Classes

On 9/18/2017 11:37 AM, Ethan Furman wrote: On 09/11/2017 03:28 PM, Guido van Rossum wrote: Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). Hmmm, named constants are one

Re: [Python-Dev] PEP 557: Data Classes

On 09/11/2017 03:28 PM, Guido van Rossum wrote: Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). Hmmm, named constants are one of the motivating factors for having an Enu

Re: [Python-Dev] PEP 557: Data Classes

​I make this suggestion in trepidation, given that Guido called a halt on the Great Naming Debate, but it seems that a short, neutral name with data connotations previously not a part of many popular subsystems is required. I therefore propose "row", which is sufficiently neutral to avoid most cur

Re: [Python-Dev] PEP 557: Data Classes

Thanks for the PEP! :) I like the naming. ;) Though, I would like to add to Michel's argument in favor of a base class. On 11.09.2017 08:38, Michel Desmoulin wrote: - I read Guido talking about some base class as alternative to the generator version, but don't see it in the PEP. Is it still

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-15 05:08, Michel Desmoulin wrote: Because given how convenient it is, it will most probably becomes the default way to write classes in Python. Not just for record. Yes, would have been great if this was how the original object worked and the current barebones object was a base(obj

Re: [Python-Dev] PEP 557: Data Classes

Le 14/09/2017 à 19:24, Mike Miller a écrit : > > On 2017-09-12 21:05, Guido van Rossum wrote: >> It's ironic that some people dislike "data classes" because these are >> regular classes, not just for data, while others are proposing >> alternative names that emphasize the data container aspect.

Re: [Python-Dev] PEP 557: Data Classes

On 15 September 2017 at 02:56, Mike Miller wrote: > > On 2017-09-12 19:09, Nick Coghlan wrote: >> >> On 13 September 2017 at 02:01, Chris Barker - NOAA Federal >> wrote: >>> >>> This really does match well with the record concept in databases, and >>> most >>> people are familiar with that. >> >>

Re: [Python-Dev] PEP 557: Data Classes

Let's all please take a time out from the naming discussion. On Sep 14, 2017 11:15 AM, "Stefan Krah" wrote: > On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote: > > On 2017-09-14 10:45, Stefan Krah wrote: > > >I'd expect something like a C struct or an ML record. > > > > Struct is take

Re: [Python-Dev] PEP 557: Data Classes

On Thu, Sep 14, 2017 at 11:06:15AM -0700, Mike Miller wrote: > On 2017-09-14 10:45, Stefan Krah wrote: > >I'd expect something like a C struct or an ML record. > > Struct is taken, and your second example is record. *If* the name were collections.record, I'd expect collections.record to be someth

Re: [Python-Dev] PEP 557: Data Classes

On Sep 14, 2017, at 09:56, Mike Miller wrote: > Record is the most common name for this ubiquitous concept. Mind if we call them Eric Classes to keep it clear? Because if its name is not Eric Classes, it will cause a little confusion. g’day-bruce-ly y’rs, -Barry signature.asc Description:

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-14 10:45, Stefan Krah wrote: I'd expect something like a C struct or an ML record. Struct is taken, and your second example is record. from dataclass import dataclass This is more intuitive, since the PEP example also has attached methods like total_cost(). I don't think t

Re: [Python-Dev] PEP 557: Data Classes

On Thu, Sep 14, 2017 at 10:24:52AM -0700, Mike Miller wrote: > An elegant name can make the difference between another obscure > module thrown in the stdlib to be never seen again and one that gets > used every day. Which is more intuitive? > > from collections import record I'd expect somet

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-12 21:05, Guido van Rossum wrote: It's ironic that some people dislike "data classes" because these are regular classes, not just for data, while others are proposing alternative names that emphasize the data container aspect. So "data classes" splits the difference, by referring to

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-12 19:09, Nick Coghlan wrote: On 13 September 2017 at 02:01, Chris Barker - NOAA Federal wrote: This really does match well with the record concept in databases, and most people are familiar with that. No, most people aren't familiar with that - they only become familiar with it *

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/2017 11:08 PM, Nathaniel Smith wrote: Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the fiel

Re: [Python-Dev] PEP 557: Data Classes

On Tue, Sep 12, 2017 at 7:09 PM, Nick Coghlan wrote: > So in this case, the vagueness of "data class" is considered a feature > - since it doesn't inherently mean *anything*, folks are more likely > to realise that they need to look up "Python data class", and if I > search for that in a private

Re: [Python-Dev] PEP 557: Data Classes

On 13 September 2017 at 02:01, Chris Barker - NOAA Federal wrote: > This really does match well with the record concept in databases, and most > people are familiar with that. No, most people aren't familiar with that - they only become familiar with it *after* they've learned to program and lear

Re: [Python-Dev] PEP 557: Data Classes

- record +1 This really does match well with the record concept in databases, and most people are familiar with that. Though it will. E a touch confusing until (if ever) most of the database and cab traders, etc start using them. It also matches pretty well with numpy "record arrays": https://

Re: [Python-Dev] PEP 557: Data Classes

> On Sep 12, 2017, at 9:01 AM, Chris Barker - NOAA Federal > wrote: > This really does match well with the record concept in databases, and most > people are familiar with that. Though it will. E a touch confusing until (if > ever) most of the database and cab traders, etc start using them. I

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 8:21 PM, Barry Warsaw wrote: > On Sep 11, 2017, at 19:16, Guido van Rossum wrote: > > > > Or we could just have two arguments, eq= and order=, and > some rule so that you only need to specify one or the other but not both. > (E.g. order=True implies eq=True.) That seems b

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 19:16, Guido van Rossum wrote: > > Or we could just have two arguments, eq= and order=, and some > rule so that you only need to specify one or the other but not both. (E.g. > order=True implies eq=True.) That seems better than needing new constants > just for this flag. Y

Re: [Python-Dev] PEP 557: Data Classes

Or we could just have two arguments, eq= and order=, and some rule so that you only need to specify one or the other but not both. (E.g. order=True implies eq=True.) That seems better than needing new constants just for this flag. On Mon, Sep 11, 2017 at 6:49 PM, Barry Warsaw wrote: > On Sep 11,

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 18:36, Eric V. Smith wrote: > So if we don't do enums, I think the choices are ints, strs, or maybe > True/False/None. Do you have a preference here? > > If int or str, I assume we'd want module-level constants. > > I like the name compare=, and 3 values makes sense: None, E

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/2017 6:28 PM, Guido van Rossum wrote: Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). So if we don't do enums, I think the choices are ints, strs, or maybe True/

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/2017 12:34 PM, Nathaniel Smith wrote: On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote: On 9/10/17 11:08 PM, Nathaniel Smith wrote: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unha

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-11 17:00, Barry Warsaw wrote: I’ve used ‘bag’ too, but I’m not sure that’s descriptive enough for the stdlib. Well, "the Pythons" were irreverent, were they not? ;) -Mike ___ Python-Dev mailing list Python-Dev@python.org https://mail.p

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 16:51, Mike Miller wrote: > > On 2017-09-11 05:26, Eric V. Smith wrote: >> On 9/10/17 10:27 PM, Raymond Hettinger wrote: > > I've typically used these type of objects as records. When in an irreverent > mood I've called them bags. I’ve used ‘bag’ too, but I’m not sure that

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-11 05:26, Eric V. Smith wrote: On 9/10/17 10:27 PM, Raymond Hettinger wrote: I've typically used these type of objects as records. When in an irreverent mood I've called them bags. The short name is helpful as they get used all over the place. I'll add Nick's "declarative" as i

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-10 18:20, Eric V. Smith wrote: I'll think about adding some more language to the PEP about it. Agreed, was only looking for mention or example that a specific type was not required. Perhaps even dusting off the word "annotation" to describe them. ___

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-10 23:38, Michel Desmoulin wrote: I'm going to put some words in explaining why I don't want to use base classes (I don't think it buys you anything). Do you have a reason for preferring base classes? Not preferring, but having it as an alternative. Mainly for 2 reasons: 1 - data

Re: [Python-Dev] PEP 557: Data Classes

On Sep 11, 2017, at 15:16, Ethan Furman wrote: >> >> enum Compare(enum.Enum): >> none = 1 >> unordered = 2 >> ordered = 3 > > I like the enum idea (suprise! ;) but I would suggest "equal" or "equivalent" > instead of "unordered"; better to say what they are rather than what they are

Re: [Python-Dev] PEP 557: Data Classes

Oddly I don't like the enum (flag names get too long that way), but I do agree with everything else Barry said (it should be a trivalue flag and please don't name it cmp). On Mon, Sep 11, 2017 at 3:16 PM, Ethan Furman wrote: > On 09/11/2017 03:00 PM, Barry Warsaw wrote: > >> On Sep 10, 2017, at

Re: [Python-Dev] PEP 557: Data Classes

On 09/11/2017 03:00 PM, Barry Warsaw wrote: On Sep 10, 2017, at 20:08, Nathaniel Smith wrote: I've sometimes wished that attrs let me control whether it generated equality methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the cmp= argument should take an enum with optio

Re: [Python-Dev] PEP 557: Data Classes

On Sep 10, 2017, at 20:08, Nathaniel Smith wrote: > > I've sometimes wished that attrs let me control whether it generated equality > methods (eq/ne/hash) separately from ordering methods (lt/gt/...). Maybe the > cmp= argument should take an enum with options none/equality-only/full? I have ha

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 5:32 AM, Eric V. Smith wrote: > On 9/10/17 11:08 PM, Nathaniel Smith wrote: >> >> Hi Eric, >> >> A few quick comments: >> >> Why do you even have a hash= argument on individual fields? For the >> whole class, I can imagine you might want to explicitly mark a whole >> class

Re: [Python-Dev] PEP 557: Data Classes

On Mon, Sep 11, 2017 at 6:51 AM, Eric V. Smith wrote: > On 9/11/17 9:43 AM, tds...@mailbox.org wrote: > >> Hi Eric, >> >> I have on question not addressed yet. >> The implementation is based on "__annotations__" where the type is >> specified. >> But "__annotations__" is not always filled. An int

Re: [Python-Dev] PEP 557: Data Classes

Hi Eric, I have on question not addressed yet. The implementation is based on "__annotations__" where the type is specified. But "__annotations__" is not always filled. An interpreter version with special optimization could remove all __annotations__ for performance reasons. (Discussed in other

Re: [Python-Dev] PEP 557: Data Classes

On 9/11/17 9:43 AM, tds...@mailbox.org wrote: Hi Eric, I have on question not addressed yet. The implementation is based on "__annotations__" where the type is specified. But "__annotations__" is not always filled. An interpreter version with special optimization could remove all __annotations_

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/17 11:08 PM, Nathaniel Smith wrote: Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the field-lev

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/17 10:27 PM, Raymond Hettinger wrote: On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote: And now I've pushed a version that works with Python 3.6 to PyPI at https://pypi.python.org/pypi/dataclasses It implements the PEP as it currently stands. I'll be making some tweaks in the comin

Re: [Python-Dev] PEP 557: Data Classes

On 11 September 2017 at 12:27, Raymond Hettinger wrote: > Once you get agreement on the functionality, name bike-shedding will likely > be next. In a way, all classes are data classes so that name doesn't tell me > much. Instead, it would be nice to have something suggestive of what it > actu

Re: [Python-Dev] PEP 557: Data Classes

Le 10/09/2017 à 18:36, Eric V. Smith a écrit : > On 9/10/2017 10:00 AM, Michel Desmoulin wrote: >> The reaction is overwhelmingly positive everywhere: hacker news, reddit, >> twitter. > > Do you have a pointer to the Hacker News discussion? I missed it. Err... I may have been over enthusiastic

Re: [Python-Dev] PEP 557: Data Classes

Hi Eric, A few quick comments: Why do you even have a hash= argument on individual fields? For the whole class, I can imagine you might want to explicitly mark a whole class as unhashable, but it seems like the only thing you can do with the field-level hash= argument is to create a class where t

Re: [Python-Dev] PEP 557: Data Classes

> On Sep 10, 2017, at 4:54 PM, Eric V. Smith wrote: > > And now I've pushed a version that works with Python 3.6 to PyPI at > https://pypi.python.org/pypi/dataclasses > > It implements the PEP as it currently stands. I'll be making some tweaks in > the coming weeks. Feedback is welcomed. > >

Re: [Python-Dev] PEP 557: Data Classes

> On Sep 10, 2017, at 5:13 PM, Mike Miller wrote: > > Thanks for the info. > > On 2017-09-08 15:40, Eric V. Smith wrote: >>> - Are types required? >> Annotations are required, the typing module is not. >>> Maybe an example or two with Any? >> I'd rather leave it like it is: typing is reference

Re: [Python-Dev] PEP 557: Data Classes

On 9/8/2017 11:01 AM, Eric V. Smith wrote: Oops, I forgot the link. It should show up shortly at https://www.python.org/dev/peps/pep-0557/. And now I've pushed a version that works with Python 3.6 to PyPI at https://pypi.python.org/pypi/dataclasses It implements the PEP as it currently stand

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-10 14:23, Ivan Levkivskyi wrote: This is not the case, static support for dataclasses is an import point of motivation. I've needed this functionality a decade before types became cool again. ;-) It is hard to support static typing for many third party packages like attrs, since

Re: [Python-Dev] PEP 557: Data Classes

On 10 September 2017 at 23:05, Mike Miller wrote: > [...] > As the problem this PEP is solving is orthogonal to typing improvements > This is not the case, static support for dataclasses is an import point of motivation. It is hard to support static typing for many third party packages like attr

Re: [Python-Dev] PEP 557: Data Classes

Thanks for the info. On 2017-09-08 15:40, Eric V. Smith wrote: - Are types required? Annotations are required, the typing module is not. Maybe an example or two with Any? I'd rather leave it like it is: typing is referenced only once, for ClassVar. Guess I really meant "object" or "ty

Re: [Python-Dev] PEP 557: Data Classes

Thanks for the info. On 2017-09-08 15:40, Eric V. Smith wrote: - Are types required? Annotations are required, the typing module is not. Maybe an example or two with Any? I'd rather leave it like it is: typing is referenced only once, for ClassVar. Guess I really meant "object" or "ty

Re: [Python-Dev] PEP 557: Data Classes

On Sun, Sep 10, 2017 at 9:36 AM, Eric V. Smith wrote: > On 9/10/2017 10:00 AM, Michel Desmoulin wrote: > >> - any chance it becomes a built in later ? When classes have been >> improved in Python 2, the object built-in was added. Imagine if we had >> had to import it every time... Or maybe just p

Re: [Python-Dev] PEP 557: Data Classes

On 9/10/2017 10:00 AM, Michel Desmoulin wrote: The reaction is overwhelmingly positive everywhere: hacker news, reddit, twitter. Do you have a pointer to the Hacker News discussion? I missed it. People have been expecting something like that for a long time. Me, too! 3 questions: - is pr

Re: [Python-Dev] PEP 557: Data Classes

The reaction is overwhelmingly positive everywhere: hacker news, reddit, twitter. People have been expecting something like that for a long time. 3 questions: - is providing validation/conversion hooks completely out of the question of still open for debate ? I know it's to keep the implementati

Re: [Python-Dev] PEP 557: Data Classes

On 9/9/2017 11:41 AM, Gustavo Carneiro wrote: Hi, it is not clear whether anything is done to total_cost:     def total_cost(self) -> float: Does this become a property automatically, or is it still a method call?  To that end, some examples of *using* a data class, not just defining one, wo

Re: [Python-Dev] PEP 557: Data Classes

Hi, it is not clear whether anything is done to total_cost: def total_cost(self) -> float: Does this become a property automatically, or is it still a method call? To that end, some examples of *using* a data class, not just defining one, would be helpful. If it remains a normal method, why

Re: [Python-Dev] PEP 557: Data Classes

Hi, first post here. My two cents: Here's a list of "prior arts" that I have collected over the years, besides attrs, that address similar needs (and often, much more): - https://github.com/bluedynamics/plumber - https://github.com/ionelmc/python-fields - https://github.com/frasertweedale/elk -

Re: [Python-Dev] PEP 557: Data Classes

On 9 September 2017 at 01:00, Guido van Rossum wrote: > I think it would be useful to write 1-2 sentences about the problem with > inheritance -- in that case you pretty much have to use a metaclass, > > It is not the case now. I think __init_subclass__ has almost the same possibilities as a deco

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-08 07:57, Eric V. Smith wrote: I've written a PEP for… Apologies for the following list dumb questions and bikesheds: - 'Classes can be thought of as "mutable namedtuples with defaults".' - A C/C++ (struct)ure sounds like a simpler description that many more would understan

Re: [Python-Dev] PEP 557: Data Classes

I think it would be useful to write 1-2 sentences about the problem with inheritance -- in that case you pretty much have to use a metaclass, and the use of a metaclass makes life harder for people who want to use their own metaclass (since metaclasses don't combine without some manual intervention

Re: [Python-Dev] PEP 557: Data Classes

On 9/8/17 3:20 PM, Mike Miller wrote: On 2017-09-08 07:57, Eric V. Smith wrote: I've written a PEP for… Apologies for the following list dumb questions and bikesheds: - 'Classes can be thought of as "mutable namedtuples with defaults".' - A C/C++ (struct)ure sounds like a simpler descrip

Re: [Python-Dev] PEP 557: Data Classes

On 2017-09-08 07:57, Eric V. Smith wrote: I've written a PEP for… Apologies for the following list dumb questions and bikesheds: - 'Classes can be thought of as "mutable namedtuples with defaults".' - A C/C++ (struct)ure sounds like a simpler description that many more would understan

Re: [Python-Dev] PEP 557: Data Classes

On 09/08/2017 11:38 AM, Steven D'Aprano wrote: On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote: def __eq__(self, other): if other.__class__ is self.__class__: return (self.name, self.unit_price, self.quantity_on_hand) == (other.name, other.unit_price, other.qua

Re: [Python-Dev] PEP 557: Data Classes

On Fri, Sep 08, 2017 at 10:37:12AM -0700, Nick Coghlan wrote: > > def __eq__(self, other): > > if other.__class__ is self.__class__: > > return (self.name, self.unit_price, self.quantity_on_hand) == > > (other.name, other.unit_price, other.quantity_on_hand) > > return NotIm

  1   2   >