Anthony <anthonysar...@gmail.com> added the comment:
Vedran thank you for the detailed comments. I want to separate the idea side and implementation: The idea is having defaults expressed in a way of least surprise and in the least amount of code. Specifically that [1] makes more sense then field(default_factory=lambda: [1]) or more generally that default makes more sense then field(default_factory=lambda: default) I agree there's a lot lacking in my example starting point implementation. Let's not let what's lacking in that implementation distract from the spirit of the idea. The scope of that example is meat to illustrate creating a default that is of least surprising, specifically that a new instance of a class is isolated. But I think the point of whether or not the default is isolated feels like a distraction. If a motivation for using type annotations is to restrict to reduce errors. To me, "prototyping" defaults by having them declared as soon as possible in the class is a further restriction. I believe that's a reasonable coding practice, and actually a good thing. To me this is the current situation, in order to setup a class using @dataclass a user must either: a) Have a relatively in depth understanding of python. I think proofs of that include both PEP having to have a section justifying that. And that there was such discussion in the issue. A point of higher level languages is to nicely abstract lower level APIs, if I have to learn the lower level API in order to use the language it reduces the benefit, and that's really what the points made sound like. b) Calling two "special" / additional functions and adding a (relatively) large amount of code. I can't think of anything else in python where the default method requires knowing two separate additional functions! Python is all about short, semantically meaningful expressions yet this feels like the total opposite! If setting up defaults is a common point of error or "bad code" then why not setup the standard library in such a way that it does it right? ie that a user can specify the default they want and the library sets up the default in the right way. If that's as a separate object, or a mutable object, either way. The point being that setting up a default should be straightforward. This is my first attempt at a contribution, even if all it is is highlighting a problem and the "solution" I'm suggesting may be the wrong one. But so far all of comments feel like they are defending a cascade of "not ideal" situations. Let's try actually looking at the root from the user's perspective and how can we improve this! ---------- nosy: +gvanrossum _______________________________________ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue38758> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
