CLN: Replaced "bool_t" with "builtins.bool"
- [ ] closes #xxxx
- [ ] tests added / passed
- [ ] passes `black pandas`
- [ ] passes `git diff upstream/master -u -- "*.py" | flake8 --diff`
- [ ] whatsnew entry

@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? looking at the solution in https://github.com/ahawker/ulid/pull/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  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 > 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" I agree with Will.  The bool_t definition also has a comment telling us why it is there, which the builtins.bool doesnt 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 https://github.com/ahawker/ulid/pull/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) Do we support ```float16```? > Do we support `float16`?

#32449 should fix that. 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
 > 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 :)