On Sun, May 01, 2022 at 10:40:49PM -0700, Christopher Barker wrote:
> 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.
Ah, the penny drops! That makes sense.
> > Named tuples support all of that too.
> >
>
> No, they don't -- you can add methods, though with a klunky interface,
Its the same class+def interface used for adding methods to any class,
just with a call to namedtuple as the base class.
class Thingy(namedtuple("Thingy", "spam eggs cheese")):
def method(self, arg):
pass
I think it is a beautifully elegant interface.
> and they ARE tuples under the hood which does come with restrictions.
That is a very good point.
> And the
> immutability means that added methods can't actually do very much.
TIL that string and Decimal methods don't do much.
*wink*
> > 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.
[...]
> 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.
I'm not a database guy either. When I say record, I mean in the sense of
Pascal records, or what C calls structs. A collection of named fields
holding data.
Objects fundamentally have three properties: identity, state, and
behaviour. The behaviour comes from methods operating on the object's
state. And that state is normally a collection of named fields holding
data. That is, a record.
If your class is written in C, like the builtins, you can avoid
exposing the names of your data fields, thus giving the illusion from
Python that they don't have a name. But at the C level, they have a
name, otherwise you can't refer to them from your C code.
> For me, datclasses are a way to make a general purpose class that hold a
> bunch of data,
I.e. a bunch of named fields, or a record :-)
> and have the boilerplate written for me.
Yes, I get that part.
I just find the boilerplate to be less of a cognitive burden than
learning the details of dataclasses. Perhaps that's because I've been
fortunate enough to not have to deal with classes with vast amounts of
boilerplate. Or I'm just slow to recognise Blub features :-)
> 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.
That sounds like a class builder mini-framework.
What you describe as "flexible" I describe as "overcomplex". All that
extra complexity to just avoid writing a class and methods.
Anyway, I'm not trying to discourage you from using dataclasses, or
persuade you that they are "bad". I'm sure you know your use-cases, and
I have not yet sat down and given dataclasses a real solid workout.
Maybe I will come around to them once I do.
> All this makes them very useful for more general purpose classes than a
> simple record.
I'm not saying that all classes *are* a simple record, heavens not!
I'm saying that all classes contain, at their core, a record of named
fields containing data. Of course classes extend that with all sorts of
goodies, like inheritance, object identity, methods to operate on that
data in all sorts of ways, a nice OOP interface, and more.
Anyway, I think I now understand where you are coming from, thank you
for taking the time to elaborate.
> I'm suggesting that folks find
> evidence for how often auto-assigned parameters would be very useful when
> dataclasses would not.
+1
--
Steve
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/S25Y3L3HAK6XR2VOI7IDFRPBUMCCBOZ3/
Code of Conduct: http://python.org/psf/codeofconduct/
