Regarding the usage of a decorator to do the auto-assignment, I think that it has an issue regarding how to select a subset of the variables that you would be setting. In the general case, you can probably get away with calling `autoassign`. But, for example, if you want to set a but not b, you'd probably have to use a string as the identifier of the parameters that you want to assign: ``` class MyKlass: @autoassign('a') def __init__(self, a, b): print(b) ``` This, in my perspective, brings two things: the first one is that you'd be repeating everywhere the list of names, so for example doing refactors like changing a variable name would be a bit error-prone: If you change the variable from `a` to `my_var_name`, you'd have to also change the list in the autoassign. It's not a lot, but it can induce some errors because of the repetition. On the other hand, I guess it would be a bit hard for IDEs and static checkers to follow this execution path. I know that I'm only one data point, but for what it's worth, I was very excited with the idea but this prevented me from actually implementing this solution on a day-to-day basis: it felt a bit fragile and induced me to some errors. About dataclasses, the point that Chris mentions, I think that they are in a different scope from this, since they do much more stuff. But, beyond this, a solution on the dataclass style would face a similar scenario: since the `__init__` is autogenerated, you would also be in a tight spot in the situation of "how would I bind only one of the items?". Again, now I'm talking about my experience, but I think that it's very hard to think that we could replace "classes" with "dataclasses" altogether. Here's an example of one of the (unexpected for me) things that happen when you try to do inheritance on dataclasses: https://peps.python.org/pep-0557/#inheritance. Overall, I think that it's hard to think about a solution to this problem that is clean and robust without adding new syntax with it. I would like to hear your thoughts on this (and everyone else's of course!) Cheers, Pablo On Mon, Apr 18, 2022 at 9:55 PM Christopher Barker <pythonchb@gmail.com> wrote:
On Mon, Apr 18, 2022 at 4:24 PM Joao S. O. Bueno <jsbueno@python.org.br> wrote:
I for one am all for the inclusion of a decorator targeting either the __init__ method or the class itself to perform this binding of known arguments to instance attributes prior to entering __init__. It could live either in functools or dataclasses itself.
Isn’t this what dataclasses already accomplish? I understand that it’s the reverse— with a dataclass, you specify the fields, and the __init__ is generated, whereas this proposal is ttt be at you’d write an __init__, and the attributes would be set — but other than taste, is there a practical difference?
-CHB
On Sat, Apr 16, 2022 at 5:49 PM Pablo Alcain <pabloalcain@gmail.com> wrote:
The problem of assigning init arguments as attributes has appeared several times in the past ( https://mail.python.org/archives/list/python-ideas@python.org/message/VLI3DO... was the most recent we could find) and is already handled in dataclasses.
Lately, discussing this topic with a friend, we thought that using a specific token could be a possible approach, so you could do:
class MyClass:
def __init__(self, @a, @b, c):
pass
and it would be analogous to doing:
class MyClass:
def __init__(self, a, b, c):
self.a = a
self.b = b
Then, you would instantiate the class as usual, and the variables tagged with `@` would be bound to the object:
objekt = MyClass(2, 3, 4)
print(objekt.b)
3
print(objekt.c)
AttributeError: 'MyClass' object has no attribute 'c'
We have a working implementation here if anyone wants to take a look at: https://github.com/pabloalcain/cpython/tree/feature/auto_attribute. Keep in mind that we have limited knowledge about how to modify cpython itself, and which would the best places be to do the modifications, so it's more than likely that some design decisions aren't very sound ( https://devguide.python.org/grammar/ and https://devguide.python.org/parser/ were incredibly helpful).
Besides the implementation, we would like to know what the community thinks on whether this might have any value. While developing this, we realized that Crystal already has this feature (eg https://github.com/askn/crystal-by-example/blob/master/struct/struct.cr) with the same syntax; which is kind of expected, considering it's syntax is based on Ruby.
Random collection of thoughts:
1. If auto-assignment made sense in general, one of the reasons we went for this rather than the decorator approach is that we wouldn't like to have a list of strings that can vary decoupled from the actual argument name.
2. The current implementation of `@` works for any function, not only init. We don't know if this would actually be a desirable feature.
3. It also works with any function in the wild. This mostly allows for monkey-patching to work out of the box:
class Klass:
... def __init__(self):
... pass
...
def add_parameter(k, @p):
... pass
...
Klass.add_parameter = add_parameter
objekt = Klass()
print(objekt.p)
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'Klass' object has no attribute 'p'
objekt.add_parameter(11)
print(objekt.p)
11
Again, we are not sure if this is desirable, but it's what made most sense for us at the moment.
4. Adding the `@` token to the argument doesn’t remove the variable from the function/method scope, so this would be perfectly valid:
def my_function(k, @parameter):
... print(parameter)
my_function(objekt, 4)
4
k.parameter
4
5. We didn’t implement it for lambda functions.
Cheers,
Pablo and Quimey
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/SCXHEW... Code of Conduct: http://python.org/psf/codeofconduct/
_______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-leave@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/HUGRGX... Code of Conduct: http://python.org/psf/codeofconduct/
-- Christopher Barker, PhD (Chris)
Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython