Skip to content

Bump Python version to 3.13#955

Open
gonzaponte wants to merge 43 commits intonext-exp:masterfrom
gonzaponte:python3.13
Open

Bump Python version to 3.13#955
gonzaponte wants to merge 43 commits intonext-exp:masterfrom
gonzaponte:python3.13

Conversation

@gonzaponte
Copy link
Copy Markdown
Collaborator

Several changes, particularly in pandas, mean that we need to do things slightly differently.

Copy link
Copy Markdown
Member

@jwaiton jwaiton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First read over, its good work and very well commented. I just have a few questions.

Comment thread manage.sh
Comment thread pyproject.toml Outdated
Comment thread pyproject.toml Outdated
Comment thread manage.sh
Comment thread invisible_cities/database/load_db_test.py
Comment thread setup.py
Comment thread setup.py
Comment thread invisible_cities/reco/pmaps_functions_test.py
Comment thread invisible_cities/detsim/sensor_utils.py Outdated
Comment thread invisible_cities/reco/hits_functions.py
I couldn't figure out why we need absolute imports here
Running setup.py directly is deprecated:

        ********************************************************************************
        Please avoid running ``setup.py`` and ``easy_install``.
        Instead, use pypa/build, pypa/installer or other
        standards-based tools.

        See pypa/setuptools#917 for details.
        ********************************************************************************
I guess hypothesis' heuristics, tend to generate values around 0,
which makes it filter a lot of data
The new pandas version issues a warning because `fillna` attempts to
work on columns of type `str` (a.k.a `object`) which doesn't work. The
fix consists in filling `nan`s only in the columsn that might have them.
Hypothesis found the case where x_min==x_max, which we want to test
separately.
The data in the input file contains hits that do not correspond to
sensor positions. This is not expected in our code. The refactored
version of this function assumes that each hit correspond to a SiPM.
This is a mistery. What's changed in pandas(?) hdf5(?) for the data to be
in a different order? I have no clue.
The former is deprecated.
We do not avoid inplace overall, but rather column operations with the
inplace argument which is no longer allowed. In the new pandas version,
the interface forces you to do one of:

- do the operation on the dataframe, using the arguments to restrict the
  operation to a subset of columns (first hunk of the diff)

- do the operation on the column, without inplace, and reassign it to
  the same column (second hunk of the diff)
This has to do with a change in the groupby-apply behaviour of pandas.
In the older version, the groups passed to `apply` contained the
grouping columns. The new behaviour promotes removing the grouping
columns from the groups. For now it still allows both uses via the
`include_groups` argument, but it will become the default (or even
fixed) behaviour in the future.

Before the function used in `apply` (let's say `drop`) was returning a
dataframe that contained the grouping columns. `apply` would then
combine the resulting dataframes using the grouping columns as index.
Finally, we were resetting and dropping the _entire index_ because the
grouping columns were already in the dataframe.

Now, the grouping columns are not passed to `drop`, so the dataframe it
returns does not contain them. When `apply` combines these dataframes
using the grouping columns, we must preserve the index in order not to
lose this information. However, the dataframe produced in `drop`
contains another (meaningless) index. This is just because dataframes
must have an index. What we do in this case is to just drop the
meaningless index and restore the grouping columns which have been set
as the index.
not sure why this is needed, I forgot.
A extreme case was failing the test. We are not interested in that and
there was not much we could do, since it's a numpy function that's
acting weird.
iloc operations now return wrapped types
This reverts commit b224dfd893cacc38a40088936ed4637319185a51.

This doesn't seem to have an effect anywhere, so there is no reason for
the explicit conversion
pandas no longer allows indexing using sets
Copy link
Copy Markdown
Member

@jwaiton jwaiton left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This PR bumps the python version from 3.8 to 3.13, requiring some alterations to the code to ensure IC functions as intended.

Very nice work!

@gonzaponte
Copy link
Copy Markdown
Collaborator Author

gonzaponte commented Mar 17, 2026

Closes #920.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants