5 ms·

it feels like the first major release in 18 years which introduces lots of breaking changes should just be a fork rather than a version. let me do `pip install

it feels like the first major release in 18 years which introduces lots of breaking changes should just be a fork rather than a version. let me do `pip install numpy2` and not have to worry about whether or not some other library in my project requires numpy<2.

make3 2y ago
knowing how careful the NumPy devs are, this was likely a very well pondered decision & all of these deprecations likely have been announced for a long time. Seeing knee jerk reactions like this is annoying.
- deleted 2y ago
  [deleted]
- kaashif 2y ago
  Do you have a link to the discussion where this was very well pondered? I can't find anything, but I'm very interested in that kind of discussion.
  - ngoldbaum 2y ago
    We had a developer meeting to discuss what should go into 2.0 in April 2023: https://github.com/numpy/archive/tree/main/2.0_developer_meeting https://github.com/numpy/archive/tree/main/2.0_developer_mee...
vessenes 2y ago
From a consumer (developer consumer) point of view, I hear you. From a project point of view, there are some pretty strong contra-indicators in the last 20 years of language development that make this plan suspect, or at least pretty scary — both Perl and Python had extremely rocky transitions around major versions; Perl’s ultimately failing and Python’s ultimately taking like 10 years. At least. I think the last time I needed Python 2 for something was a few months ago, and before that it had been a year or so. I’ve never needed Perl 6, but if I did I would be forced to read a lot of history while I downloaded and figured out which, if any, Perl 5 modules I’m looking for got ported. I’d imagine the numpy devs probably don’t have the resources to support what would certainly become two competing forks that each have communities with their own needs.
- sestep 2y ago
  Could you elaborate further on this? Is it not the case that they'll still need to support numpy 1.x for at least the near-term future? My understanding was the parent comment was specifically talking about the technical difficulty of multiple versions for the same Python package, not the social problem of project and community management across breaking changes.
  - rovr138 2y ago
    For the near term future, they can use the latest 1 version
  - vessenes 2y ago
    Yes, agreed they’ll need to support 1.x for (probably) quite a while, depending on API and interface changes between major versions. My point, or at least the point I had in mind, was that the social and technical go together in a lot of subtle and sometimes surprising ways; in this case, I’d bet the idea of a second package name a) is a bad one because it’s likely to create differing community expectations about whether or not it’s okay to keep using the 1.0 package, and b) would let people feel okay not upgrading for a while / demanding security and bug fix point releases on 1.x longer than if the package itself just updates its major version.
- librasteve 2y ago
  i think it’s fair to say that perl6 has been an “extremely rocky transition” ultimately it was renamed raku to reflect this and avoid camping on the perl5 version numbering raku has good package compatibility via Inline::Perl5 and Inline::Python and FFI to languages like Rust and Zig among the many downsides of the transition, one upside is that raku is a clean sheet of paper and has some interesting new work for example in LLM support I have started work on a new raku module called Dan::Polars and would welcome contributions from Numpy/Pandas folks with a vision of how to improve the APIs and abstractions … it’s a good place to make a real contribution, help make something new and better and get to grips with some raku and some rust. just connect via https://github.com/librasteve/raku-Dan-Polars https://github.com/librasteve/raku-Dan-Polars if you are interested and would like to know more
patrick451 2y ago
A project with both numpy arrays and numpy2 arrays getting mixed together sounds like a disaster to me.
aphexairlines 2y ago
If your requirements.in referenced numpy before this release, then doesn't your requirements.txt already reference a specific 1.x version?
theamk 2y ago
That was my first reaction as well, but apparently as far a Python goes, numpy 2 code is fully compatible with numpy 1 code [0], with exception of single "byte_bounds" function (which sounds super rare, so I doubt it'd be a problem) So at least the migration path for python modules is clear: upgrade to be numpy 2 compatible, wait for critical mass, start adding numpy 2 features. Sounds way better than python2 -> python3 migration, for example. However, the fact that I had to look at 3rd party page to find this out is IMHO a big documentation problem. It should be plastered in all announcements, on documentation and migration page: "there is a common subset for python code of numpy 1 and 2, so you can upgrade now, no need to wait for full adoption" [0] https://docs.astral.sh/ruff/rules/numpy2-deprecation/ https://docs.astral.sh/ruff/rules/numpy2-deprecation/

make3 2y ago

knowing how careful the NumPy devs are, this was likely a very well pondered decision & all of these deprecations likely have been announced for a long time. Seeing knee jerk reactions like this is annoying.

deleted 2y ago
[deleted]
kaashif 2y ago
Do you have a link to the discussion where this was very well pondered? I can't find anything, but I'm very interested in that kind of discussion.
- ngoldbaum 2y ago
  We had a developer meeting to discuss what should go into 2.0 in April 2023: https://github.com/numpy/archive/tree/main/2.0_developer_meeting https://github.com/numpy/archive/tree/main/2.0_developer_mee...

vessenes 2y ago

From a consumer (developer consumer) point of view, I hear you. From a project point of view, there are some pretty strong contra-indicators in the last 20 years of language development that make this plan suspect, or at least pretty scary — both Perl and Python had extremely rocky transitions around major versions; Perl’s ultimately failing and Python’s ultimately taking like 10 years. At least. I think the last time I needed Python 2 for something was a few months ago, and before that it had been a year or so. I’ve never needed Perl 6, but if I did I would be forced to read a lot of history while I downloaded and figured out which, if any, Perl 5 modules I’m looking for got ported. I’d imagine the numpy devs probably don’t have the resources to support what would certainly become two competing forks that each have communities with their own needs.

sestep 2y ago
Could you elaborate further on this? Is it not the case that they'll still need to support numpy 1.x for at least the near-term future? My understanding was the parent comment was specifically talking about the technical difficulty of multiple versions for the same Python package, not the social problem of project and community management across breaking changes.
- rovr138 2y ago
  For the near term future, they can use the latest 1 version
- vessenes 2y ago
  Yes, agreed they’ll need to support 1.x for (probably) quite a while, depending on API and interface changes between major versions. My point, or at least the point I had in mind, was that the social and technical go together in a lot of subtle and sometimes surprising ways; in this case, I’d bet the idea of a second package name a) is a bad one because it’s likely to create differing community expectations about whether or not it’s okay to keep using the 1.0 package, and b) would let people feel okay not upgrading for a while / demanding security and bug fix point releases on 1.x longer than if the package itself just updates its major version.
librasteve 2y ago
i think it’s fair to say that perl6 has been an “extremely rocky transition” ultimately it was renamed raku to reflect this and avoid camping on the perl5 version numbering raku has good package compatibility via Inline::Perl5 and Inline::Python and FFI to languages like Rust and Zig among the many downsides of the transition, one upside is that raku is a clean sheet of paper and has some interesting new work for example in LLM support I have started work on a new raku module called Dan::Polars and would welcome contributions from Numpy/Pandas folks with a vision of how to improve the APIs and abstractions … it’s a good place to make a real contribution, help make something new and better and get to grips with some raku and some rust. just connect via https://github.com/librasteve/raku-Dan-Polars https://github.com/librasteve/raku-Dan-Polars if you are interested and would like to know more

patrick451 2y ago

A project with both numpy arrays and numpy2 arrays getting mixed together sounds like a disaster to me.

aphexairlines 2y ago

If your requirements.in referenced numpy before this release, then doesn't your requirements.txt already reference a specific 1.x version?

theamk 2y ago

That was my first reaction as well, but apparently as far a Python goes, numpy 2 code is fully compatible with numpy 1 code [0], with exception of single "byte_bounds" function (which sounds super rare, so I doubt it'd be a problem) So at least the migration path for python modules is clear: upgrade to be numpy 2 compatible, wait for critical mass, start adding numpy 2 features. Sounds way better than python2 -> python3 migration, for example. However, the fact that I had to look at 3rd party page to find this out is IMHO a big documentation problem. It should be plastered in all announcements, on documentation and migration page: "there is a common subset for python code of numpy 1 and 2, so you can upgrade now, no need to wait for full adoption" [0] https://docs.astral.sh/ruff/rules/numpy2-deprecation/ https://docs.astral.sh/ruff/rules/numpy2-deprecation/