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 <python...@gmail.com>
wrote:
> On Mon, Apr 18, 2022 at 4:24 PM Joao S. O. Bueno <jsbu...@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 <pabloalc...@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/VLI3DOFA5VWMGJMJGRDC7JZTRKEPPZNU/
>>> 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-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/SCXHEWCHBJN3A7DPGGPPFLSTMBLLAOTX/
>>> Code of Conduct: http://python.org/psf/codeofconduct/
>>>
>> _______________________________________________
>> 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/HUGRGXVT7NBWSXI2ILZOMFIRWV4KIQ5Q/
>> 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
>
_______________________________________________
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/EXJQ66UZLO25LAN5FQPUIKOVLGLMCD7F/
Code of Conduct: http://python.org/psf/codeofconduct/
