[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Sebastian Berg]

On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote:
> On 05/05/2024 11:32, Mark Harfouche wrote:
> 

> > 
> > Thank you for considering this last minute request. I know it adds 
> > work at this stage.
> > 
> > Mark
> 
> 
> I think NumPy should not be the leader in dropping versions, rather 
> should be one of the more conservative packages since other packages 
> depend on it. We have indeed dropped 3.9 on HEAD, and will not be 
> supporting it for 2.1, but to me it makes sense to support it for the
> large 2.0 release.


I think it is late anyway and NumPy always had a slightly longer
support period and that seemed fine especially since NumPy is low in
the stack.

The SPEC was written to give the community that precedence and show
that many agree with you (and numpy endorses it).
Maybe the "endorsed by" list should rather be grown to strengthen the
argument instead?

(Of course there are true exceptions, IIRC scikit-learn chooses to have
much longer support windows.)

- Sebastian


> 
> 
> Matti
> 
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sebast...@sipsolutions.net
> 


___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Mark Harfouche]

On Mon, May 6, 2024 at 6:46 AM Sebastian Berg 
wrote:

> On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote:
> > On 05/05/2024 11:32, Mark Harfouche wrote:
> >
> > but to me it makes sense to support it for the
> > large 2.0 release.
>
> The release will not be without problems rippling throughout the
community. SPEC0 effectively asks downstream packages to:
"Focus on Python 3.10 in 2024". But the introduction of "numpy 2.0" without
updated downstream packages will surely break some.
If these breakages occur, packages will have to think about whether or not
to backport a release for those stuck on Python 3.9.
This is something that was identified as a potential risk
https://github.com/numpy/numpy/issues/26191 and you have all been very
proactive in helping resolve the issues.
I'm asking that you let Python 3.9 support disappear with 1.26, and not
"drop a final version" before you decide to move on with 3.10+ only.

On the list above is, Scikit-image, which I am a core developer of, and you
have all identified as being compatible with Numpy 2.0 starting 0.23.1 does
not have a CPython 3.9 build for 0.23.1 on pypi.
https://pypi.org/project/scikit-image/0.23.1/#files
It also lists as being compatible with numpy >=1.22 in its dependencies as
this was understood to be the best practice at the time
https://github.com/scikit-image/scikit-image/blob/v0.22.x/pyproject.toml#L29

Thus a project that uses Python 3.9 + pip + scikit-image will type

pip install scikit-image

and this can pull in numpy 2.0
I sadly haven't followed too closely with the full list of fixes for numpy
2.0 that were introduced in the 0.23.1 release, but I'm not looking forward
to explaining to users why "Python" broke "again" on python 3.9.

Scikit-image is an active project, with many eyes on it, and it seems many
fixes for Numpy2 were already in the 0.22.0 release, but smaller projects
will not have been so proactive.

I think it is late anyway and NumPy always had a slightly longer
> support period and that seemed fine especially since NumPy is low in
> the stack.
>
> The SPEC was written to give the community that precedence and show
> that many agree with you (and numpy endorses it).
> Maybe the "endorsed by" list should rather be grown to strengthen the
> argument instead?
>

I am asking that Numpy be included in the list of packages that adhere to
it making the whole SPEC stronger.
"Endorsed" but not adhered to is a much weaker argument than: "this is what
numpy follows", "if the policy is good enough for them is good enough for
us".
It's very difficult to convince others when they see numpy as not following
things, so they say "well its working now, lets just keep the CIs the same".
It only grows the support burden for the strained open source we have (our
time).
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: numpy on iOS

[Stanley Seibert]

The Beeware (https://beeware.org/) developers build NumPy (and other binary
extension packages) for mobile operating systems, both iOS and Android.
You can see their scripts and build recipes here:

https://github.com/beeware/mobile-forge

In particular, you can see the patch they need to make to the vendored copy
of Meson to support iOS here:

https://github.com/beeware/mobile-forge/blob/main/recipes/numpy/patches/mobile-1.26.0.patch

On Sat, May 4, 2024 at 7:51 AM Vitalii  wrote:

> Hi everyone,
>
> I wonder if anyone has successful experience in building numpy with native
> libs for iOS distribution. Please, share your knowledge.
>
> Thank you,
> Vitalii
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: sseib...@anaconda.com
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: numpy on iOS

[Stanley Seibert]

I should also note that Beeware has a number of patches for the Python
interpreter itself to get iOS support working.  Fortunately, as of the
upcoming Python 3.13 beta, those patches are all merged into CPython main
and iOS becomes a Tier 3 supported platform:

https://peps.python.org/pep-0730/

On Mon, May 6, 2024 at 9:10 AM Stanley Seibert 
wrote:

> The Beeware (https://beeware.org/) developers build NumPy (and other
> binary extension packages) for mobile operating systems, both iOS and
> Android.  You can see their scripts and build recipes here:
>
> https://github.com/beeware/mobile-forge
>
> In particular, you can see the patch they need to make to the vendored
> copy of Meson to support iOS here:
>
>
> https://github.com/beeware/mobile-forge/blob/main/recipes/numpy/patches/mobile-1.26.0.patch
>
> On Sat, May 4, 2024 at 7:51 AM Vitalii  wrote:
>
>> Hi everyone,
>>
>> I wonder if anyone has successful experience in building numpy with
>> native libs for iOS distribution. Please, share your knowledge.
>>
>> Thank you,
>> Vitalii
>> ___
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: sseib...@anaconda.com
>>
>
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: next Documentation team meeting

[Mukulika Pahari]

Hi all,

Our next Documentation Team meeting will happen on *Monday, May 6* at *11PM 
UTC*. If this time slot is inconvenient for you to join, please let me know in 
the replies or Slack and we will work something out.

All are welcome - you don't need to already be a contributor to join. If you 
have questions or are curious about what we're doing, we'll be happy to meet 
you!

If you wish to join on Zoom, use this (updated) link:
https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ...

Here's the permanent hackmd document with the meeting notes (still being
updated):
https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg

Hope to see you around!

Best wishes,
Mukulika
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: next Documentation team meeting

[Mukulika Pahari]

Patrick Zamba wrote:
> Hie, M. Pahari
> 
> Kindly, reschedule me for another slot, for the one you sent me I won't be
> able to attend.
> 
> Thank you
> 
> Patrick

Hi Patrick,
Thanks for letting me know. I will send around a poll for deciding on a new 
docs meeting time. Please indicate your preferences then.

> On Mon, 8 Apr 2024, 06:32 Mukulika Pahari,  wrote:
> > Hi all,
> > Our next Documentation Team meeting will happen on *Monday, April 8* at
> > *11PM UTC*. If this time slot is inconvenient for you to join, please let
> > me know in the replies or Slack and we will work something out.
> > All are welcome - you don't need to already be a contributor to join. If
> > you have questions or are curious about what we're doing, we'll be happy to
> > meet you!
> > If you wish to join on Zoom, use this (updated) link:
> > https://numfocus-org.zoom.us/j/85016474448?pwd=TWEvaWJ1SklyVEpwNXUrcHV1YmFJQ.
> > ..
> > Here's the permanent hackmd document with the meeting notes (still being
> > updated):
> > https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg
> > Hope to see you around!
> > Best wishes,
> > Mukulika
> > ___
> > NumPy-Discussion mailing list -- numpy-discussion@python.org
> > To unsubscribe send an email to numpy-discussion-le...@python.org
> > https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> > Member address: pzamb...@gmail.com
> >
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Aaron Meurer]

On Mon, May 6, 2024 at 6:34 AM Mark Harfouche  wrote:
>
>
> On Mon, May 6, 2024 at 6:46 AM Sebastian Berg  
> wrote:
>>
>> On Mon, 2024-05-06 at 09:17 +1000, Matti Picus wrote:
>> > On 05/05/2024 11:32, Mark Harfouche wrote:
>> >
>> > but to me it makes sense to support it for the
>> > large 2.0 release.
>>
> The release will not be without problems rippling throughout the community. 
> SPEC0 effectively asks downstream packages to:
> "Focus on Python 3.10 in 2024". But the introduction of "numpy 2.0" without 
> updated downstream packages will surely break some.
> If these breakages occur, packages will have to think about whether or not to 
> backport a release for those stuck on Python 3.9.
> This is something that was identified as a potential risk  
> https://github.com/numpy/numpy/issues/26191 and you have all been very 
> proactive in helping resolve the issues.
> I'm asking that you let Python 3.9 support disappear with 1.26, and not "drop 
> a final version" before you decide to move on with 3.10+ only.

I don't understand NumPy supporting Python 3.9 means you have to also.
A downstream dependent only has to support at most the versions you
do. If NumPy dropped Python 3.9 but you wanted to keep it that would
be a problem, but the reverse isn't because scikit-image depends on
NumPy, not the other way around.

>
> On the list above is, Scikit-image, which I am a core developer of, and you 
> have all identified as being compatible with Numpy 2.0 starting 0.23.1 does 
> not have a CPython 3.9 build for 0.23.1 on pypi.
> https://pypi.org/project/scikit-image/0.23.1/#files
> It also lists as being compatible with numpy >=1.22 in its dependencies as 
> this was understood to be the best practice at the time
> https://github.com/scikit-image/scikit-image/blob/v0.22.x/pyproject.toml#L29
>
> Thus a project that uses Python 3.9 + pip + scikit-image will type
>
> pip install scikit-image
>
> and this can pull in numpy 2.0
> I sadly haven't followed too closely with the full list of fixes for numpy 
> 2.0 that were introduced in the 0.23.1 release, but I'm not looking forward 
> to explaining to users why "Python" broke "again" on python 3.9.

I rather expect the packaging issues that will arise when NumPy 2.0 is
released will be more general than this. The central issue being that
no one pinned NumPy < 2 until recently (and I'm sure many aren't even
doing it at all yet), and on PyPI, there's no way to update pinning
metadata except by doing a new patch release. Maybe someone could do
an analysis of the metadata on PyPI to see whether this specific issue
is likely to occur broadly or is just specific to scikit-image.

Aaron Meurer

>
> Scikit-image is an active project, with many eyes on it, and it seems many 
> fixes for Numpy2 were already in the 0.22.0 release, but smaller projects 
> will not have been so proactive.
>
>> I think it is late anyway and NumPy always had a slightly longer
>> support period and that seemed fine especially since NumPy is low in
>> the stack.
>>
>> The SPEC was written to give the community that precedence and show
>> that many agree with you (and numpy endorses it).
>> Maybe the "endorsed by" list should rather be grown to strengthen the
>> argument instead?
>
>
> I am asking that Numpy be included in the list of packages that adhere to it 
> making the whole SPEC stronger.
> "Endorsed" but not adhered to is a much weaker argument than: "this is what 
> numpy follows", "if the policy is good enough for them is good enough for us".
> It's very difficult to convince others when they see numpy as not following 
> things, so they say "well its working now, lets just keep the CIs the same".
> It only grows the support burden for the strained open source we have (our 
> time).
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: asmeu...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Oscar Benjamin]

On Mon, 6 May 2024 at 19:59, Aaron Meurer  wrote:
>
> On Mon, May 6, 2024 at 6:34 AM Mark Harfouche  
> wrote:
> >
> > I'm asking that you let Python 3.9 support disappear with 1.26, and not 
> > "drop a final version" before you decide to move on with 3.10+ only.
>
> I don't understand NumPy supporting Python 3.9 means you have to also.
> A downstream dependent only has to support at most the versions you
> do. If NumPy dropped Python 3.9 but you wanted to keep it that would
> be a problem, but the reverse isn't because scikit-image depends on
> NumPy, not the other way around.

A downstream package needs to provide updates for all the same Python
versions as its dependencies because otherwise e.g. a NumPy 2.0
release for CPython 3.9 breaks dependent packages that no longer
support 3.9. Those projects then need to add back support for older
Python versions at the same time as putting out an urgent
compatibility release. Perhaps usually this is not such an issue but
particularly for an intentionally compatibility breaking release
sending it out to more than the usual range of Python versions is not
helpful for downstream.

--
Oscar
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Ralf Gommers]

On Mon, May 6, 2024 at 10:42 PM Oscar Benjamin 
wrote:

> On Mon, 6 May 2024 at 19:59, Aaron Meurer  wrote:
> >
> > On Mon, May 6, 2024 at 6:34 AM Mark Harfouche 
> wrote:
> > >
> > > I'm asking that you let Python 3.9 support disappear with 1.26, and
> not "drop a final version" before you decide to move on with 3.10+ only.
> >
> > I don't understand NumPy supporting Python 3.9 means you have to also.
> > A downstream dependent only has to support at most the versions you
> > do. If NumPy dropped Python 3.9 but you wanted to keep it that would
> > be a problem, but the reverse isn't because scikit-image depends on
> > NumPy, not the other way around.
>
> A downstream package needs to provide updates for all the same Python
> versions as its dependencies because otherwise e.g. a NumPy 2.0
> release for CPython 3.9 breaks dependent packages that no longer
> support 3.9. Those projects then need to add back support for older
> Python versions at the same time as putting out an urgent
> compatibility release. Perhaps usually this is not such an issue but
> particularly for an intentionally compatibility breaking release
> sending it out to more than the usual range of Python versions is not
> helpful for downstream.
>

I think this is an important argument indeed. The initial "follow SPEC 0"
is not really relevant, but let's focus on the practical issue at hand.
When a user types `pip install numpy scikit-image` in a Python 3.9
environment, where numpy 2.0 would support 3.9 and scikit-image 0.23 does
not, then the end result will be that numpy 2.0 and scikit-image 0.22
(incompatible!) will be installed. This is undesirable.

This problem could have been avoided by proper use of upper bounds.
Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in
scikit-image (definitely for ABI reasons, and arguably also for API
reasons). It would really be useful if downstream packages started to take
adding upper bounds correctly more seriously. E.g., SciPy has always done
it right, so the failure mode that this thread is about doesn't exist for
SciPy. That said, this ship has sailed for 2.0 - most packages don't have
upper bounds in some or all of their recent releases.

So, I think I'm in favor of dropping Python 3.9 support after all to
prevent problems. It is late in the game, but I do see that we're going to
cause problems for packages that have already dropped 3.9, and I don't yet
see an issue with dropping 3.9 for numpy 2.0 now. Does anyone see a
potential failure mode if we go that way?

Cheers,
Ralf
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Aaron Meurer]

On Mon, May 6, 2024 at 3:05 PM Ralf Gommers  wrote:
>
>
>
> On Mon, May 6, 2024 at 10:42 PM Oscar Benjamin  
> wrote:
>>
>> On Mon, 6 May 2024 at 19:59, Aaron Meurer  wrote:
>> >
>> > On Mon, May 6, 2024 at 6:34 AM Mark Harfouche  
>> > wrote:
>> > >
>> > > I'm asking that you let Python 3.9 support disappear with 1.26, and not 
>> > > "drop a final version" before you decide to move on with 3.10+ only.
>> >
>> > I don't understand NumPy supporting Python 3.9 means you have to also.
>> > A downstream dependent only has to support at most the versions you
>> > do. If NumPy dropped Python 3.9 but you wanted to keep it that would
>> > be a problem, but the reverse isn't because scikit-image depends on
>> > NumPy, not the other way around.
>>
>> A downstream package needs to provide updates for all the same Python
>> versions as its dependencies because otherwise e.g. a NumPy 2.0
>> release for CPython 3.9 breaks dependent packages that no longer
>> support 3.9. Those projects then need to add back support for older
>> Python versions at the same time as putting out an urgent
>> compatibility release. Perhaps usually this is not such an issue but
>> particularly for an intentionally compatibility breaking release
>> sending it out to more than the usual range of Python versions is not
>> helpful for downstream.
>
>
> I think this is an important argument indeed. The initial "follow SPEC 0" is 
> not really relevant, but let's focus on the practical issue at hand. When a 
> user types `pip install numpy scikit-image` in a Python 3.9 environment, 
> where numpy 2.0 would support 3.9 and scikit-image 0.23 does not, then the 
> end result will be that numpy 2.0 and scikit-image 0.22 (incompatible!) will 
> be installed. This is undesirable.
>
> This problem could have been avoided by proper use of upper bounds. 
> Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in 
> scikit-image (definitely for ABI reasons, and arguably also for API reasons). 
> It would really be useful if downstream packages started to take adding upper 
> bounds correctly more seriously. E.g., SciPy has always done it right, so the 
> failure mode that this thread is about doesn't exist for SciPy. That said, 
> this ship has sailed for 2.0 - most packages don't have upper bounds in some 
> or all of their recent releases.
>
> So, I think I'm in favor of dropping Python 3.9 support after all to prevent 
> problems. It is late in the game, but I do see that we're going to cause 
> problems for packages that have already dropped 3.9, and I don't yet see an 
> issue with dropping 3.9 for numpy 2.0 now. Does anyone see a potential 
> failure mode if we go that way?

Presumably dropping 3.9 support at this point would not mean removing
anything that would actually break NumPy in Python 3.9. It would just
mean adding the python_requires metadata and not building a 3.9 wheel.
So if someone really needs a 3.9-compatible NumPy 2.0 they could build
a wheel manually.

I'm assuming the python_requires metadata is required though since
otherwise pip would try to build a wheel from source.

Aaron Meurer

>
> Cheers,
> Ralf
>
> ___
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: asmeu...@gmail.com
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] PR - can I get a new review?

[Jake S.]

Hi community,

PR 26081  is about making
numpy's ShapeType covariant and bound to a tuple of ints.  The community
has requested this occasionally in issue 16544
.  I'm reaching out via the
listserv because it's been a few months, and I don't want it to get too
stale.  I could really use some help pushing it over the finish line.

Summary:
Two numpy reviewers and one interested community member reviewed the PR and
asked for a type alias akin to npt.NDArray that allowed shape.  I worked
through the issues with TypeVarTuple and made npt.Array, and it was
fragile, but passing CI.  After a few months passed, I returned to fix the
fragility in the hopes of getting some more attention, but now it fails CI
in some odd builds (passes the mypy bit).  I have no idea how to get these
to pass, as they appear unrelated to anything I've worked on (OpenBLAS on
windows, freeBSD...?).

Thanks,
Jake
___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

[Numpy-discussion] Re: Please consider dropping Python 3.9 support for Numpy 2.0

[Juan Nunez-Iglesias]

On Tue, 7 May 2024, at 7:04 AM, Ralf Gommers wrote:
> This problem could have been avoided by proper use of upper bounds. 
> Scikit-image 0.22 not including a `numpy<2.0` upper bound is a bug in 
> scikit-image (definitely for ABI reasons, and arguably also for API reasons). 
> It would really be useful if downstream packages started to take adding upper 
> bounds correctly more seriously. E.g., SciPy has always done it right, so the 
> failure mode that this thread is about doesn't exist for SciPy. That said, 
> this ship has sailed for 2.0 - most packages don't have upper bounds in some 
> or all of their recent releases.

I don't think this is a downstream problem, I think this is a "PyPI has 
immutable metadata" problem. I'm a big fan of Henry Schreiner's "Should You Use 
Upper Bound Version Constraints" 
, where he argues 
convincingly that the answer is almost always no. This highlighted bit contains 
the gist:

> A library that requires a manual version intervention is not broken, it’s 
> just irritating. A library that can’t be installed due to a version conflict 
> is broken. If that version conflict is fake, then you’ve created an 
> unsolvable problem where one didn’t exist.

Dropping Py 3.9 will fix the issue for a subset of users, but certainly not all 
users. Someone who pip installs scikit-image==0.22 on Py 3.10 will have a 
broken install. But importantly, they will be able to fix it in user space.

At any rate, it's not like NumPy (or SciPy, or scikit-image) don't change APIs 
over several minor versions. Quoting Henry again:

> Quite ironically, the better a package follows SemVer, the smaller the change 
> will trigger a major version, and therefore the less likely a major version 
> will break a particular downstream code.

In short, and independent of the Py3.9 issue, I don't think we should advocate 
for upper caps in general, because in general it is impossible to know whether 
an update is going to break your library, regardless of their SemVer practices, 
and a fake upper pin is worse than no upper pin.

Juan.___
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com