pandas-dev / pandas-stubs

Public type stubs for pandas
BSD 3-Clause "New" or "Revised" License
234 stars 124 forks source link

Version 2.0 Compatibility Tracker #624

Open Dr-Irv opened 1 year ago

Dr-Irv commented 1 year ago

This is the list of things that are in pandas 2.0 release notes that need to be addressed in pandas-stubs. PR's welcome. If you do a PR, check off the item and put a link to the PR that closed it. One PR can address multiple issues.

Some of these may already have been taken care of, so if so, check them off and indicate with a comment such as "previously complete"

gandhis1 commented 1 year ago

Is the cut-off for removal of support for 1.5 effectively immediately? For instance, there are bugs constantly being fixed in the annotations, and so I currently stay up-to-date on the version. However I don't know if I'll be able to easily upgrade to 2.0 without breaking anything, and so I'd probably defer that upgrade. It seems 2.0 brings a fair amount of backwards-incompatible changes.

Dr-Irv commented 1 year ago

Is the cut-off for removal of support for 1.5 effectively immediately? For instance, there are bugs constantly being fixed in the annotations, and so I currently stay up-to-date on the version. However I don't know if I'll be able to easily upgrade to 2.0 without breaking anything, and so I'd probably defer that upgrade. It seems 2.0 brings a fair amount of backwards-incompatible changes.

Yes. The idea is that we want to encourage people to use the 2.0 API. I think that the 2.0 stubs (when released) will still work with 1.5 code, and, if not, they are telling you places in your code that you should change in order to be compatible with 2.0 in the future.

As an example, anything that was deprecated in 1.5 was already removed from the stubs.

ramvikrams commented 1 year ago

@Dr-Irv I think i have added the dtype_backend in series.convert_dtypes whch is covered in #655

Dr-Irv commented 1 year ago

@Dr-Irv I think i have added the dtype_backend in series.convert_dtypes is covered in #655

Thanks. I updated the list.

ramvikrams commented 1 year ago

@Dr-Irv i think you can mark this Added name parameter to IntervalIndex.from_breaks(), IntervalIndex.from_arrays(), IntervalIndex.from_tuples() as completed as the name parameter is already added in these.

Dr-Irv commented 1 year ago

@Dr-Irv i think you can mark this Added name parameter to IntervalIndex.from_breaks(), IntervalIndex.from_arrays(), IntervalIndex.from_tuples() as completed as the name parameter is already added in these.

Thanks. I've done that update

caneff commented 1 year ago

What is actually needed to be done to disallow non-keyword arguments? Most of the stubs already have the * in the overloads, is it just a matter of bring in the function def too for those overloaded ones? Lets just use drop as an example.

If so I can take those over.

Dr-Irv commented 1 year ago

What is actually needed to be done to disallow non-keyword arguments? Most of the stubs already have the * in the overloads, is it just a matter of bring in the function def too for those overloaded ones? Lets just use drop as an example.

If so I can take those over.

It's a mix of using * and /. See https://peps.python.org/pep-0570/#syntax-and-semantics

PR's are welcome. Maybe do one function so we can agree on the approach, then you can expand it to others.