On Sat, Apr 30, 2022 at 2:17 PM Pablo Alcain <pabloalc...@gmail.com> wrote:
> >>> B) Most __init__ params need specialized behavior, and are quite >> distinct from what's needed by __eq__ and __repr__ >> >> (B) is well covered by the current, you-need-to-specify-everything >> approach. >> > > I don’t see B as a “extreme approach”. > It's not and "extreme" approach -- it's one end of a continuum. > I think that comparing python classes with the specific dataclass is not > helpful. The B scenario is simply the > > $ grep -Ie "self\.\(\w\+\) = \1" -r cpython/Lib | wc > 2095 > > I did the same in two libraries that I use regularly: pandas and > scikit-learn: > > $ grep -Ie "self\.\(\w\+\) = \1" -r sklearn | wc -l > 1786 > > $ grep -Ie "self\.\(\w\+\) = \1" -r pandas | wc -l > 650 > > That’s a total of ~4.5k lines of code (again, this is an overestimation, > but it can give us an idea of the ballpark estimate) > That, well, is pretty much useless, if I understand the re correctly -- the fact that a class is assigning to self doesn't mean it's directly assigning the parameters with no other logic. And any number of those self assignments could be in non-__init__ methods. All that shows is that instance attributes are used. I don't think anyone is questioning that. For a better and more fine-grained analysis, Quimey wrote this small > library (https://github.com/quimeyps/analize_autoassign) that uses the > Abstract Syntax Tree to analyze a bunch of libraries and identify when the > “autoassign” could work. > It shows that out of 20k analyzed classes in the selected libraries > (including black, pandas, numpy, etc), ~17% of them could benefit from the > usage of auto-assign syntax. > I only read English, and haven't studied the coe, so I don't know how that works, but assuming it's accurately testing for the simple cases that auto-assigning could work for; That's not that much actually -- for approx every six-parameter function, one of them could be auto-assigned. or for every six functions, one could make good use of auto-assignment (and maybe be a dataclass?) So it looks like the isolated pattern of `self.<something> = <something>` > is used a lot. > I don't think that's ever been in question. The question, as I see it, is what fraction of parameters could get auto-assigned in general -- for classes where dataclasses wouldn't make sense. And I'm not trying to be a Negative Nelly here -- I honestly don't know, I actually expected it to be higher than 17% -- but in any case, I think it should be higher than 17% to make it worth a syntax addition. But pandas and numpy may not be the least bit representative -- maybe run the most popular packages on PyPi? I thought I made this point, but it seems to have gotten lost: What I'm saying is that, for example, if a class __init__ has 6 parameters, and one of them could be auto-assigned, then yes, auto-assigning could be used, but you really haven't gained much from that -- it would not be worth the syntax change. And any class with an __init__ in which most or all parameters could be auto-assigned -- then those might be a good candidate for a dataclass. So how many are there where say, more than half of __init__ parameters could be auto-assigned, where dataclasses wouldn't be helpful? A lot? then, yes, new syntax may be warranted. But, obviously, it entails a further of discussion whether it makes sense > to add new syntax for this, considering the maintenance that it implies. > It's not so much the maintenance -- it's the transition burden, and the burden of yet more complexity in the language, particularly parameters/arguments: Try to teach a newbie about arguments/parameters in Python, there is a remarkable complexity there already: positional vs keyword *args, **kwargs keyword-only. (and all of these from both the caller and callee perspective) That's a lot of possible combinations -- believe me, it's pretty darn complex and hard to explain! -CHB -- 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/QLYDWJBVMVKRE2RRN7WFCVUQWOEFMHOE/ Code of Conduct: http://python.org/psf/codeofconduct/
