On Wed, Apr 20, 2022 at 12:30 PM Pablo Alcain <pabloalc...@gmail.com> wrote:
>
> 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.
>
IMO, that is trivially resolvable by doing the decorator, by default,
assign all parameters. If it tkaes a string or sequence with parameter
names, then, it will just bind those (still shorter than one line
`self.attr = attr` for each attribute.
And for the fragility: that is the advantage of having a robust
implementation of something like this on the stdlib: it is not something
most people will go out of their way to write their own, since the tradeoff
is just
copy and paste a bunch of plain assignments.
But having it right and known, could chop off tens of lines of useless code
in, probably the majority of Python projects.
Also answering Christopher Barker:
This has a subtle, but different use than dataclasses.
It might be grouped in the dataclasses module, on the stdlib.
>
> 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/ZEUFH6343EIN3REU4LFT7MMQJLSZLSL2/
Code of Conduct: http://python.org/psf/codeofconduct/
