Re: [Numpy-discussion] Bump warning stacklevel
On Mi, 2016-01-27 at 17:12 -0500, Benjamin Root wrote: > I like the idea of bumping the stacklevel in principle, but I am not > sure it is all that practical. For example, if a warning came up when > doing "x / y", I am assuming that it is emitted from within the ufunc > np.divide(). So, you would need two stacklevels based on whether the > entry point was the operator or a direct call to np.divide()? Also, I > would imagine it might get weird for numpy functions called within > other numpy functions. Or perhaps I am not totally understanding how > this would be done? You are right of course, and the answer is that I was never planning on fixing that. This is only for warnings by functions directly called by the users (or those which always go through one more level, though I did not check the C-api for such funcs). Also C-Api warnings are already correct in this regard automatically. Anyway, I still think it is worth it, even if in practice a lot of warnings are such things as ufunc warnings from inside a python func. And there is no real way to change that, that I am aware of, unless maybe we add a warning_stacklevel argument to those C-api funcs ;). - Sebastian > Ben Root > > > On Wed, Jan 27, 2016 at 5:07 PM, Ralf Gommers > wrote: > > > > > > On Wed, Jan 27, 2016 at 11:02 PM, sebastian < > > sebast...@sipsolutions.net> wrote: > > > On 2016-01-27 21:01, Ralf Gommers wrote: > > > > > > > > One issue will be how to keep this consistent. `stacklevel` is > > > > used so > > > > rarely that new PRs will always omit it for new warnings. Will > > > > we just > > > > rely on code review, or would a private wrapper around `warn` > > > > to use > > > > inside numpy plus a test that checks that the wrapper is used > > > > everywhere be helpful here? > > > > > > > > > > > Yeah, I mean you could add tests for the individual functions in > > > principle. > > > I am not sure if adding an alias helps much, how are we going to > > > test that > > > warnings.warn is not being used? Seems like quite a bit of voodoo > > > necessary > > > for that. > > > > > I was thinking something along these lines, but with a regexp > > checking for warnings.warn: https://github.com/scipy/scipy/blob/mas > > ter/scipy/fftpack/tests/test_import.py > > > > Probably more trouble than it's worth though. > > > > Ralf > > > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Proposal for IQR function
I have created an IQR function to add to the other dispersion metrics such as standard deviation. I have described the purpose and nature of the proposal in PR#7137, so I am pasting the text here as well: Motivation -- This function is used in one place in numpy already (to compute the Freedman-Diaconis histogram bin estimator) in addition to being requested on Stack Overflow a couple of times: - http://stackoverflow.com/questions/23228244/how-do-you-find-the-iqr-in-numpy - http://stackoverflow.com/questions/27472330/how-should-the-interquartile-range-be-calculated-in-python It is also used in matplotlib for box and violin plots: http://matplotlib.org/faq/howto_faq.html#interpreting-box-plots-and-violin-plots. It is a very simple, common and robust dispersion estimator. There does not appear to be an implementation for it anywhere in numpy or scipy. About - This function is a convenience combination of `np.percentile` and `np.subtract`. As such, it allows the the difference between any two percentiles to be computed, not necessarily (25, 75), which is the default. All of the recent enhancements to percentile are used. The documentation and testing is borrowed heavily from `np.percentile`. Wikipedia Reference: https://en.wikipedia.org/wiki/Interquartile_range Note -- The tests will not pass until the bug-fix for `np.percentile` kwarg `interpolation='midpoint'` (#7129) is incorporated and this PR is rebased. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Numpy 1.11.0b2 released
Hi All, I hope I am pleased to announce the Numpy 1.11.0b2 release. The first beta was a damp squib due to missing files in the released source files, this release fixes that. The new source filese may be downloaded from sourceforge, no binaries will be released until the mingw tool chain problems are sorted. Please test and report any problem. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
Hi, On Thu, Jan 28, 2016 at 12:51 PM, Charles R Harris wrote: > Hi All, > > I hope I am pleased to announce the Numpy 1.11.0b2 release. The first beta > was a damp squib due to missing files in the released source files, this > release fixes that. The new source filese may be downloaded from > sourceforge, no binaries will be released until the mingw tool chain > problems are sorted. > > Please test and report any problem. OSX wheels build OK: https://travis-ci.org/MacPython/numpy-wheels/builds/105521850 Y'all can test with: pip install --pre --trusted-host wheels.scipy.org -f http://wheels.scipy.org numpy Cheers, Matthew ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
Maybe we should upload to pypi? This allows us to upload binaries for osx at least, and in general will make the beta available to anyone who does 'pip install --pre numpy'. (But not regular 'pip install numpy', because pip is clever enough to recognize that this is a prerelease and should not be used by default.) (For bonus points, start a campaign to convince everyone to add --pre to their ci setups, so that merely uploading a prerelease will ensure that it starts getting tested automatically.) On Jan 28, 2016 12:51 PM, "Charles R Harris" wrote: > Hi All, > > I hope I am pleased to announce the Numpy 1.11.0b2 release. The first beta > was a damp squib due to missing files in the released source files, this > release fixes that. The new source filese may be downloaded from > sourceforge, no binaries will be released until the mingw tool chain > problems are sorted. > > Please test and report any problem. > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Problem with NumPy 1.10.4 with ATLAS on Python 2.7.8
Hi all, I recently upgraded NumPy from 1.9.1 to 1.10.4 on Python 2.7.8 by using pip. As always I specified the paths to Blas, Lapack and Atlas in the respective environment variables. I used the same compiler I used to compile both Python and the libraries (GCC 4.6.1). The problem is that it always tries to get Blas symbols in the wrong library: >>> import numpy Traceback (most recent call last): File "", line 1, in File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/__init__.py", line 180, in from . import add_newdocs File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/add_newdocs.py", line 13, in from numpy.lib import add_newdoc File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/lib/__init__.py", line 8, in from .type_check import * File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/lib/type_check.py", line 11, in import numpy.core.numeric as _nx File "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/core/__init__.py", line 14, in from . import multiarray ImportError: /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- packages/numpy/core/multiarray.so: undefined symbol: cblas_sgemm I also tried to install from source instead of pip but no luck either. The only way to get it to work is to downgrade to 1.9.1. Any idea why? Thanks. Davide___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: > Maybe we should upload to pypi? This allows us to upload binaries for osx > at least, and in general will make the beta available to anyone who does > 'pip install --pre numpy'. (But not regular 'pip install numpy', because > pip is clever enough to recognize that this is a prerelease and should not > be used by default.) > > (For bonus points, start a campaign to convince everyone to add --pre to > their ci setups, so that merely uploading a prerelease will ensure that it > starts getting tested automatically.) > On Jan 28, 2016 12:51 PM, "Charles R Harris" > wrote: > >> Hi All, >> >> I hope I am pleased to announce the Numpy 1.11.0b2 release. The first >> beta was a damp squib due to missing files in the released source files, >> this release fixes that. The new source filese may be downloaded from >> sourceforge, no binaries will be released until the mingw tool chain >> problems are sorted. >> >> Please test and report any problem. >> > So what happens if I use twine to upload a beta? Mind, I'd give it a try if pypi weren't an irreversible machine of doom. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
AFAIK beta releases act just like regular releases, except that the pip ui and the pypi ui continue to emphasize the older "real" release. On Jan 28, 2016 2:03 PM, "Charles R Harris" wrote: > > > On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: > >> Maybe we should upload to pypi? This allows us to upload binaries for osx >> at least, and in general will make the beta available to anyone who does >> 'pip install --pre numpy'. (But not regular 'pip install numpy', because >> pip is clever enough to recognize that this is a prerelease and should not >> be used by default.) >> >> (For bonus points, start a campaign to convince everyone to add --pre to >> their ci setups, so that merely uploading a prerelease will ensure that it >> starts getting tested automatically.) >> On Jan 28, 2016 12:51 PM, "Charles R Harris" >> wrote: >> >>> Hi All, >>> >>> I hope I am pleased to announce the Numpy 1.11.0b2 release. The first >>> beta was a damp squib due to missing files in the released source files, >>> this release fixes that. The new source filese may be downloaded from >>> sourceforge, no binaries will be released until the mingw tool chain >>> problems are sorted. >>> >>> Please test and report any problem. >>> >> > So what happens if I use twine to upload a beta? Mind, I'd give it a try > if pypi weren't an irreversible machine of doom. > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with NumPy 1.10.4 with ATLAS on Python 2.7.8
What does ldd /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/core/multiarray.so say? (I'm not a numpy build expert but that should at least give a hint at which kind of brokenness you're running into... I'm also somewhat curious why you're using such an ancient compiler, but that's unlikely to be the issue.) On Jan 28, 2016 1:43 PM, "Davide Vanzo" wrote: > Hi all, > I recently upgraded NumPy from 1.9.1 to 1.10.4 on Python 2.7.8 by using > pip. As always I specified the paths to Blas, Lapack and Atlas in the > respective environment variables. I used the same compiler I used to > compile both Python and the libraries (GCC 4.6.1). The problem is that it > always tries to get Blas symbols in the wrong library: > > >>> import numpy > Traceback (most recent call last): > File "", line 1, in > File > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/__init__.py", > line 180, in > from . import add_newdocs > File > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/add_newdocs.py", > line 13, in > from numpy.lib import add_newdoc > File > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/lib/__init__.py", > line 8, in > from .type_check import * > File > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/lib/type_check.py", > line 11, in > import numpy.core.numeric as _nx > File > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/core/__init__.py", > line 14, in > from . import multiarray > ImportError: > /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site-packages/numpy/core/multiarray.so: > undefined symbol: cblas_sgemm > > I also tried to install from source instead of pip but no luck either. > The only way to get it to work is to downgrade to 1.9.1. > Any idea why? > > Thanks. > > Davide > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Thu, Jan 28, 2016 at 11:03 PM, Charles R Harris < charlesr.har...@gmail.com> wrote: > > > On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: > >> Maybe we should upload to pypi? This allows us to upload binaries for osx >> at least, and in general will make the beta available to anyone who does >> 'pip install --pre numpy'. (But not regular 'pip install numpy', because >> pip is clever enough to recognize that this is a prerelease and should not >> be used by default.) >> >> (For bonus points, start a campaign to convince everyone to add --pre to >> their ci setups, so that merely uploading a prerelease will ensure that it >> starts getting tested automatically.) >> On Jan 28, 2016 12:51 PM, "Charles R Harris" >> wrote: >> >>> Hi All, >>> >>> I hope I am pleased to announce the Numpy 1.11.0b2 release. The first >>> beta was a damp squib due to missing files in the released source files, >>> this release fixes that. The new source filese may be downloaded from >>> sourceforge, no binaries will be released until the mingw tool chain >>> problems are sorted. >>> >>> Please test and report any problem. >>> >> > So what happens if I use twine to upload a beta? Mind, I'd give it a try > if pypi weren't an irreversible machine of doom. > One of the things that will probably happen but needs to be avoided is that 1.11b2 becomes the visible release at https://pypi.python.org/pypi/numpy. By default I think the status of all releases but the last uploaded one (or highest version number?) is set to hidden. Other ways that users can get a pre-release by accident are: - they have pip <1.4 (released in July 2013) - other packages have a requirement on numpy with a prerelease version (see https://pip.pypa.io/en/stable/reference/pip_install/#pre-release-versions) Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Problem with NumPy 1.10.4 with ATLAS on Python 2.7.8
Nathaniel, thanks for your reply. Here is the output you requested (and a little more). # ldd /usr/local/python2/2.7.8/x86_64/gcc46/nonet/lib/python2.7/site- packages/numpy/core/multiarray.so linux-vdso.so.1 => (0x7fffce3f2000) libatlas.so => /usr/local/atlas/latest/x86_64/gcc46/nonet/lib/libatlas.so (0x7f86253df000) libm.so.6 => /lib64/libm.so.6 (0x7f8625147000) libpython2.7.so.1.0 => /usr/local/python2/2.7.8/x86_64/gcc46/nonet/lib/libpython2.7.so.1.0 (0x7f8624d6c000) libpthread.so.0 => /lib64/libpthread.so.0 (0x7f8624b4f000) libc.so.6 => /lib64/libc.so.6 (0x7f86247ba000) /lib64/ld-linux-x86-64.so.2 (0x7f8626409000) libdl.so.2 => /lib64/libdl.so.2 (0x7f86245b6000) libutil.so.1 => /lib64/libutil.so.1 (0x7f86243b3000) # nm -D /usr/local/atlas/latest/x86_64/gcc46/nonet/lib/libatlas.so | grep cblas # nm -D /usr/local/atlas/latest/x86_64/gcc46/nonet/lib/liblapack.so | grep cblas U cblas_cdotc_sub U cblas_cgemm […] U cblas_sgemm U cblas_sgemv […] U cblas_ztrsv I'm pretty familiar with this error and I always solved it by correctly pointing the installer to the correct library paths with the BLAS/LAPACK/ATLAS environment variables. However with 1.10.4 no matter how I tried to define such variables (even by inserting them in the site.cfg file), there was no way to make it work. Davide On Thu, 2016-01-28 at 14:23 -0800, Nathaniel Smith wrote: > What does > ldd > /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- > packages/numpy/core/multiarray.so > say? > (I'm not a numpy build expert but that should at least give a hint at > which kind of brokenness you're running into... I'm also somewhat > curious why you're using such an ancient compiler, but that's > unlikely to be the issue.) > On Jan 28, 2016 1:43 PM, "Davide Vanzo" > wrote: > > Hi all, > > I recently upgraded NumPy from 1.9.1 to 1.10.4 on Python 2.7.8 by > > using pip. As always I specified the paths to Blas, Lapack and > > Atlas in the respective environment variables. I used the same > > compiler I used to compile both Python and the libraries (GCC > > 4.6.1). The problem is that it always tries to get Blas symbols in > > the wrong library: > > > > >>> import numpy > > Traceback (most recent call last): > > File "", line 1, in > > File > > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site > > -packages/numpy/__init__.py", line 180, in > > from . import add_newdocs > > File > > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site > > -packages/numpy/add_newdocs.py", line 13, in > > from numpy.lib import add_newdoc > > File > > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site > > -packages/numpy/lib/__init__.py", line 8, in > > from .type_check import * > > File > > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site > > -packages/numpy/lib/type_check.py", line 11, in > > import numpy.core.numeric as _nx > > File > > "/usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site > > -packages/numpy/core/__init__.py", line 14, in > > from . import multiarray > > ImportError: > > /usr/local/python2/2.7.8/x86_64/gcc46/New_build/lib/python2.7/site- > > packages/numpy/core/multiarray.so: undefined symbol: cblas_sgemm > > > > I also tried to install from source instead of pip but no luck > > either. > > The only way to get it to work is to downgrade to 1.9.1. > > Any idea why? > > > > Thanks. > > > > Davide > > > > ___ > > NumPy-Discussion mailing list > > NumPy-Discussion@scipy.org > > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Thu, Jan 28, 2016 at 2:23 PM, Ralf Gommers wrote: > > > On Thu, Jan 28, 2016 at 11:03 PM, Charles R Harris > wrote: >> >> >> >> On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: >>> >>> Maybe we should upload to pypi? This allows us to upload binaries for osx >>> at least, and in general will make the beta available to anyone who does >>> 'pip install --pre numpy'. (But not regular 'pip install numpy', because pip >>> is clever enough to recognize that this is a prerelease and should not be >>> used by default.) >>> >>> (For bonus points, start a campaign to convince everyone to add --pre to >>> their ci setups, so that merely uploading a prerelease will ensure that it >>> starts getting tested automatically.) >>> >>> On Jan 28, 2016 12:51 PM, "Charles R Harris" >>> wrote: Hi All, I hope I am pleased to announce the Numpy 1.11.0b2 release. The first beta was a damp squib due to missing files in the released source files, this release fixes that. The new source filese may be downloaded from sourceforge, no binaries will be released until the mingw tool chain problems are sorted. Please test and report any problem. >> >> >> So what happens if I use twine to upload a beta? Mind, I'd give it a try >> if pypi weren't an irreversible machine of doom. > > > One of the things that will probably happen but needs to be avoided is that > 1.11b2 becomes the visible release at https://pypi.python.org/pypi/numpy. By > default I think the status of all releases but the last uploaded one (or > highest version number?) is set to hidden. Huh, I had the impression that if it was ambiguous whether the "latest version" was a pre-release or not, then pypi would list all of them on that page -- at least I know I've seen projects where going to the main pypi URL gives a list of several versions like that. Or maybe the next-to-latest one gets hidden by default and you're supposed to go back and "un-hide" the last release manually. Could try uploading to https://testpypi.python.org/pypi and see what happens... > Other ways that users can get a pre-release by accident are: > - they have pip <1.4 (released in July 2013) It looks like ~a year ago this was ~20% of users -- https://caremad.io/2015/04/a-year-of-pypi-downloads/ I wouldn't be surprised if it dropped quite a bit since then, but if this is something that will affect our decision then we can ping @dstufft to ask for updated numbers. -n -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Thu, Jan 28, 2016 at 11:57 PM, Nathaniel Smith wrote: > On Thu, Jan 28, 2016 at 2:23 PM, Ralf Gommers > wrote: > > > > > > On Thu, Jan 28, 2016 at 11:03 PM, Charles R Harris > > wrote: > >> > >> > >> > >> On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: > >>> > >>> Maybe we should upload to pypi? This allows us to upload binaries for > osx > >>> at least, and in general will make the beta available to anyone who > does > >>> 'pip install --pre numpy'. (But not regular 'pip install numpy', > because pip > >>> is clever enough to recognize that this is a prerelease and should not > be > >>> used by default.) > >>> > >>> (For bonus points, start a campaign to convince everyone to add --pre > to > >>> their ci setups, so that merely uploading a prerelease will ensure > that it > >>> starts getting tested automatically.) > >>> > >>> On Jan 28, 2016 12:51 PM, "Charles R Harris" < > charlesr.har...@gmail.com> > >>> wrote: > > Hi All, > > I hope I am pleased to announce the Numpy 1.11.0b2 release. The first > beta was a damp squib due to missing files in the released source > files, > this release fixes that. The new source filese may be downloaded from > sourceforge, no binaries will be released until the mingw tool chain > problems are sorted. > > Please test and report any problem. > >> > >> > >> So what happens if I use twine to upload a beta? Mind, I'd give it a try > >> if pypi weren't an irreversible machine of doom. > > > > > > One of the things that will probably happen but needs to be avoided is > that > > 1.11b2 becomes the visible release at https://pypi.python.org/pypi/numpy. > By > > default I think the status of all releases but the last uploaded one (or > > highest version number?) is set to hidden. > > Huh, I had the impression that if it was ambiguous whether the "latest > version" was a pre-release or not, then pypi would list all of them on > that page -- at least I know I've seen projects where going to the > main pypi URL gives a list of several versions like that. Or maybe the > next-to-latest one gets hidden by default and you're supposed to go > back and "un-hide" the last release manually. > > Could try uploading to > > https://testpypi.python.org/pypi > > and see what happens... > That's worth a try, would be good to know what the behavior is. > > > Other ways that users can get a pre-release by accident are: > > - they have pip <1.4 (released in July 2013) > > It looks like ~a year ago this was ~20% of users -- > https://caremad.io/2015/04/a-year-of-pypi-downloads/ > I wouldn't be surprised if it dropped quite a bit since then, but if > this is something that will affect our decision then we can ping > @dstufft to ask for updated numbers. > Hmm, that's more than I expected. Even if it dropped by a factor of 10 over the last year, that would still be a lot of failed installs for the current beta1. It looks to me like this is a bad trade-off. It would be much better to encourage people to test against numpy master instead of a pre-release (and we were trying to do that anyway). So the benefit is then fairly limited, mostly typing the longer line including wheels.scipy.org when someone wants to test a pre-release. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Jan 28, 2016 3:25 PM, "Ralf Gommers" wrote: > > > > On Thu, Jan 28, 2016 at 11:57 PM, Nathaniel Smith wrote: >> >> On Thu, Jan 28, 2016 at 2:23 PM, Ralf Gommers wrote: >> > >> > >> > On Thu, Jan 28, 2016 at 11:03 PM, Charles R Harris >> > wrote: >> >> >> >> >> >> >> >> On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith wrote: >> >>> >> >>> Maybe we should upload to pypi? This allows us to upload binaries for osx >> >>> at least, and in general will make the beta available to anyone who does >> >>> 'pip install --pre numpy'. (But not regular 'pip install numpy', because >> >>> pip >> >>> is clever enough to recognize that this is a prerelease and should not be >> >>> used by default.) >> >>> >> >>> (For bonus points, start a campaign to convince everyone to add --pre to >> >>> their ci setups, so that merely uploading a prerelease will ensure that >> >>> it >> >>> starts getting tested automatically.) >> >>> >> >>> On Jan 28, 2016 12:51 PM, "Charles R Harris" >> >>> wrote: >> >> Hi All, >> >> I hope I am pleased to announce the Numpy 1.11.0b2 release. The first >> beta was a damp squib due to missing files in the released source files, >> this release fixes that. The new source filese may be downloaded from >> sourceforge, no binaries will be released until the mingw tool chain >> problems are sorted. >> >> Please test and report any problem. >> >> >> >> >> >> So what happens if I use twine to upload a beta? Mind, I'd give it a try >> >> if pypi weren't an irreversible machine of doom. >> > >> > >> > One of the things that will probably happen but needs to be avoided is that >> > 1.11b2 becomes the visible release at https://pypi.python.org/pypi/numpy. >> > By >> > default I think the status of all releases but the last uploaded one (or >> > highest version number?) is set to hidden. >> >> Huh, I had the impression that if it was ambiguous whether the "latest >> version" was a pre-release or not, then pypi would list all of them on >> that page -- at least I know I've seen projects where going to the >> main pypi URL gives a list of several versions like that. Or maybe the >> next-to-latest one gets hidden by default and you're supposed to go >> back and "un-hide" the last release manually. >> >> Could try uploading to >> >> https://testpypi.python.org/pypi >> >> and see what happens... > > > That's worth a try, would be good to know what the behavior is. > >> >> >> > Other ways that users can get a pre-release by accident are: >> > - they have pip <1.4 (released in July 2013) >> >> It looks like ~a year ago this was ~20% of users -- >> https://caremad.io/2015/04/a-year-of-pypi-downloads/ >> I wouldn't be surprised if it dropped quite a bit since then, but if >> this is something that will affect our decision then we can ping >> @dstufft to ask for updated numbers. > > > Hmm, that's more than I expected. Even if it dropped by a factor of 10 over > the last year, that would still be a lot of failed installs for the current > beta1. It looks to me like this is a bad trade-off. It would be much better > to encourage people to test against numpy master instead of a pre-release > (and we were trying to do that anyway). So the benefit is then fairly > limited, mostly typing the longer line including wheels.scipy.org when > someone wants to test a pre-release. After the disastrous lack of testing for the 1.10 prereleases, it might almost be a good thing if we accidentally swept up some pip 1.3 users into doing prerelease testing... I mean, if they don't test it now, they'll just end up testing it later, and at least there will be fewer of them to start with? Plus all they have to do to opt out is to maintain a vaguely up-to-date environment, which is a good thing for the ecosystem anyway :-). It's bad for everyone if pip and PyPI are collaborating to provide this rather nice, standard feature for distributing and QAing pre-releases, but we can't actually use it because of people not upgrading pip... Regarding CI setups and testing against master: I think of these as being complementary. The fact is that master *will* sometimes just be broken, or contain tentative API changes that get changed before the release, etc. So it's really great that there are some projects who are willing to take on the work of testing numpy master directly as part of their own CI setups, but it is going to be extra work and risk for them, they'll probably have to switch it off sometimes and then turn it back on, and they really need to have decent channels of communication with us whenever things go wrong because sometimes the answer will be "doh, we didn't mean to change that, please leave your code alone and we'll fix it on our end". (My nightmare here is that downstream projects start working around bugs in master, and then we find ourselves having to jump through hoops to maintain backcompat with code that was never even released. __numpy_ufunc__ is stuck in this s
Re: [Numpy-discussion] Numpy 1.11.0b2 released
On Fri, Jan 29, 2016 at 4:21 AM, Nathaniel Smith wrote: > On Jan 28, 2016 3:25 PM, "Ralf Gommers" wrote: > > > > > > > > On Thu, Jan 28, 2016 at 11:57 PM, Nathaniel Smith wrote: > >> > >> On Thu, Jan 28, 2016 at 2:23 PM, Ralf Gommers > wrote: > >> > > >> > > >> > On Thu, Jan 28, 2016 at 11:03 PM, Charles R Harris > >> > wrote: > >> >> > >> >> > >> >> > >> >> On Thu, Jan 28, 2016 at 2:36 PM, Nathaniel Smith > wrote: > >> >>> > >> >>> Maybe we should upload to pypi? This allows us to upload binaries > for osx > >> >>> at least, and in general will make the beta available to anyone who > does > >> >>> 'pip install --pre numpy'. (But not regular 'pip install numpy', > because pip > >> >>> is clever enough to recognize that this is a prerelease and should > not be > >> >>> used by default.) > >> >>> > >> >>> (For bonus points, start a campaign to convince everyone to add > --pre to > >> >>> their ci setups, so that merely uploading a prerelease will ensure > that it > >> >>> starts getting tested automatically.) > >> >>> > >> >>> On Jan 28, 2016 12:51 PM, "Charles R Harris" < > charlesr.har...@gmail.com> > >> >>> wrote: > >> > >> Hi All, > >> > >> I hope I am pleased to announce the Numpy 1.11.0b2 release. The > first > >> beta was a damp squib due to missing files in the released source > files, > >> this release fixes that. The new source filese may be downloaded > from > >> sourceforge, no binaries will be released until the mingw tool > chain > >> problems are sorted. > >> > >> Please test and report any problem. > >> >> > >> >> > >> >> So what happens if I use twine to upload a beta? Mind, I'd give it a > try > >> >> if pypi weren't an irreversible machine of doom. > >> > > >> > > >> > One of the things that will probably happen but needs to be avoided > is that > >> > 1.11b2 becomes the visible release at > https://pypi.python.org/pypi/numpy. By > >> > default I think the status of all releases but the last uploaded one > (or > >> > highest version number?) is set to hidden. > >> > >> Huh, I had the impression that if it was ambiguous whether the "latest > >> version" was a pre-release or not, then pypi would list all of them on > >> that page -- at least I know I've seen projects where going to the > >> main pypi URL gives a list of several versions like that. Or maybe the > >> next-to-latest one gets hidden by default and you're supposed to go > >> back and "un-hide" the last release manually. > >> > >> Could try uploading to > >> > >> https://testpypi.python.org/pypi > >> > >> and see what happens... > > > > > > That's worth a try, would be good to know what the behavior is. > > > >> > >> > >> > Other ways that users can get a pre-release by accident are: > >> > - they have pip <1.4 (released in July 2013) > >> > >> It looks like ~a year ago this was ~20% of users -- > >> https://caremad.io/2015/04/a-year-of-pypi-downloads/ > >> I wouldn't be surprised if it dropped quite a bit since then, but if > >> this is something that will affect our decision then we can ping > >> @dstufft to ask for updated numbers. > > > > > > Hmm, that's more than I expected. Even if it dropped by a factor of 10 > over the last year, that would still be a lot of failed installs for the > current beta1. It looks to me like this is a bad trade-off. It would be > much better to encourage people to test against numpy master instead of a > pre-release (and we were trying to do that anyway). So the benefit is then > fairly limited, mostly typing the longer line including wheels.scipy.org > when someone wants to test a pre-release. > > After the disastrous lack of testing for the 1.10 prereleases, it > might almost be a good thing if we accidentally swept up some pip 1.3 > users into doing prerelease testing... I mean, if they don't test it > now, they'll just end up testing it later, and at least there will be > fewer of them to start with? Plus all they have to do to opt out is to > maintain a vaguely up-to-date environment, which is a good thing for > the ecosystem anyway :-). It's bad for everyone if pip and PyPI are > collaborating to provide this rather nice, standard feature for > distributing and QAing pre-releases, but we can't actually use it > because of people not upgrading pip... > That's a fair point. And given the amount of brokenness in (especially older versions of ) pip, plus how easy it is to upgrade pip, we should probably just say that we expect a recent pip (say last 3 major releases). > > Regarding CI setups and testing against master: I think of these as > being complementary. The fact is that master *will* sometimes just be > broken, or contain tentative API changes that get changed before the > release, etc. So it's really great that there are some projects who > are willing to take on the work of testing numpy master directly as > part of their own CI setups, but it is going to be extra work and risk > for them, they'll probably have to switch it
