PERF: extract_array -> _values

[jbrockmendel]

Found that grepping for uses of pd.array is a PITA, so went through and changed them all (inside core) to pd_array. @MarcoGorelli would it be feasible to make a code check for this?

[MarcoGorelli]

Should we then also use consistently pd_array in tests and remove the line

pandas/scripts/check_for_inconsistent_pandas_namespace.py

Line 32 in 95a86a9

"array", # `import array` and `pd.array` should both be allowed

? cc @jorisvandenbossche as you're commented on pd_array previously

[jbrockmendel]

Should we then also use consistently pd_array in tests and remove the line

another option would be to define it pd_array in core.construction and import it into the pd namespace as array

[jorisvandenbossche]

Should we then also use consistently pd_array in tests and remove the line

For me this PR doesn't change what I said previously about it. In tests we should prefer to use public API where possible, this PR is about internal imports.

another option would be to define it pd_array in core.construction and import it into the pd namespace as array

That doesn't solve the issue that I want it as pd.array in the tests, though ;)

[MarcoGorelli]

understood - thanks for explaining!

[jreback]

any non-trivial perf impact?

and should we have a rule for internal tests? (to use pd_array)?

[jbrockmendel]

another option would be to define it pd_array in core.construction and import it into the pd namespace as array

That doesn't solve the issue that I want it as pd.array in the tests, though ;)

Maybe I communicated poorly. The ideas was that pd.__init__ could have from pandas.core.construction import pd_array as array, so tests could still use pd.array or from pandas import array

[jorisvandenbossche]

@jbrockmendel I understood that correctly ;) (but so then it doesn't matter for tests, and since you were replying to Marco's comment about tests, I thought it was related to that)