CLN: Replaced "bool_t" with "builtins.bool"

[ShaharNaveh]

• closes #xxxx
• tests added / passed
• passes black pandas
• passes git diff upstream/master -u -- "*.py" | flake8 --diff
• whatsnew entry

[simonjayhawkins]

Thanks @MomIsBestFriend I like this, but the style guide recommends the alias approach. https://pandas.io/docs/development/contributing.html#style-guidelines

Do you know which approach is best practice?

[ShaharNaveh]

@simonjayhawkins I have to be honest I didn't make this changes with Type annotations in mind, I simply saw bool_t and didn't knew what it was, and thought this changes will not cause future confusion.

And for your question, which approach is the best practice, I really don't know, is there anyone at mypy that we can ask?

[simonjayhawkins]

looking at the solution in ahawker/ulid#26, does that look clearer?

i.e. we define aliases in pandas._typing that use the same name with capitalization.

so the alias for str is Str, bool is Bool etc.

I also like this as it is consistent with dict and Dict (although for a different reason, Dict can accept type parameters)

@WillAyd

[simonjayhawkins]

when rendering the docs, the aliased type is displayed.

can you render the docs for these changes, so we can see the output.

[ShaharNaveh]

The docs looks the same to me:

[simonjayhawkins]

Thanks. I recall a discussion about the added "clutter" to the docs with the addition of type annotations in the function signature. (which to be fair, is redundant since we add the types to the docstring)

[WillAyd]

These might not be required with recent updates to the semantic analyzer so can try that, but otherwise I don't think there's any real benefit to changing

[simonjayhawkins]

These might not be required with recent updates to the semantic analyzer so can try that, but otherwise I don't think there's any real benefit to changing

worth giving it a try, but we should probably keep the "alias trick" as "a good defensive solution"

[jbrockmendel]

I agree with Will. The bool_t definition also has a comment telling us why it is there, which the builtins.bool doesnt

[simonjayhawkins]

I think that perhaps we could move the alias to pandas_typing and add a better explanation and ensure consistency.

in pandas\core\indexes\base.py we have str_t = str and in pandas\core\dtypes\dtypes.py we have str_type = str, neither of which have comments to explain.

in ahawker/ulid#26 the alias is in a shared hints module (equivalent to our pandas_typing)

and looks like...

#: Type hint that is an alias for the built-in :class:`~str` type.
Str = str

I think we should do that for bool here and str in the other two modules mentioned.

( and agree on _t vs _type vs Capitalization)

[ShaharNaveh]

Do we support float16?

[simonjayhawkins]

Do we support float16?

#32449 should fix that.

[WillAyd]

Would have to search but fairly certain what we have now is the suggested approach by Guido / mypy folks.

Do any of these. alternatives have a clear benefit? If not I think should just close

[ShaharNaveh]

Do any of these. alternatives have a clear benefit? If not I think should just close

No, there is not a clear benefit.

---

Closing, thank you all for the notes :)