[Python-ideas] Re: mro and super don't feel so pythonic
malmiteria writes: > Stephen J. Turnbull writes > > Every feature means making an arbitrary choice that may or may > > not be what the programmers wanted. > > I don't think that's what greg meant. I don't either. That's a separate comment that I made about the nature of developing a product (namely, Python itself). Greg wasn't commenting on that, and he may or may not agree with me -- I'm pretty sure he'll *understand* the point. Whether he agrees doesn't matter for the point I was making, which was about how *I* interpret "when faced with uncertainty, refuse to guess." > they can take the time to learn C3 in depth. Which most people > don't, so they are left guessing. So what? It rarely matters, and if it does, it almost never does real harm because people who depend on super in MI contexts generally do know what they're doing and design for success. If it does do harm, somebody was being too tricky for their own good. Sure, the too tricky somebody may be a library author (hello, Django) in which case the person we're worried about is innocent collateral damage. I'm afraid that person is going to have to put out the effort to learn what the MRO is and how it works, or consult someone who already knows. In any case, I don't see evidence that such collateral damage is anything but a theoretical possibility. Steve ___ 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/L4M3N4TNGVS4F7HLGYQ5XT7ADKQGDKAE/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
On Mon, Apr 18, 2022 at 4:24 PM Joao S. O. Bueno 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 > 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 "", line 1, in >> >> 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,
[Python-ideas] Re: mro and super don't feel so pythonic
On 18/04/22 7:29 pm, malmiteria wrote: It's an arbitrary choice that the C3 feature itself makes, and the programmer is left guessing what that choice was, unless they can take the time to learn C3 in depth. Even if you do, it's still an arbitrary choice to prefer the leftmost method, which might be what you want or might not. The "guessing" in the Zen is a tongue-in-cheek way of referring to picking something as a default when there isn't any strong reason to think it will be what is most often wanted. If there's any literal guessing involved, it's on the part of the language designer. -- Greg ___ 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/JEHUSQKTLQQGA7FEVPMQI5TAZP6VZ4L7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Auto assignment of attributes
There is no need for a whole new syntax for what can trivially be accomplished by a decorator, and a simple one, in this cases. 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. On Sat, Apr 16, 2022 at 5:49 PM Pablo Alcain 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 "", line 1, in > > 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/
[Python-ideas] Re: mro and super don't feel so pythonic
Stephen J. Turnbull writes > Every feature means making an arbitrary choice that may or may not be > what the programmers wanted. I don't think that's what greg meant. It's not an arbitrary choice between multiple possible features that would cover the same need. It's an arbitrary choice that the C3 feature itself makes, and the programmer is left guessing what that choice was, unless they can take the time to learn C3 in depth. Which most people don't, so they are left guessing. And since the feature doesn't tell what it does, from within the language itself (or in other term, reading the program doesn't tell you what it does), it's fair to say there's some guessing involved in it, for most programmers. ___ 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/5XSJIB5RP6Q3HK3RD5622J3BXLRPJR7K/ Code of Conduct: http://python.org/psf/codeofconduct/
