On 4/19/20 11:28 AM, David Mertz wrote: > On Sun, Apr 19, 2020, 7:24 AM Richard Damon <[email protected] > <mailto:[email protected]>> wrote: > > One of the key motivations of this proposal is to make nicer a > call with a lot of key word arguments where the local > variable name happens (intentionally) to match the keyword > parameter name. > > > I think Stephen said that this "same name across scopes" is an > anti-pattern. I mostly disagree, though obviously agree that it varies > between different code. He mentioned something like: > > process_account(name=name, email=email) > > And that would be better with email_john and email_jane as names in > outer scope. > > I've worked with large code bases where the equivalent complex object > is used in many places. Not necessarily as a continuous life of an > actual object, but sometimes sent as JSON, other times read from > database, other times calculated dynamically, etc. > > For example, maybe there is a 'person_record' that has as > attributes/keys/whatever name and email. But in this existing code, a > different name is used through a call chain and in different corners > of the code. E.g. we read json_record, which calls something naming it > dynamic_record, which eventually arrives at a function that saves > db_record. But these are all actually the same object layout or even > the same object. > > When it comes time to refactor—now we need to rename 'telephone' as > 'home_phone' and add 'cell_phone'—finding all the locations to change > is a PITA. If only we could grep 'person_record' globally, it would > have been easy.
As with most anti-patterns, there tend to be cases where they actually help (which is why some think of them as a useful pattern), but then it get applied beyond the cases where it is actually useful, and then becomes the anti-pattern. My personal thought on the case you are presenting, is that I would be tempted to grep for telephone, to change that because the change likely affects not just this given structure, but may also impact related structures which also assumed a single phone number. -- Richard Damon _______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/PFSCBT3GATRPUPSQR4DFX4SVCJXFJUTH/ Code of Conduct: http://python.org/psf/codeofconduct/
