BUG: Add np.uintc to _factorizers in merge.py to fix KeyError when merging DataFrames with uintc columns
State: closed

- [x] closes #58713 (Replace xxxx with the GitHub issue number)
- [x] [Tests added and passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#writing-tests) if fixing a bug or adding a new feature
- [x] All [code checks passed](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#pre-commit).
- [x] Added [type annotations](https://pandas.pydata.org/pandas-docs/dev/development/contributing_codebase.html#type-hints) to new arguments/methods/functions.
- [x] Added an entry in the latest `doc/source/whatsnew/vX.X.X.rst` file if fixing a bug or adding a new feature.


Labels:
name: Reshaping
description: Concat, Merge/Join, Stack/Unstack, Explode
name: Windows
description: Windows OS

Comments:
hiii @myles the PR is ready to merge
thanks @Tirthchoksi22 

the same issue was fixed for `np.intc` in #53175.

This is only for Windows and is it a regression from a previous release?

if so could probably use the previous fix/tests/release note for this PR?
Yes, it appears that there is indeed a regression on Windows machines. The issue seems to have resurfaced after being resolved in a previous release.

> thanks @Tirthchoksi22
> 
> the same issue was fixed for `np.intc` in #53175.
> 
> This is only for Windows and is it a regression from a previous release?
> 
> if so could probably use the previous fix/tests/release note for this PR?


@simonjayhawkins After reviewing the code and considering the previous fix, it appears that the solution implemented in this pull request is indeed identical to the one used in the previous resolution of the regression.

> thanks @Tirthchoksi22
> 
> the same issue was fixed for `np.intc` in #53175.
> 
> This is only for Windows and is it a regression from a previous release?
> 
> if so could probably use the previous fix/tests/release note for this PR?


@simonjayhawkins Also guide me what to do next do i have to create new PR with previous fix/tests/release or this is ok ??as this would be my first Open Source Contribution 
you can make changes to you branch and push those changes to update this PR. No need to close and open a new PR.

All bug fixes and regression fixes need a test to ensure that the issue does not resurface here. In this case, looking at the fix for `np.intc` the parameterization of `test_join_multi_dtypes` was updated. Perhaps could do the same here?

For the release note, if you (I can't check a windows only bug easily) determine for which pandas release it was a regression, or if that is many releases ago, then we maybe need a note either under the bug fixes or regression section of the release notes. If a bug fix would go in the 3.0 what's new. If a regression, would go in the 2.2.x release notes (but that depends if we are doing another patch release)

cc @lithomas1 
@simonjayhawkins  Thank you for your feedback. Upon further review, I realized that the changes made to the merge.py file were minimal and consisted of adding just one extra line (`np.uintc: libhashtable.UInt32Factorizer`) to the `_factorizers` dictionary. The majority of the changes were indeed in the test file, where I added tests to ensure proper handling of numpy.uintc columns.

Additionally, I'd like to confirm that the release note has already been included in the bug fixes and regression section, documenting the resolution of the issue.

Given this information, I believe that the changes made align with the expectations outlined in your feedback. Please let me know if there are any further adjustments or considerations needed.

Thank you for your continued guidance and support throughout this process.
ci is failing, 

/pre-commit
> ci is failing,
> 
> /pre-commit


so what to do now ??

I thought that comment should have triggered the bot. 
/pre-commit
@github-actions pre-commit
> /pre-commit

I dont think there's a command like this 
pre-commit.ci autofix
@simonjayhawkins Could you kindly confirm if the changes proposed in this pull request are satisfactory, or if there are any additional adjustments needed before merging?
pre-commit.ci autofix
I was browsing recent pull requests and have a Windows machine so thought I would give this a quick test for you. It looks like the difference is that on Windows np.uintc is not aliased to any of the types already in the _factorizers dictionary:

```python
Python 3.12.3 (tags/v3.12.3:f6650f9, Apr  9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.uintc is np.int64
False
>>> np.uintc is np.longlong
False
>>> np.uintc is np.int32
False
>>> np.uintc is np.int16
False
>>> np.uintc is np.int8
False
>>> np.uintc is np.uint64
False
>>> np.uintc is np.uint32
False
>>> np.uintc is np.uint16
False
>>> np.uintc is np.uint8
False
>>> np.uintc is np.bool_
False
>>> np.uintc is np.float64
False
>>> np.uintc is np.float32
False
>>> np.uintc is np.complex64
False
>>> np.uintc is np.complex128
False
>>> np.uintc is np.object_
False
```

Whereas at least in Linux it is aliased to the np.uint32 type:
```python
Python 3.12.3 (main, Apr 10 2024, 05:33:47) [GCC 13.2.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import numpy as np
>>> np.uintc is np.int64
False
>>> np.uintc is np.longlong
False
>>> np.uintc is np.int32
False
>>> np.uintc is np.int16
False
>>> np.uintc is np.int8
False
>>> np.uintc is np.uint64
False
>>> np.uintc is np.uint32
True
>>> np.uintc is np.uint16
False
>>> np.uintc is np.uint8
False
>>> np.uintc is np.bool_
False
>>> np.uintc is np.float64
False
>>> np.uintc is np.float32
False
>>> np.uintc is np.complex64
False
>>> np.uintc is np.complex128
False
>>> np.uintc is np.object_
False
```

This is probably related to Windows using the LLP64 64-bit data model vs LP64 used elsewhere (https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models). https://stackoverflow.com/questions/76155091/np-uint32-np-uintc-on-windows gives a possible explanation.
> I was browsing recent pull requests and have a Windows machine so thought I would give this a quick test for you. It looks like the difference is that on Windows np.uintc is not aliased to any of the types already in the _factorizers dictionary:
> 
> ```python
> Python 3.12.3 (tags/v3.12.3:f6650f9, Apr  9 2024, 14:05:25) [MSC v.1938 64 bit (AMD64)] on win32
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy as np
> >>> np.uintc is np.int64
> False
> >>> np.uintc is np.longlong
> False
> >>> np.uintc is np.int32
> False
> >>> np.uintc is np.int16
> False
> >>> np.uintc is np.int8
> False
> >>> np.uintc is np.uint64
> False
> >>> np.uintc is np.uint32
> False
> >>> np.uintc is np.uint16
> False
> >>> np.uintc is np.uint8
> False
> >>> np.uintc is np.bool_
> False
> >>> np.uintc is np.float64
> False
> >>> np.uintc is np.float32
> False
> >>> np.uintc is np.complex64
> False
> >>> np.uintc is np.complex128
> False
> >>> np.uintc is np.object_
> False
> ```
> 
> Whereas at least in Linux it is aliased to the np.uint32 type:
> 
> ```python
> Python 3.12.3 (main, Apr 10 2024, 05:33:47) [GCC 13.2.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> import numpy as np
> >>> np.uintc is np.int64
> False
> >>> np.uintc is np.longlong
> False
> >>> np.uintc is np.int32
> False
> >>> np.uintc is np.int16
> False
> >>> np.uintc is np.int8
> False
> >>> np.uintc is np.uint64
> False
> >>> np.uintc is np.uint32
> True
> >>> np.uintc is np.uint16
> False
> >>> np.uintc is np.uint8
> False
> >>> np.uintc is np.bool_
> False
> >>> np.uintc is np.float64
> False
> >>> np.uintc is np.float32
> False
> >>> np.uintc is np.complex64
> False
> >>> np.uintc is np.complex128
> False
> >>> np.uintc is np.object_
> False
> ```
> 
> This is probably related to Windows using the LLP64 64-bit data model vs LP64 used elsewhere (https://en.wikipedia.org/wiki/64-bit_computing#64-bit_data_models). https://stackoverflow.com/questions/76155091/np-uint32-np-uintc-on-windows gives a possible explanation.

thanks for the explanation mate it helps a lot 
pre-commit.ci autofix

@simonjayhawkins your requested changes are done and this PR is ready to merge now 
pre-commit.ci autofix

pre-commit.ci autofix

@Tirthchoksi22 on a procedural note, the `pre-commit.ci autofix` is useful for maintainers to correct the code. As the PR author, you can install pre-commit in your local dev environment to check the code changes you make before pushing them to the PR.  
> @Tirthchoksi22 on a procedural note, the `pre-commit.ci autofix` is useful for maintainers to correct the code. As the PR author, you can install pre-commit in your local dev environment to check the code changes you make before pushing them to the PR.

ok sorry I didn't know about that 
Can you please use that comment now because i didnt have install pre-commit in my local environment right now 
> Can you please use that comment now because i didnt have install pre-commit in my local environment right now

feel free to issue that command yourself. I was not suggesting that you could not use it. (However, if you look at the pandas documentation, you will see a section for setting up a development environment)
pre-commit.ci autofix
pre-commit.ci autofix
@simonjayhawkins @WillAyd @mroeschke Guys any update ???
@simonjayhawkins ??