Back

@glyph You've got a typo in the second code block: the arguments to the import are backwards.

@jamesh correction much appreciated

@jamesh Fix should be live now.

@pawamoy

from what I can tell:

```
@dataclass
class StoresDouble:
original_value: InitVar[int]
value: int = field(init=false)
def __post_init__(self, original_value):
self.value = 2 * original_value
```

@hynek I'd be a lot happier if dataclasses copied attrs's features more precisely (and if there is serious ensuing discussion, I'll be advocating for a second look at some of those, particularly "private" variable handling), but "defining classes" is one of those places where there's a fair amount of benefit to following the language standard even if it's suboptimal.

@hynek /me waves his arms vaguely in the direction of pretty much every Scheme implementation

@zzzeek I think this will really be one of the easier migrations; it can go as fast or as slow as the community wants to dictate and it can live side-by-side for a really long time if necessary.

@carlmjohnson I specifically avoided that one because I didn’t want to use more obscure abbreviations with overloaded meanings :-). Although I knew someone would probably suggest it …

@glyph @carlmjohnson can't because of the stdlib module. For historical reasons we'll go with Pascals record, that surely won't confuse anyone

@mborus in my ideal world this would raise an exception since this class doesn’t have a __c attribute

@mborus how "unexpected"? this is what the distinction between `is` and `==` is for.

@glyph You have a point there, I should use "is" instead of "==" to compare for equal

Unexpected just because "==" ususally worked like "is" unless it's defined differently.

@mborus `==` is supposed to mean "value equality" whereas `is` is supposed to mean "mutability equality". built-in types follow this convention, so why are user-defined types confusingly different?

>>> x = [1, 2, 3]
>>> y = [1, 2, 3]
>>> a = {1: 2, 3: 4}
>>> b = {1: 2, 3: 4}
>>> print(x == y)
True
>>> x.append(1)
>>> print(x == y)
False
>>> print(a == b)
True
>>> b[5] = 6
>>> print(a == b)
False

@glyph Good question.

I don't know why this was chosen. If I had to guess using "is" as a default for "__eq__" is easy to implement and guaranteed that there's always a result to "==".

I always treat "==" as "whatever __eq__ says or defaults to" and changed it for some of my own classes.

To check I looked up the docs (https://docs.python.org/release/3.11.2/library/stdtypes.html#comparisons) and "==" is just defined as "equal" (with no concrete definition what that actually means and the class default of "is" is mentioned)

@tonnydourado frozen defaults to False so I don't know what you mean by "immutability by default". If you hand-roll the whole init, the behavior is still the same.

@glyph I mean if you hand roll the init, you can't use frozen=True at all, because you have to mutate self in the init.

@tonnydourado oh, hmmmm. perhaps a design decision that needs revisiting, given that then init=False, frozen=True is sort of mutually incoherent unless you do gymnastics like this

from dataclasses import dataclass

@dataclass(frozen=True, init=False)
class froz:
a: int
b: str
def __init__(self):
super().__setattr__("a", 7)
super().__setattr__("b", "lol")

print(froz())

@glyph there's another thing that intersects with it: a hand-rolled init is never overwritten, even if you don't set init=False. In fact, even if you set init=True, the init already present in the class will not be overwritten.

@glyph which means you can't just crosscheck frozen and init, for instance, to raise an error.

@tonnydourado maybe there needs to be a different hook? __pre_frozen_init__ or something? this is an ugly edge case

@glyph I feel like this is why god created __new__, but for some reason we never use it?

@glyph Also, dataclasses are a comedy, as currently implemented. attrs is not just a progenitor, it's miles better.

@glyph Doesn't matter. If dataclasses are the default, then there needs to be some support for other use cases. But I can see a new "dataclass" keyword working.

@b11c are mixins even compatible with type annotations? and do dynamically constructed classes even use `class` statements? I don't really understand this criticism.

@glyph 1. Of course they are.
2. Generally no, but can be constructed from different types of classes, with and without attributes.
3. This is not a criticism, I'm just thinking about the common usages.
4. On reflection, I'm actually absolutely certain that dataclasses are a special case and not the other way around.

@b11c

1. huh! I guess they do, you… put a bunch of `@abstractmethod`s on the mixin to say what it needs? I'll have to go fix up some legacy code to do that, at least, where I can't get rid of mixins entirely

2. what is the problem with constructing them from dataclasses, if they are constructed with regular classes?

3. if I'm saying "dataclasses are not a special case" and you are saying "dataclasses are a special case" it feels like definitionally a criticism?

4. agree to disagree

@glyph 1. No, use Protocols.

@b11c I love me a good protocol, but where would you put it in a Mixin?

@glyph Option 1: In the mixin's inheritance tree, like in any other case.

Option 2: Nowhere. That's the beauty of protocols, you don't have to explicitly state it for a class to implement it.

@b11c mixins inherently require things from `self`, so if you do option 2 you get a bunch of type errors when you attempt to use it. but TIL inheriting a protocol in a semi-concrete class is functionally identical to declaring an `@abstractmethod` for all members of that protocol!

@b11c (I don't love the fact that you don't get type errors on any of this stuff until instantiation time, I feel like I really want to know what's concrete and what's abstract explicitly in the implementation. but it's a minor quibble.)

@b11c I'm using it in sense of like "media criticism"; one can criticize an idea and not a person. but fair enough, that is definitely "sense 2" in the dictionary and not obvious when used intransitively

@glyph Fair enough!

@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

@ubernostrum this is probably its own blog post

@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

@SnoopJ believe it or not you’re the first person to say this to me :-)