On Sun, May 1, 2022 at 1:16 AM Steven D'Aprano <steve@pearwood.info> wrote:
Absolutely. However, this is not an "all Classes" question. Isn't it? I thought this was a proposal to allow any class to partake in
On Sat, Apr 23, 2022 at 12:11:07PM -0700, Christopher Barker wrote: the dataclass autoassignment feature.
Yes, any class could use this feature (though it's more limited than what dataclasses do) -- what I was getting is is that it would not be (particularly) useful for all classes -- only classes where there are a lot of __init__ parameters that can be auto-assigned. And that use case overlaps to some extent with dataclasses. Perhaps your answer isn't as clear as you think it is.
apparently not.
But do think they are for classes that are primarily about storing a defined set of data.
Ah, mutable named tuples, with or without defaults? :-)
well, no. - the key is that you can add other methods to them, and
"primarily" -- but the key difference is that dataclasses are far more customisable and flexible. They are more like "classes with boiler plate dunders auto-generated" That is, a lot more like "regular" classes than they are like tuples. Whereas namedtupels are , well, tuples where the item have names. That's kinda it. produce
all sort of varyingly complex functionality.
Named tuples support all of that too.
No, they don't -- you can add methods, though with a klunky interface, and they ARE tuples under the hood which does come with restrictions. And the immutability means that added methods can't actually do very much. One of the reasons I have not glommed onto dataclasses is that for my
purposes, they don't seem to add much that named tuples didn't already give us.
ahh -- that may be because you think of them as "mutable named tuples" -- that is, the only reason you'd want to use them is if you want your "record" to be mutable. But I think you miss the larger picture.
* Record- or struct-like named fields? Check.
* Automatic equality? Check.
* Nice repr? Check.
* Can add arbitrary methods and override existing methods? Check.
that's a little klunky though, isn't it? Have you seen much use of named tuples like that? For that matter do folks do that with tuples much either? Perhaps named tuples offer *too much**:
* Instances of tuple; * Equality with other tuples;
Yes, that can be a downside, indeed. and maybe dataclasses offer some features I haven't needed yet, but it
seems to me that named tuples and dataclasses are two solutions to the same problem: how to create a record with named fields.
I suspect you may have missed the power of datclasses because you started with this assumption. Maybe it's because I'm not much of a database guy, but I don't think in terms of records. For me, datclasses are a way to make a general purpose class that hold a bunch of data, and have the boilerplate written for me. And what dataclasses add that makes them so flexible is that they: - allow for various custom fields: - notably default factories to handle mutable defaults - provide a way to customise the initialization - and critically, provide a collection of field objects that can be used to customize behavior. All this makes them very useful for more general purpose classes than a simple record. I guess a way to think if them is this: if you are writing a class in which the __init__ assigns most of the parameters to the instance, then a dataclass could be helpful. which is why I think they solve *part* of the problem that special auto assigning syntax would solve. Not all of the problem, which is why I'm suggesting that folks find evidence for how often auto-assigned parameters would be very useful when dataclasses would not. So I don't understand what you think dataclasses are, if you vehemently
deny that they are records (not just one nope, but three).
It's not that they can't be used as records, it's that they can be so much more. After all what is any class but a collection of attributes (some of which may be methods) ?
And since I don't understand your concept of dataclasses, I don't know how to treat your position in this discussion. Should I treat it as mainstream, or idiosyncratic? Right now, it seems pretty idiosyncratic.
perhaps it is -- the mainstream may not have noticed how much one can do with dataclasses.
But anyway, the rest of my post was the real point, and we're busy arguing
semantics here.
Well yes, because if we don't agree on semantics, we cannot possibly communicate.
sure -- I should have been more explicit -- arguing about what "mutable named tuple" means didn't seem useful. But in retrospect I was wrong -- it may matter to this discussion, and that's why I originally pointed out that I don't think of dataclasses as "mutable named tuples" -- perhaps I should have said not *only* mutable named tuples. The relevant point here is that I'm suggesting there are uses for dataclasses that go beyond a simple record that happens to be mutable -- i.e. classes that do (potentially much) more than simply get and set attributes. Which means that someone that needs to assign a lot of parameters to self, but doesn't think they are writing a simple record may well be able to use dataclasses, and thus may not need syntax for auto-assigning paramaters. But one thinks that dataclasses are "mutable named tuples", then then they wont' consider them for more complex needs, and thus may find they really want that auto-assigning syntax.
Semantics is the **meaning of our words and concepts**. If we don't agree on what those words mean, then how do we understand each other?
What I meant by arguing semantics is that we don't need to agree on a brief way to describe dataclasses -- dataclasses are what they are, and are defined by what features they have. That's it. If you want to call them 'mutable namedtuples', fine, just be careful that that doesn't limit what you think they can be used for. -CHB -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython