Refactor: Consolidate import and usage of random

[eumiro]

No description provided.

[uranusjr]

Wow this entire function can use a rewrite. (Not saying you should do it in this PR.)

[Lee-W]

Same as #34113. I'm wondering why we want to consolidate imports this way. Does that mean we should avoid from ... import ... pattern.

[eumiro]

Same as #34113. I'm wondering why we want to consolidate imports this way. Does that mean we should avoid from ... import ... pattern.

I'm suggesting having all imported modules/classes the same way, so in this case there's always import random and not from random import random which could confuse devs. random is a case where direct import random is better, since solitary random() or randrange() may be obvious, but sample() or choice() not.

There are cases where I do from … import …, e.g. collections or pathlib. The most important rule is to be repo-wide-consistent. I also usually do import itertools as it, but the maintainers suggested to keep it as itertools, which I do not object.

[Lee-W]

Same as #34113. I'm wondering why we want to consolidate imports this way. Does that mean we should avoid from ... import ... pattern.

I'm suggesting having all imported modules/classes the same way, so in this case there's always import random and not from random import random which could confuse devs. random is a case where direct import random is better, since solitary random() or randrange() may be obvious, but sample() or choice() not.

There are cases where I do from … import …, e.g. collections or pathlib. The most important rule is to be repo-wide-consistent. I also usually do import itertools as it, but the maintainers suggested to keep it as itertools, which I do not object.

Yep, agree unifying them would be great 👍 Do we want to document it somewhere? (e.g., use import random instead of from random import random)

[potiuk]

I think those kind of rules are rarely read and we have two approaches there that 'work'

a) hope that people will follow what is in the code (not perfect but mostly works) - this is a stage we are currently in

b) better - add pre-commit to do ast parsing and add rules of things we want do not want to have. I'd say it would be great if thos unification that can be done (imports are generally easy) are added as a rule to pre-commits

Maybe you can work with @eumiro together to determine the list of rules that can be automatically verified and and write a pre&commit doing it ?