Back

@glyph I think I would prefer the split some other languages already have, between classes and some kind of "record" type whose primary purpose is to be a data-carrying object (which is what I always used tuples for in Python).

At least, if I'm reading it correctly, the things that would benefit most from your proposal are things that primarily are being used as data-carrying objects: primarily-behavior-carrying or mixed-behavior-and-data-carrying objects tend not to be reducible to that kind of simple definition syntax and will usually want to do enough custom stuff that you're writing an __init__() anyway.

@ubernostrum I see this pattern in other OO-ish languages and I really don't get it. Python's an OO language, a container for data *is* an object, that's how you express a collection of attributes. like the only way this would make sense to me is if we added some form of *truly* private variables to classes, where methods exist in a closure with all fields 'nonlocal' by default like some Scheme object models

@ubernostrum re: writing an __init__ anyway, I'm slowly coming to regard __init__ as a bit of an antipattern. __init__ should never do anything but set attributes, if you have custom construction behavior, it makes more sense to have a custom classmethod factory, which can also do things like raising an exception before allocating the object itself as __new__ would, or return new subtypes in some cases to allow for easier API evolution

@glyph @ubernostrum
Even though this is all hard for me to follow from my more novice perspective... I did just start using @hynek attrs library, and started thinking about all of this inadvertently. Actually using the library helped dissuade me from hooking into the initialization in the first place, and I found that a classmethod works better for my purposes.

Anyway, thanks for the discussion.

Here's the bit from attrs docs that helped me:

https://www.attrs.org/en/stable/init.html#hooking-yourself-into-initialization