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

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

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

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

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

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,

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

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

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

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

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

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"

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

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

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

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:

[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",

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

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

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 >

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

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

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

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

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/ >>

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

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

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

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

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/ >>

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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":

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,

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.

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 >

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

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

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

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

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

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’

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

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

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: > >>

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

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

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

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

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

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

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

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

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

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.

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

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

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,

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

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

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

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

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

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

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,

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

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

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

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

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

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,

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

  1   2   >