On Mon, May 2, 2022 at 7:42 PM Steven D'Aprano <st...@pearwood.info> wrote:
> 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.
Now you get it :-)
What you describe as "flexible" I describe as "overcomplex". All that
> extra complexity to just avoid writing a class and methods.
I don’t think much of that complexity is exposed if you don’t need it.
I'm saying that all classes contain, at their core, a record of named
> fields containing data.
Exactly — which is why data classes can be a base for a lot of use cases.
Anyway, I think thee we conversation has moved beyond this.
-CHB
--
Christopher Barker, PhD (Chris)
Python Language Consulting
- Teaching
- Scientific Software Development
- Desktop GUI and Web Development
- wxPython, numpy, scipy, Cython
_______________________________________________
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/JY5FLNRRGTYNGFRZBH7EU3U335ZP2MGD/
Code of Conduct: http://python.org/psf/codeofconduct/
