If I recall correctly, people were building against the Numpy 2.0.0 release
candidates in particular. In hindsight keeping those on PyPI might have
been better. A formal NEP/SPEC seems a good idea.
Peter
On Tue, Sep 3, 2024 at 6:20 PM matti picus wrote:
> I would prefer we never delete packages
This looks handy - I used the following to try it:
$ pip install -U ruff
$ ruff --preview --select NPY201 --fix
Happily nothing to address on the code baseI tried.
Thanks,
Peter
On Thu, Jan 11, 2024 at 11:32 AM Mateusz Sokol wrote:
>
> Hi all!
>
> Some time ago we added a new rule to Ruff li
Hello all,
I imagine there are many people here using the black coding style as
implemented by the tool black, albeit with reservations about how it
lays out arrays by default (often therefore wrapped in a format off/on
block to exclude the array from automatic layout to allow for manual
column ba
On Tue, Oct 10, 2023 at 6:32 PM Matthew Brett
wrote:
> Hi,
>
>
> On Tue, 10 Oct 2023 at 00:55, Andrew Nelson wrote:
> >
> >
> > On Mon, 9 Oct 2023 at 23:50, Matthew Brett
> wrote:
> >>
> >> Hi,
> >>
> >> On Mon, Oct 9, 2023 at 11:49 AM Andrew Nelson
> wrote:
> >> Could you say more about why y
On Sat, Mar 25, 2023 at 12:35 PM Matteo Raso via NumPy-Discussion
wrote:
>
> P.S. I originally tried to send this message as an email, but it was instantly
> rejected because I'm not a list member. That's a pretty serious error for a
> public mailing list.
That's very normal on a mailing list. Ev
Hello Sebastian,
I rarely use NumPy scalars directly, but the repr change could
have impact in assorted downstream projects' documentation.
For clarity, this idea would not alter how NumPy arrays print,
would it - since they already include the type information?
>>> np.array([34.3, 10.1, -0.5],
On Fri, May 6, 2022 at 4:59 PM Charles R Harris
wrote:
>
> Heh. I think automatic formatting is the future and was happy to see the
> PR. The only question is if black is the way we want to go. IIRC, the main
> sticking points were
>
>- Line length (<= 79).
>- Quotation mark changes (nois
at 7:24 PM Matti Picus wrote:
> On 18/1/22 5:37 pm, Peter Cock wrote:
>
> > Dear Charles,
> >
> > Thank you for your work on the numpy releases, including v1.22.1.
> >
> > I noticed that for Windows Python 3.10, there is only a 64-bit wheel:
> >
> >
Dear Charles,
Thank you for your work on the numpy releases, including v1.22.1.
I noticed that for Windows Python 3.10, there is only a 64-bit wheel:
numpy-1.22.1-cp310-cp310-win_amd64.whl
That is true both on PyPI and in the list of checksums here:
https://github.com/numpy/numpy/releases/tag/
That's great, thanks! Hopefully I'll get time to sort that out soon.
Peter
On Thu, Jan 6, 2022 at 3:23 PM Matti Picus wrote:
>
> On 6/1/22 2:15 pm, Peter Cock wrote:
>
> > Hello Matti, Charles,
> >
> > ...
> >
> > Do you have any advice on
Hello Matti, Charles,
I'm a minor numpy contributor but mostly follow the mailing list with an eye
on any impacts downstream for Biopython. Like numpy and scipy etc, we
had been using TravisCI to build our wheels:
https://github.com/biopython/biopython-wheels
Lots of other projects using multibu
On Tue, Nov 2, 2021 at 1:07 PM Ralf Gommers wrote:
>
> Our current wheel build machinery is at
> https://github.com/MacPython/numpy-wheels/,
> but please ignore that. We just merged a PR which uses cibuildwheel into the
> main repo.
> That should be the target. If cibuildwheel has/gains the ab
I would recommend using the community run conda-forge as one of your
default conda channels. They have a very slick largely automated system
to update recipes when upstream makes a release. The default Anaconda
channel from Anaconda, Inc. (formerly Continuum Analytics, Inc.) is
comparatively slow.
b.com/biopython/biopython-wheels
Do you need any other information from me, or the Biopython team?
Thank you,
Peter,
(On behalf of Biopython)
On Tue, Aug 11, 2020 at 6:34 AM Matti Picus wrote:
>
> On 8/11/20 12:39 AM, Peter Cock wrote:
>
> Hi Matti,
>
> Is this an open invita
Hi Matti,
Is this an open invitation to the wider Numpy ecosystem? I am
interested on behalf of Biopython which was using the donated
Rackspace for multibuild wheel staging prior to PyPy release
(although having weekly test releases sounds interesting too).
I would be happy to continue this discu
Ah - this is unwelcome news.
See https://mail.python.org/pipermail/scipy-dev/2020-February/023990.html
and https://github.com/matthew-brett/multibuild/issues/304
There are quite a few project's using the multibuild system now...
Peter
On Fri, Aug 7, 2020 at 2:01 PM Kevin Sheppard
wrote:
> The
To save anyone else looking, it was pull request 15185:
https://github.com/numpy/numpy/pull/15185
Peter
On Mon, Jan 13, 2020 at 5:25 PM mpro wrote:
>
> Hi,
>
> 18 days ago I submitted pull request that improves accuracy of mean function
> by calculating mean sequentially along certain axis.
> H
I’d find this sort of (stricter) numpydoc validation tool very useful,
especially if the different codes can be selectively enforced while
bringing a large code base into compliance (as pandas seems to have used
this).
A stand alone tool would be fine, a flake8 plug-in perhaps even better -
see al
On Tue, Jul 2, 2019 at 11:19 PM Matti Picus wrote:
> In PR 13886 I reworked the way the link to the release notes is
> generated. The current page is
>
>
> http://www.numpy.org/devdocs/release.html
>
>
> and the new page is
>
>
>
> https://8001-908607-gh.circle-artifacts.com/0/home/circleci/repo
On Thu, Feb 8, 2018 at 11:22 AM, Ralf Gommers wrote:
> On Wed, Feb 7, 2018 at 11:29 PM, Stefan van der Walt
> wrote:
>>
>> For scikit-image, we've started a policy of pushing minor edits
>> (spelling corrections, sentence restructuring, etc.) directly to the PR
>> branch, instead of flagging thos
On Wed, Feb 7, 2018 at 11:04 PM, Andrew Nelson wrote:
> Other factors hindering new contributors:
>
> 1) Being unfamiliar with git. e.g. knowing that you have to fork numpy
> first, then clone from your fork, then create a feature branch. That's just
> the """straightforward bit""". It's hell the
Since Konrad Hinsen no longer follows the NumPy discussion list
for lack of time, he has not posted here - but he has commented
about this on Twitter and written up a good blog post:
http://blog.khinsen.net/posts/2017/11/16/a-plea-for-stability-in-the-scipy-ecosystem/
In a field where scientific
On Wed, Nov 8, 2017 at 10:17 PM, Bryan Van de ven wrote:
>
>> On Nov 8, 2017, at 10:50, Peter Cock wrote:
>>
>> NumPy (and to a lesser extent SciPy) is in a tough position being at the
>> bottom of many scientific Python programming stacks. Whenever you
>> drop P
On Tue, Nov 7, 2017 at 11:40 PM, Nathaniel Smith wrote:
>
>
>
> Right now, the decision in front of us is what to tell people who ask about
> numpy's py2 support plans, so that they can make their own plans. Given what
> we know right now, I don't think we should promise to keep support past
> 20
This came up for Biopython recently (someone using our
library on a cluster ran into thread limits triggered by the
importing of NumPy), and suggested something like this:
import os
try:
os.environ["OMP_NUM_THREADS"] = "1"
import numpy
finally:
del os.environ["OMP_NUM_THREADS"]
Or MKL_
On Wed, Jul 5, 2017 at 11:25 AM, Ralf Gommers wrote:
>
>
> On Wed, Jul 5, 2017 at 10:14 PM, Peter Cock
> wrote:
>>
>> Note that TravisCI does not yet have official Python support on Mac OS X,
>>
>> https://github.com/travis-ci/travis-ci/issues/2312
>>
&
Note that TravisCI does not yet have official Python support on Mac OS X,
https://github.com/travis-ci/travis-ci/issues/2312
I believe it is possible to do anyway by faking it under another setting
(e.g. pretend to be a generic language build, and use the system Python
or install your own specifi
27 matches
Mail list logo
