From sebastian at sipsolutions.net Tue Sep 1 11:10:30 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 01 Sep 2020 10:10:30 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday Message-ID: Hi all, There will be a NumPy Community meeting Wednesday September 2nd at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ralf.gommers at gmail.com Wed Sep 2 06:33:10 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 2 Sep 2020 11:33:10 +0100 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils Message-ID: Hi all, I spent some time looking at the fallout of the setuptools 50.0 release. There's quite a few small issues, those can/should all be worked around by pinning setuptools to a lower version. The root cause and main longer-term issue is that numpy.distutils extends and monkeypatches distutils, which mostly was fine because distutils moved super slowly and had a decent QA process. Now with setuptools, any patch goes into master and gets released to the whole wide world without any testing. The summary of that and how to deal with it I posted on https://github.com/pypa/setuptools/issues/2372 for discussion. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sat Sep 5 07:12:06 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sat, 5 Sep 2020 12:12:06 +0100 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: References: Message-ID: Hi all, Preliminary conclusion: let's pin all packages to setuptools < 50.0 and wait for 6-9 months till the dust settles. Things may still change; the reception of PEP 632 [1] hasn't been a "great idea, let's just rip it out without a plan" one so far. Cheers, Ralf [1] https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 On Wed, Sep 2, 2020 at 11:33 AM Ralf Gommers wrote: > Hi all, > > I spent some time looking at the fallout of the setuptools 50.0 release. > There's quite a few small issues, those can/should all be worked around by > pinning setuptools to a lower version. > > The root cause and main longer-term issue is that numpy.distutils extends > and monkeypatches distutils, which mostly was fine because distutils moved > super slowly and had a decent QA process. Now with setuptools, any patch > goes into master and gets released to the whole wide world without any > testing. The summary of that and how to deal with it I posted on > https://github.com/pypa/setuptools/issues/2372 for discussion. > > Cheers, > Ralf > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cournape at gmail.com Sun Sep 6 01:06:31 2020 From: cournape at gmail.com (David Cournapeau) Date: Sun, 6 Sep 2020 14:06:31 +0900 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: References: Message-ID: I will comment with more details on GH, but I think jraco's suggestion makes a lot of sense. I would be willing to spend some time to merge upstream (i.e. setuptools now :) ) some of our changes in numpy.distutils. Assuming the numpy.distutils codebase has not changed much in the last 10 years, my sense is that a lot of the features that relied on monkey patching can be merged upstream, fortran support being one notable exception. I remember trying to put in mingw64 support in distutils upstream 10 years ago, and the pace of communication was so slow that I gave up. But it was technically straightforward. David On Sat, Sep 5, 2020 at 8:13 PM Ralf Gommers wrote: > Hi all, > > Preliminary conclusion: let's pin all packages to setuptools < 50.0 and > wait for 6-9 months till the dust settles. Things may still change; the > reception of PEP 632 [1] hasn't been a "great idea, let's just rip it out > without a plan" one so far. > > Cheers, > Ralf > > [1] https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 > > > On Wed, Sep 2, 2020 at 11:33 AM Ralf Gommers > wrote: > >> Hi all, >> >> I spent some time looking at the fallout of the setuptools 50.0 release. >> There's quite a few small issues, those can/should all be worked around by >> pinning setuptools to a lower version. >> >> The root cause and main longer-term issue is that numpy.distutils extends >> and monkeypatches distutils, which mostly was fine because distutils moved >> super slowly and had a decent QA process. Now with setuptools, any patch >> goes into master and gets released to the whole wide world without any >> testing. The summary of that and how to deal with it I posted on >> https://github.com/pypa/setuptools/issues/2372 for discussion. >> >> Cheers, >> Ralf >> >> _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at grinta.net Sun Sep 6 04:42:52 2020 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 6 Sep 2020 10:42:52 +0200 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: References: Message-ID: <234cc664-54a3-60fc-6bf1-25a2c7ddab25@grinta.net> On 06/09/2020 07:06, David Cournapeau wrote: > Assuming the numpy.distutils codebase has not changed much in the last > 10 years, my sense is that a lot of the features that relied on monkey > patching can be merged upstream,? fortran support being one notable > exception. This may be bigger endeavor, but wouldn't it be possible to extend setuptools interfaces in a way that plugging in the fortran support does not require monkey patching or accessing the implementation internals? Such an extension could also be used to extend setuptools to handle extensions written in other languages such as Rust. By the way, how is Cython affected by this? Cython also distributes an extension to (the module formerly know as) distutils to transparently compile extensions written in Cython. Could the efforts toward multi-language support in distutils be coordinated with the Cython maintainers? Cheers, Dan From ralf.gommers at gmail.com Sun Sep 6 05:26:25 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 6 Sep 2020 10:26:25 +0100 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: References: Message-ID: On Sun, Sep 6, 2020 at 6:07 AM David Cournapeau wrote: > I will comment with more details on GH, but I think jraco's suggestion > makes a lot of sense. I would be willing to spend some time to merge > upstream (i.e. setuptools now :) ) some of our changes in numpy.distutils. > Thanks David! > Assuming the numpy.distutils codebase has not changed much in the last 10 > years, my sense is that a lot of the features that relied on monkey > patching can be merged upstream, fortran support being one notable > exception. > There has been a lot of churn and a few new features, but the structure hasn't changed much so I think your assessment is right. Cheers, Ralf > I remember trying to put in mingw64 support in distutils upstream 10 years > ago, and the pace of communication was so slow that I gave up. But it was > technically straightforward. > > David > > On Sat, Sep 5, 2020 at 8:13 PM Ralf Gommers > wrote: > >> Hi all, >> >> Preliminary conclusion: let's pin all packages to setuptools < 50.0 and >> wait for 6-9 months till the dust settles. Things may still change; the >> reception of PEP 632 [1] hasn't been a "great idea, let's just rip it out >> without a plan" one so far. >> >> Cheers, >> Ralf >> >> [1] https://discuss.python.org/t/pep-632-deprecate-distutils-module/5134 >> >> >> On Wed, Sep 2, 2020 at 11:33 AM Ralf Gommers >> wrote: >> >>> Hi all, >>> >>> I spent some time looking at the fallout of the setuptools 50.0 release. >>> There's quite a few small issues, those can/should all be worked around by >>> pinning setuptools to a lower version. >>> >>> The root cause and main longer-term issue is that numpy.distutils >>> extends and monkeypatches distutils, which mostly was fine because >>> distutils moved super slowly and had a decent QA process. Now with >>> setuptools, any patch goes into master and gets released to the whole wide >>> world without any testing. The summary of that and how to deal with it I >>> posted on https://github.com/pypa/setuptools/issues/2372 for discussion. >>> >>> Cheers, >>> Ralf >>> >>> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Sep 6 05:28:04 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 6 Sep 2020 10:28:04 +0100 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: <234cc664-54a3-60fc-6bf1-25a2c7ddab25@grinta.net> References: <234cc664-54a3-60fc-6bf1-25a2c7ddab25@grinta.net> Message-ID: On Sun, Sep 6, 2020 at 9:50 AM Daniele Nicolodi wrote: > On 06/09/2020 07:06, David Cournapeau wrote: > > Assuming the numpy.distutils codebase has not changed much in the last > > 10 years, my sense is that a lot of the features that relied on monkey > > patching can be merged upstream, fortran support being one notable > > exception. > > This may be bigger endeavor, but wouldn't it be possible to extend > setuptools interfaces in a way that plugging in the fortran support does > not require monkey patching or accessing the implementation internals? > Probably not, since distutils really doesn't have much of a design, or separation between API and implementation. > Such an extension could also be used to extend setuptools to handle > extensions written in other languages such as Rust. > > By the way, how is Cython affected by this? Cython also distributes an > extension to (the module formerly know as) distutils to transparently > compile extensions written in Cython. Could the efforts toward > multi-language support in distutils be coordinated with the Cython > maintainers? > Cython.Distutils is a few hundred lines of code, numpy.distutils is 20,000 lines of code. I don't think Cython will have much problems adapting. Cheers, Ralf > Cheers, > Dan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniele at grinta.net Sun Sep 6 05:39:30 2020 From: daniele at grinta.net (Daniele Nicolodi) Date: Sun, 6 Sep 2020 11:39:30 +0200 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: References: <234cc664-54a3-60fc-6bf1-25a2c7ddab25@grinta.net> Message-ID: <39665d2c-d4b5-0b93-498e-4e458439784a@grinta.net> On 06/09/2020 11:28, Ralf Gommers wrote: > On Sun, Sep 6, 2020 at 9:50 AM Daniele Nicolodi > This may be bigger endeavor, but wouldn't it be possible to extend > setuptools interfaces in a way that plugging in the fortran support does > not require monkey patching or accessing the implementation internals? > > Probably not, since distutils really doesn't have much of a design, or > separation between API and implementation. I was under the impression that one of the reasons why distutils is being deprecated in favor of setuptools is to change this and evolve the code into a better form, not to just move the code around. > By the way, how is Cython affected by this? Cython also distributes an > extension to (the module formerly know as) distutils to transparently > compile extensions written in Cython. Could the efforts toward > multi-language support in distutils be coordinated with the Cython > maintainers? > > Cython.Distutils is a few hundred lines of code, numpy.distutils is > 20,000 lines of code. I don't think Cython will have much problems adapting. I'm well aware of that, however I was only referring to Fortran support here, which may be something valuable to merge upstream. And Cython also injects the support for a different language into distutils/setuptools, thus maybe a common approach could be envisioned, maybe more robust than the current one. I haven't looked at the code, though. Cheers, Dan From cournape at gmail.com Sun Sep 6 10:45:14 2020 From: cournape at gmail.com (David Cournapeau) Date: Sun, 6 Sep 2020 23:45:14 +0900 Subject: [Numpy-discussion] setuptools/distutils merger & numpy.distutils In-Reply-To: <39665d2c-d4b5-0b93-498e-4e458439784a@grinta.net> References: <234cc664-54a3-60fc-6bf1-25a2c7ddab25@grinta.net> <39665d2c-d4b5-0b93-498e-4e458439784a@grinta.net> Message-ID: On Sun, Sep 6, 2020 at 6:40 PM Daniele Nicolodi wrote: > On 06/09/2020 11:28, Ralf Gommers wrote: > > On Sun, Sep 6, 2020 at 9:50 AM Daniele Nicolodi > > This may be bigger endeavor, but wouldn't it be possible to extend > > setuptools interfaces in a way that plugging in the fortran support > does > > not require monkey patching or accessing the implementation > internals? > > > > Probably not, since distutils really doesn't have much of a design, or > > separation between API and implementation. > > I was under the impression that one of the reasons why distutils is > being deprecated in favor of setuptools is to change this and evolve the > code into a better form, not to just move the code around. > The conclusion of most people who do know that codebase is that you can't fix it through evolutionary design. It needs to be redone from the ground up, and few people are interested in doing that work. David > > > By the way, how is Cython affected by this? Cython also distributes > an > > extension to (the module formerly know as) distutils to transparently > > compile extensions written in Cython. Could the efforts toward > > multi-language support in distutils be coordinated with the Cython > > maintainers? > > > > Cython.Distutils is a few hundred lines of code, numpy.distutils is > > 20,000 lines of code. I don't think Cython will have much problems > adapting. > > I'm well aware of that, however I was only referring to Fortran support > here, which may be something valuable to merge upstream. And Cython also > injects the support for a different language into distutils/setuptools, > thus maybe a common approach could be envisioned, maybe more robust than > the current one. I haven't looked at the code, though. > > Cheers, > Dan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ilhanpolat at gmail.com Sun Sep 6 19:37:51 2020 From: ilhanpolat at gmail.com (Ilhan Polat) Date: Mon, 7 Sep 2020 01:37:51 +0200 Subject: [Numpy-discussion] Cythonize and add backslash logic to "scipy.linalg.solve" Message-ID: Dear all, I've finally managed to draft a PR [1] for the functionality given in the title (see also "Algorithms" section of [2]). It is almost halfway done but the gist is already in place. I'm posting this to both NumPy and SciPy lists since I think it is important enough to get feedback from all parties involved.The particular detail I need to be taught is the Cython parts and fleshing out anti-patterns and code smells. Probably NumPy folks are better equipped to spot the C related issues. There is this ILP64 issue that I am aware of which would cause a bit of trouble and I would appreciate it if we can tackle it at this early stage. Thanks in advance, ilhan [1] : https://github.com/scipy/scipy/pull/12824 [2] : https://nl.mathworks.com/help/matlab/ref/mldivide.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Sep 8 18:09:50 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 08 Sep 2020 17:09:50 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Today - Triage Focus Message-ID: <73f110eeae0da7fd3eb119ce4fe7be5dcf0f431a.camel@sipsolutions.net> Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, September 9th) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized or simply discussed briefly. Just comment on it so we can label it, or add your PR/issue to this weeks topics for discussion. Best regards Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From mikofski at berkeley.edu Wed Sep 9 00:20:00 2020 From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD) Date: Tue, 8 Sep 2020 21:20:00 -0700 Subject: [Numpy-discussion] ANN: pvlib-0.8.0 python package for solar energy modeling Message-ID: Dear Pythonistas and Solar Energy enthusiasts, I am very happy to announce a new, major release of pvlib python, for simulating the performance of photovoltaic solar energy systems. *See what's new for v0.8.0:* * https://pvlib-python.readthedocs.io/en/stable/whatsnew.html *Releases are available from the CheeseShop and the conda-forge channel:* * https://pypi.org/project/pvlib/ * https://anaconda.org/conda-forge/pvlib-python *Read the Documentation:* * https://pvlib-python.readthedocs.io/en/stable/index.html *Report issues & contribute:* * https://github.com/pvlib/pvlib-python *Highlights:* * Because this is a major release, there are many breaking changes so please read through the release notes carefully before updating * Python-3.5 is no longer supported, SciPy-1.2.0 is now a required dependency, and the Pandas minimum version is now v0.22.0 * New functions for calculation of sky-diffuse irradiance, fitting PV module IV-curve traces to single-diode model coefficients, and accommodating terrain slope when backtracking. * Many new contributors, bug fixes, and improvements in the documentation. * Also coming soon, AirSpeed Velocity benchmarks. Stay tuned! *The development team thanks you for using pvlib python!* -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Thu Sep 10 13:42:44 2020 From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD) Date: Thu, 10 Sep 2020 10:42:44 -0700 Subject: [Numpy-discussion] number datetime64 dtypes Message-ID: Hi, Thank you for your time. A colleague asked me about creating a range of numpy datetime64 at 15-day increments. This works: np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), np.timedelta64(15, 'D')) but then they also showed me this, which leads to some very strange responses: np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), dtype="datetime64[15D]") Out[50]: array(['2008-03-27', '2008-04-11', '2008-04-26', '2008-05-11', '2008-05-26', '2008-06-10', '2008-06-25', '2008-07-10', ... '2020-05-23', '2020-06-07', '2020-06-22', '2020-07-07', '2020-07-22', '2020-08-06'], dtype='datetime64[15D]') See how the 1st day is March 27th? I couldn't find a reference to this dtype ( "datetime64[15D]" ) in the numpy docs, but I think it's a common pattern in Pandas, that is using a number to get an increment of the frequency, for example "5T" is 5-minutes, etc. There is a reference to using arange with dtype on the datetimes & timedelta doc page () but the datetime is 1-day or "datetime64[D]" Is this the intended outcome? Or is it a side effect? I wonder if others have tried to adapt Pandas patterns to Numpy datetimes, and if it's an issue for anyone else. I've advised my colleague not to use Numpy datetimes like this, assuming based on the docs that Pandas-style offsets do not translate into Numpy style datetimes. thanks! -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From wieser.eric+numpy at gmail.com Thu Sep 10 14:03:03 2020 From: wieser.eric+numpy at gmail.com (Eric Wieser) Date: Thu, 10 Sep 2020 19:03:03 +0100 Subject: [Numpy-discussion] number datetime64 dtypes In-Reply-To: References: Message-ID: It's interesting to confirm that people are aware of this syntax! This is intended but perhaps not useful behavior. `datetime64[15D]` is a type that stores dates by the nearest date that is a multiple of 15 days from the unix epoch. Arguably there isn't a situation where using `15D` makes a whole lot of sense, but the generalization is useful - `datetime64[15m]` stores dates rounded to the nearest quarter hour, which is somewhat sensible. Perhaps we should have added support for a custom epoch, which would make your problem go away... On Thu, 10 Sep 2020 at 18:43, Dr. Mark Alexander Mikofski PhD < mikofski at berkeley.edu> wrote: > Hi, > > Thank you for your time. > > A colleague asked me about creating a range of numpy datetime64 at 15-day > increments. > > This works: > > np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), np.timedelta64(15, 'D')) > > but then they also showed me this, which leads to some very strange > responses: > > np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), > dtype="datetime64[15D]") > Out[50]: > array(['2008-03-27', '2008-04-11', '2008-04-26', '2008-05-11', > '2008-05-26', '2008-06-10', '2008-06-25', '2008-07-10', > ... > '2020-05-23', '2020-06-07', '2020-06-22', '2020-07-07', > '2020-07-22', '2020-08-06'], dtype='datetime64[15D]') > > See how the 1st day is March 27th? > > I couldn't find a reference to this dtype ( "datetime64[15D]" ) in the > numpy docs, but I think it's a common pattern in Pandas, that is using a > number to get an increment of the frequency, for example "5T" is 5-minutes, > etc. > > There is a reference to using arange with dtype on the datetimes & > timedelta doc page () but the datetime is 1-day or "datetime64[D]" > > Is this the intended outcome? Or is it a side effect? > > I wonder if others have tried to adapt Pandas patterns to Numpy datetimes, > and if it's an issue for anyone else. > > I've advised my colleague not to use Numpy datetimes like this, assuming > based on the docs that Pandas-style offsets do not translate into Numpy > style datetimes. > > thanks! > > -- > Mark Mikofski, PhD (2005) > *Fiat Lux* > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Thu Sep 10 14:26:10 2020 From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD) Date: Thu, 10 Sep 2020 11:26:10 -0700 Subject: [Numpy-discussion] number datetime64 dtypes In-Reply-To: References: Message-ID: Hi Eric, Thank you so much for your answer! That explains this interesting behavior: >>> [np.datetime64('2008-04-01', f'{x}D') for x in range(1, 16)] [numpy.datetime64('2008-04-01'), numpy.datetime64('2008-04-01','2D'), numpy.datetime64('2008-03-30','3D'), numpy.datetime64('2008-03-30','4D'), numpy.datetime64('2008-04-01','5D'), numpy.datetime64('2008-03-30','6D'), numpy.datetime64('2008-03-27','7D'), numpy.datetime64('2008-03-30','8D'), numpy.datetime64('2008-03-30','9D'), numpy.datetime64('2008-04-01','10D'), numpy.datetime64('2008-04-01','11D'), numpy.datetime64('2008-03-30','12D'), numpy.datetime64('2008-03-24','13D'), numpy.datetime64('2008-03-20','14D'), numpy.datetime64('2008-03-27','15D')] Is there something to be done? Perhaps a change to the documentation? I'm willing to open a PR with your notes from this thread. Thanks! On Thu, Sep 10, 2020 at 11:04 AM Eric Wieser wrote: > It's interesting to confirm that people are aware of this syntax! > > This is intended but perhaps not useful behavior. > > `datetime64[15D]` is a type that stores dates by the nearest date that is > a multiple of 15 days from the unix epoch. > Arguably there isn't a situation where using `15D` makes a whole lot of > sense, but the generalization is useful - `datetime64[15m]` stores dates > rounded to the nearest quarter hour, which is somewhat sensible. > > Perhaps we should have added support for a custom epoch, which would make > your problem go away... > > On Thu, 10 Sep 2020 at 18:43, Dr. Mark Alexander Mikofski PhD < > mikofski at berkeley.edu> wrote: > >> Hi, >> >> Thank you for your time. >> >> A colleague asked me about creating a range of numpy datetime64 at 15-day >> increments. >> >> This works: >> >> np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), np.timedelta64(15, 'D')) >> >> but then they also showed me this, which leads to some very strange >> responses: >> >> np.arange(np.datetime64('2008-04-01'), np.datetime64('2020-09-01'), >> dtype="datetime64[15D]") >> Out[50]: >> array(['2008-03-27', '2008-04-11', '2008-04-26', '2008-05-11', >> '2008-05-26', '2008-06-10', '2008-06-25', '2008-07-10', >> ... >> '2020-05-23', '2020-06-07', '2020-06-22', '2020-07-07', >> '2020-07-22', '2020-08-06'], dtype='datetime64[15D]') >> >> See how the 1st day is March 27th? >> >> I couldn't find a reference to this dtype ( "datetime64[15D]" ) in the >> numpy docs, but I think it's a common pattern in Pandas, that is using a >> number to get an increment of the frequency, for example "5T" is 5-minutes, >> etc. >> >> There is a reference to using arange with dtype on the datetimes & >> timedelta doc page () but the datetime is 1-day or "datetime64[D]" >> >> Is this the intended outcome? Or is it a side effect? >> >> I wonder if others have tried to adapt Pandas patterns to Numpy >> datetimes, and if it's an issue for anyone else. >> >> I've advised my colleague not to use Numpy datetimes like this, assuming >> based on the docs that Pandas-style offsets do not translate into Numpy >> style datetimes. >> >> thanks! >> >> -- >> Mark Mikofski, PhD (2005) >> *Fiat Lux* >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- Mark Mikofski, PhD (2005) *Fiat Lux* -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Thu Sep 10 14:40:27 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 10 Sep 2020 12:40:27 -0600 Subject: [Numpy-discussion] NumPy 1.19.2 released Message-ID: Hi All, On behalf of the NumPy team I am pleased to announce that NumPy 1.19.2 has been released. This release fixes several bugs, prepares for the upcoming Cython 3.x release. and pins setuptools to keep distutils working while upstream modifications are ongoing. The aarch64 wheels are built with the latest manylinux2014 release that fixes the problem of differing page sizes used by different Linux distros. There is a known problem with Windows 10 version=2004 and OpenBLAS svd that we are trying to debug. If you are running that Windows version you should use a NumPy version that links to the MKL library, earlier Windows versions are fine. This release supports Python 3.6-3.8. Downstream developers should use Cython >= 0.29.21 when building for Python 3.9 and Cython >= 0.29.16 when building for Python 3.8. OpenBLAS >= 3.7 is needed to avoid wrong results on the Skylake architecture. The NumPy Wheels for this release can be downloaded from PyPI , source archives, release notes, and wheel hashes are available from Github . Linux users will need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014 wheels. *Contributors* A total of 8 people contributed to this release. People with a "+" by their names contributed a patch for the first time. - Charles Harris - Matti Picus - Pauli Virtanen - Philippe Ombredanne + - Sebastian Berg - Stefan Behnel + - Stephan Loyd + - Zac Hatfield-Dodds *Pull requests merged* A total of 9 pull requests were merged for this release. - #16959: TST: Change aarch64 to arm64 in travis.yml. - #16998: MAINT: Configure hypothesis in ``np.test()`` for determinism,... - #17000: BLD: pin setuptools < 49.2.0 - #17015: ENH: Add NumPy declarations to be used by Cython 3.0+ - #17125: BUG: Remove non-threadsafe sigint handling from fft calculation - #17243: BUG: core: fix ilp64 blas dot/vdot/... for strides > int32 max - #17244: DOC: Use SPDX license expressions with correct license - #17245: DOC: Fix the link to the quick-start in the old API functions - #17272: BUG: fix pickling of arrays larger than 2GiB Cheers, Charles Harris -------------- next part -------------- An HTML attachment was scrubbed... URL: From charlesr.harris at gmail.com Thu Sep 10 17:24:14 2020 From: charlesr.harris at gmail.com (Charles R Harris) Date: Thu, 10 Sep 2020 15:24:14 -0600 Subject: [Numpy-discussion] Numpy wheels with Python 3.9 support. Message-ID: Hi All, There are numpy pre-wheels for Python 3.9 available on the x86_64, i686, and aarch64 platforms. They use manylinux2010 and manylinux2014, so you need a recent pip to get them. Chuck -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Fri Sep 11 15:42:01 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Fri, 11 Sep 2020 16:42:01 -0300 Subject: [Numpy-discussion] Fwd: Documentation Team meeting - Monday August 31 In-Reply-To: References: Message-ID: Hi all! This is a reminder that our next Documentation Team meeting will be on *Monday, September 14* at 3PM UTC**. This meeting marks the beginning of the Google Season of Docs documentation development phase, so in addition to general documentation discussions, we'll discuss the projects and next actions for the technical writers involved. If you wish to join on Zoom, you need to use this link https://zoom.us/j/420005230 Here's the permanent hackmd document with the meeting notes (still being updated in the next few days!): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documenation+Team+Meeting&iso=20200914T15&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Tue Sep 15 15:52:14 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 15 Sep 2020 14:52:14 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday Message-ID: Hi all, There will be a NumPy Community meeting Wednesday September 16th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From ralf.gommers at gmail.com Wed Sep 16 13:53:34 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Wed, 16 Sep 2020 18:53:34 +0100 Subject: [Numpy-discussion] the NumPy paper is out! Message-ID: Hi all, Nature published our first official paper: https://www.nature.com/articles/s41586-020-2649-2 And here is the Twitter announcement: https://twitter.com/numpy_team/status/1306268442450972674 Thanks to everyone who contributed to this milestone! A few special mentions: Chuck, for many years of tireless labour keeping our code base in good shape, and being the top committer on the NumPy project by now with more than twice the commits (says `git shortlog -sn`) as the number two committer. This is why Chuck is the first author on the paper. Travis, for creating NumPy. This is why Travis is the last author on the paper, as our "elder statesman". Jarrod and St?fan, for spending a ton of time on making this the best possible paper we could possibly produce on NumPy. Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From faltet at gmail.com Wed Sep 16 15:49:52 2020 From: faltet at gmail.com (Francesc Alted) Date: Wed, 16 Sep 2020 21:49:52 +0200 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Very well written article! Congratulations everybody, most specially Travis and Chuck for their outstanding work! El dc., 16 set. 2020, 19.54, Ralf Gommers va escriure: > Hi all, > > Nature published our first official paper: > https://www.nature.com/articles/s41586-020-2649-2 > > And here is the Twitter announcement: > https://twitter.com/numpy_team/status/1306268442450972674 > > Thanks to everyone who contributed to this milestone! A few special > mentions: > > Chuck, for many years of tireless labour keeping our code base in good > shape, and being the top committer on the NumPy project by now with more > than twice the commits (says `git shortlog -sn`) as the number two > committer. This is why Chuck is the first author on the paper. > > Travis, for creating NumPy. This is why Travis is the last author on the > paper, as our "elder statesman". > > Jarrod and St?fan, for spending a ton of time on making this the best > possible paper we could possibly produce on NumPy. > > Cheers, > Ralf > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fbastien at nvidia.com Wed Sep 16 15:54:11 2020 From: fbastien at nvidia.com (Frederic Bastien) Date: Wed, 16 Sep 2020 19:54:11 +0000 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Congratulations everybody! From: NumPy-Discussion On Behalf Of Francesc Alted Sent: Wednesday, September 16, 2020 3:50 PM To: Discussion of Numerical Python Subject: Re: [Numpy-discussion] the NumPy paper is out! External email: Use caution opening links or attachments Very well written article! Congratulations everybody, most specially Travis and Chuck for their outstanding work! El dc., 16 set. 2020, 19.54, Ralf Gommers > va escriure: Hi all, Nature published our first official paper: https://www.nature.com/articles/s41586-020-2649-2 And here is the Twitter announcement: https://twitter.com/numpy_team/status/1306268442450972674 Thanks to everyone who contributed to this milestone! A few special mentions: Chuck, for many years of tireless labour keeping our code base in good shape, and being the top committer on the NumPy project by now with more than twice the commits (says `git shortlog -sn`) as the number two committer. This is why Chuck is the first author on the paper. Travis, for creating NumPy. This is why Travis is the last author on the paper, as our "elder statesman". Jarrod and St?fan, for spending a ton of time on making this the best possible paper we could possibly produce on NumPy. Cheers, Ralf _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion at python.org https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From valerio.maggio at gmail.com Wed Sep 16 16:08:39 2020 From: valerio.maggio at gmail.com (Valerio Maggio) Date: Wed, 16 Sep 2020 21:08:39 +0100 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Congratulations everyone! The paper is very well written, wonderfully organised, and something we should all be proud of. I am super happy that NumPy has finally its own (Nature!) paper: truly deserved for all the community effort, and for the key central role NumPy now has for all the ecosystem. Thank you! Valerio On Wed, Sep 16, 2020 at 9:00 PM Frederic Bastien wrote: > Congratulations everybody! > > > > *From:* NumPy-Discussion nvidia.com at python.org> *On Behalf Of *Francesc Alted > *Sent:* Wednesday, September 16, 2020 3:50 PM > *To:* Discussion of Numerical Python > *Subject:* Re: [Numpy-discussion] the NumPy paper is out! > > > > *External email: Use caution opening links or attachments* > > > > Very well written article! Congratulations everybody, most specially > Travis and Chuck for their outstanding work! > > > > El dc., 16 set. 2020, 19.54, Ralf Gommers va > escriure: > > Hi all, > > > > Nature published our first official paper: > https://www.nature.com/articles/s41586-020-2649-2 > > > > And here is the Twitter announcement: > https://twitter.com/numpy_team/status/1306268442450972674 > > > > Thanks to everyone who contributed to this milestone! A few special > mentions: > > > > Chuck, for many years of tireless labour keeping our code base in good > shape, and being the top committer on the NumPy project by now with more > than twice the commits (says `git shortlog -sn`) as the number two > committer. This is why Chuck is the first author on the paper. > > > > Travis, for creating NumPy. This is why Travis is the last author on the > paper, as our "elder statesman". > > > > Jarrod and St?fan, for spending a ton of time on making this the best > possible paper we could possibly produce on NumPy. > > > > Cheers, > > Ralf > > > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -- # valerio -------------- next part -------------- An HTML attachment was scrubbed... URL: From andy.terrel at gmail.com Wed Sep 16 16:34:40 2020 From: andy.terrel at gmail.com (Andy Ray Terrel) Date: Wed, 16 Sep 2020 15:34:40 -0500 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: This is awesome. Congratulations to the team! On Wed, Sep 16, 2020 at 3:09 PM Valerio Maggio wrote: > Congratulations everyone! > The paper is very well written, wonderfully organised, and something we > should all be proud of. > > I am super happy that NumPy has finally its own (Nature!) paper: truly > deserved for all the community effort, and for the key central role NumPy > now has for all the ecosystem. > > Thank you! > > Valerio > > On Wed, Sep 16, 2020 at 9:00 PM Frederic Bastien > wrote: > >> Congratulations everybody! >> >> >> >> *From:* NumPy-Discussion > nvidia.com at python.org> *On Behalf Of *Francesc Alted >> *Sent:* Wednesday, September 16, 2020 3:50 PM >> *To:* Discussion of Numerical Python >> *Subject:* Re: [Numpy-discussion] the NumPy paper is out! >> >> >> >> *External email: Use caution opening links or attachments* >> >> >> >> Very well written article! Congratulations everybody, most specially >> Travis and Chuck for their outstanding work! >> >> >> >> El dc., 16 set. 2020, 19.54, Ralf Gommers va >> escriure: >> >> Hi all, >> >> >> >> Nature published our first official paper: >> https://www.nature.com/articles/s41586-020-2649-2 >> >> >> >> And here is the Twitter announcement: >> https://twitter.com/numpy_team/status/1306268442450972674 >> >> >> >> Thanks to everyone who contributed to this milestone! A few special >> mentions: >> >> >> >> Chuck, for many years of tireless labour keeping our code base in good >> shape, and being the top committer on the NumPy project by now with more >> than twice the commits (says `git shortlog -sn`) as the number two >> committer. This is why Chuck is the first author on the paper. >> >> >> >> Travis, for creating NumPy. This is why Travis is the last author on the >> paper, as our "elder statesman". >> >> >> >> Jarrod and St?fan, for spending a ton of time on making this the best >> possible paper we could possibly produce on NumPy. >> >> >> >> Cheers, >> >> Ralf >> >> >> >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > > -- > # valerio > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikofski at berkeley.edu Wed Sep 16 16:44:47 2020 From: mikofski at berkeley.edu (Dr. Mark Alexander Mikofski PhD) Date: Wed, 16 Sep 2020 13:44:47 -0700 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Congratulations & thank you! On Wed, Sep 16, 2020, 1:36 PM Andy Ray Terrel wrote: > This is awesome. Congratulations to the team! > > On Wed, Sep 16, 2020 at 3:09 PM Valerio Maggio > wrote: > >> Congratulations everyone! >> The paper is very well written, wonderfully organised, and something we >> should all be proud of. >> >> I am super happy that NumPy has finally its own (Nature!) paper: truly >> deserved for all the community effort, and for the key central role NumPy >> now has for all the ecosystem. >> >> Thank you! >> >> Valerio >> >> On Wed, Sep 16, 2020 at 9:00 PM Frederic Bastien >> wrote: >> >>> Congratulations everybody! >>> >>> >>> >>> *From:* NumPy-Discussion >> nvidia.com at python.org> *On Behalf Of *Francesc Alted >>> *Sent:* Wednesday, September 16, 2020 3:50 PM >>> *To:* Discussion of Numerical Python >>> *Subject:* Re: [Numpy-discussion] the NumPy paper is out! >>> >>> >>> >>> *External email: Use caution opening links or attachments* >>> >>> >>> >>> Very well written article! Congratulations everybody, most specially >>> Travis and Chuck for their outstanding work! >>> >>> >>> >>> El dc., 16 set. 2020, 19.54, Ralf Gommers va >>> escriure: >>> >>> Hi all, >>> >>> >>> >>> Nature published our first official paper: >>> https://www.nature.com/articles/s41586-020-2649-2 >>> >>> >>> >>> And here is the Twitter announcement: >>> https://twitter.com/numpy_team/status/1306268442450972674 >>> >>> >>> >>> Thanks to everyone who contributed to this milestone! A few special >>> mentions: >>> >>> >>> >>> Chuck, for many years of tireless labour keeping our code base in good >>> shape, and being the top committer on the NumPy project by now with more >>> than twice the commits (says `git shortlog -sn`) as the number two >>> committer. This is why Chuck is the first author on the paper. >>> >>> >>> >>> Travis, for creating NumPy. This is why Travis is the last author on the >>> paper, as our "elder statesman". >>> >>> >>> >>> Jarrod and St?fan, for spending a ton of time on making this the best >>> possible paper we could possibly produce on NumPy. >>> >>> >>> >>> Cheers, >>> >>> Ralf >>> >>> >>> >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion at python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >> >> >> -- >> # valerio >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From evgeny.burovskiy at gmail.com Thu Sep 17 03:35:52 2020 From: evgeny.burovskiy at gmail.com (Evgeni Burovski) Date: Thu, 17 Sep 2020 10:35:52 +0300 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Congratulations! On Wed, Sep 16, 2020 at 8:54 PM Ralf Gommers wrote: > > Hi all, > > Nature published our first official paper: https://www.nature.com/articles/s41586-020-2649-2 > > And here is the Twitter announcement: https://twitter.com/numpy_team/status/1306268442450972674 > > Thanks to everyone who contributed to this milestone! A few special mentions: > > Chuck, for many years of tireless labour keeping our code base in good shape, and being the top committer on the NumPy project by now with more than twice the commits (says `git shortlog -sn`) as the number two committer. This is why Chuck is the first author on the paper. > > Travis, for creating NumPy. This is why Travis is the last author on the paper, as our "elder statesman". > > Jarrod and St?fan, for spending a ton of time on making this the best possible paper we could possibly produce on NumPy. > > Cheers, > Ralf > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion From derek at astro.physik.uni-goettingen.de Thu Sep 17 17:43:08 2020 From: derek at astro.physik.uni-goettingen.de (Derek Homeier) Date: Thu, 17 Sep 2020 23:43:08 +0200 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: I did not want to put any more load on the list, but let me just report that this news has got 177 likes within 24 hours in the Python users in Astronomy Facebook group, which I think sets a new record (not the 10 k likes on Twitter, but that?s a different audience ;-). Congratulations everyone again! Derek > On 16 Sep 2020, at 7:53 pm, Ralf Gommers wrote: > > Nature published our first official paper: https://www.nature.com/articles/s41586-020-2649-2 > > And here is the Twitter announcement: https://twitter.com/numpy_team/status/1306268442450972674 > > Thanks to everyone who contributed to this milestone! A few special mentions: > > Chuck, for many years of tireless labour keeping our code base in good shape, and being the top committer on the NumPy project by now with more than twice the commits (says `git shortlog -sn`) as the number two committer. This is why Chuck is the first author on the paper. > > Travis, for creating NumPy. This is why Travis is the last author on the paper, as our "elder statesman". > > Jarrod and St?fan, for spending a ton of time on making this the best possible paper we could possibly produce on NumPy. > From mark.harfouche at gmail.com Thu Sep 17 21:44:04 2020 From: mark.harfouche at gmail.com (Mark Harfouche) Date: Thu, 17 Sep 2020 21:44:04 -0400 Subject: [Numpy-discussion] the NumPy paper is out! In-Reply-To: References: Message-ID: Great work all! It got to the top of new.ycombinator.com ;) On Thu, Sep 17, 2020 at 6:35 PM Derek Homeier < derek at astro.physik.uni-goettingen.de> wrote: > I did not want to put any more load on the list, but let me just report > that this news has got > 177 likes within 24 hours in the Python users in Astronomy Facebook group, > which I think > sets a new record (not the 10 k likes on Twitter, but that?s a different > audience ;-). > > Congratulations everyone again! > > Derek > > > On 16 Sep 2020, at 7:53 pm, Ralf Gommers wrote: > > > > Nature published our first official paper: > https://www.nature.com/articles/s41586-020-2649-2 > > > > And here is the Twitter announcement: > https://twitter.com/numpy_team/status/1306268442450972674 > > > > Thanks to everyone who contributed to this milestone! A few special > mentions: > > > > Chuck, for many years of tireless labour keeping our code base in good > shape, and being the top committer on the NumPy project by now with more > than twice the commits (says `git shortlog -sn`) as the number two > committer. This is why Chuck is the first author on the paper. > > > > Travis, for creating NumPy. This is why Travis is the last author on the > paper, as our "elder statesman". > > > > Jarrod and St?fan, for spending a ton of time on making this the best > possible paper we could possibly produce on NumPy. > > > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.johnston.100 at gmail.com Mon Sep 21 13:49:15 2020 From: lee.johnston.100 at gmail.com (Lee Johnston) Date: Mon, 21 Sep 2020 12:49:15 -0500 Subject: [Numpy-discussion] PR 14700 Message-ID: Hi, PR 14700 that adds datetime64 and timedelta64 support to linspace has not been worked on since December 2019. I would like this feature sooner rather than never and have implemented the support and all recommended tests in my fork. Is there interest in supporting this feature and should I submit my PR? Lee -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Mon Sep 21 18:10:09 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Mon, 21 Sep 2020 17:10:09 -0500 Subject: [Numpy-discussion] PR 14700 In-Reply-To: References: Message-ID: <453951ec94b995c20bb14f052236751dd79d11c4.camel@sipsolutions.net> On Mon, 2020-09-21 at 12:49 -0500, Lee Johnston wrote: > Hi, PR 14700 that adds > datetime64 and timedelta64 support to linspace has not been worked on > since > December 2019. I would like this feature sooner rather than never and > have > implemented the support and all recommended tests in my fork. Is > there > interest in supporting this feature and should I submit my PR? > Definitely, it was a good start and idea. I don't remember the exact reason it stalled. I think there were issues around the step size and/or NaT handling. And a quick look over the discussion, those were real issues for ensuring the correct, expected, results. But, it may be that they were not big issues. Either, because we can live with a non-perfect solution, or because there is a solution that was simply never finalized. A PR is welcome! If you have the time, it may help to summarize the potential issues/solutions on the list so that it is easier to make a decision. It might also help to have a few more users involved who use datetimes more actively. I do not use them very often. Cheers, Sebastian > Lee > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From jni at fastmail.com Mon Sep 21 21:42:11 2020 From: jni at fastmail.com (Juan Nunez-Iglesias) Date: Tue, 22 Sep 2020 11:42:11 +1000 Subject: [Numpy-discussion] Sprint leaders wanted for SciPy Japan Message-ID: Hi NumPythonistas, and apologies cross-posting. I am sprints chair for the upcoming SciPy Japan virtual conference [1]. It?s running Oct 30-31 (main conference) and Nov 1-2 (sprints). This is the second SciPy Japan conference and the first with sprints. The sprints officially run from 9am to 5pm Tokyo time, which corresponds to 11am-7pm Australia Eastern time and 4pm-midnight Sat-Sun USA West Coast. (I won?t bother with the Europe time. ?) We currently have sprints confirmed for CuPy, dask-image, Apache Arrow, scikit-image, Sphinx, and napari. I?ve asked the scikit-learn team if they would like to lead a sprint, and would like to ask the same for NumPy and SciPy devs. (I won?t cross post to SciPy due to large overlap ? please help me spread the word!) If anyone from the core teams is willing to lead a sprint on those dates, please let me know! Thank you, Juan. [1]: https://www.scipyjapan.scipy.org From sebastian at sipsolutions.net Tue Sep 22 15:17:51 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 22 Sep 2020 14:17:51 -0500 Subject: [Numpy-discussion] NumPy Development Meeting Today - Triage Focus Message-ID: Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, September 9th) at 11 am Pacific Time (18:00 UTC). Everyone is invited to join in and edit the work-in-progress meeting topics and notes: https://hackmd.io/68i_JvOYQfy9ERiHgXMPvg I encourage everyone to notify us of issues or PRs that you feel should be prioritized or simply discussed briefly. Just comment on it so we can label it, or add your PR/issue to this weeks topics for discussion. Best regards Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From stefano.borini at gmail.com Wed Sep 23 17:22:01 2020 From: stefano.borini at gmail.com (Stefano Borini) Date: Wed, 23 Sep 2020 22:22:01 +0100 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments Message-ID: Dear all, I would like to know your opinion on how to address a specific need of the new PEP 637: https://github.com/python/peps/blob/master/pep-0637.txt Such PEP would make a syntax like the following valid obj[2, x=23] obj[2, 4, x=23] Which would resolve to a call in the form type(obj).__getitem__(obj, 2, x=23) type(obj).__getitem__(obj, (2, 4), x=23) and similar for set and del. After discussion, we currently have one open point we are unsure how to address, that is what to pass when no positional index is passed, that is: obj[x=23] We are unsure if we should resolve this call with None or the empty tuple in the positional index: type(obj).__getitem__(obj, None, x=23) type(obj).__getitem__(obj, (), x=23) You can see a detailed discussion in the PEP at L913 https://github.com/python/peps/blob/1fb19ac3a57c9793669ea9532fb840861d4d7566/pep-0637.txt#L913 One of the commenters on python-ideas reported that using None might introduce an issue in numpy, as None is used to create new axes, hence the proposal for rejection of None as a solution. However, we are unsure how strongly this would affect numpy and similar packages, as well as what developer will find more natural to receive in that case. We would like to hear your opinion on the topic. Thank you for your help. -- Kind regards, Stefano Borini From shoyer at gmail.com Thu Sep 24 00:41:33 2020 From: shoyer at gmail.com (Stephan Hoyer) Date: Wed, 23 Sep 2020 21:41:33 -0700 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments In-Reply-To: References: Message-ID: On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini wrote: > Dear all, > > > > > > I would like to know your opinion on how to address a specific need of > > > the new PEP 637: > > > > > > https://github.com/python/peps/blob/master/pep-0637.txt > > > > > > Such PEP would make a syntax like the following valid > > > > > > obj[2, x=23] > > > obj[2, 4, x=23] > > > > > > Which would resolve to a call in the form > > > > > > type(obj).__getitem__(obj, 2, x=23) > > > type(obj).__getitem__(obj, (2, 4), x=23) > > > > > > and similar for set and del. > > > After discussion, we currently have one open point we are unsure how > > > to address, that is what to pass when no positional index is passed, > > > that is: > > > > > > obj[x=23] > > > > > > We are unsure if we should resolve this call with None or the empty > > > tuple in the positional index: > > > > > > type(obj).__getitem__(obj, None, x=23) > > > type(obj).__getitem__(obj, (), x=23) > > > > Hi Stefano -- thanks for pushing this proposal forward! I am sure that support for keyword indexing will be very welcome in the scientific Python ecosystem. I have not been following the full discussion on PEP 637, but I recall seeing another suggestion earlier for what this could be resolved into: type(obj).__getitem__(obj, x=23) I.e., not passing a positional argument at all. The author of a class that supports keyword indexing could check this sort of case with a positional only argument with a default value, e.g., def __getitem__(self, key=MY_SENTINEL, /, **kwargs): where MY_SENTINEL could be any desired sentinel value, including either None or (). Is there a reason for rejecting this option? It seems like a nice explicit alternative to prespecifing the choice of sentinel value. I guess the concern might be that this would not suffice for __setitem__? > > > You can see a detailed discussion in the PEP at L913 > > > > > > > https://github.com/python/peps/blob/1fb19ac3a57c9793669ea9532fb840861d4d7566/pep-0637.txt#L913 > > > > > > One of the commenters on python-ideas reported that using None might > > > introduce an issue in numpy, as None is used to create new axes, hence > > > the proposal for rejection of None as a solution. > > > However, we are unsure how strongly this would affect numpy and > > > similar packages, as well as what developer will find more natural to > > > receive in that case. We would like to hear your opinion on the topic. > I guess the case this would disallow is distinguishing between obj[None, x=23] and obj[x=23]? Yes, this could be a little awkward potentially. The tuple would definitely be more natural for NumPy users, given the that first step of __getitem__/__setitem__ methods in the broader NumPy ecosystem is typically packing non-tuple keys into a tuple, e.g., def __getitem__(self, key): if not isinstance(key, tuple): key = (key,) ... That said: - NumPy itself is unlikely to support keyword indexing anytime soon. - New packages could encourage using explicit aliases like "np.newaxis" instead of "None", which in general is a best practice already. - The combined use of keyword indexing *and* insertion of new axes at the same time strikes me as something that would be unusual in practice. From what I've seen, it is most useful to either use entirely unnamed or entirely named axes. In the later case, I might write something like obj[x=None] to indicate inserting a new dimension with the name "x". I think we could definitely live with it either way. I would lean towards using an empty tuple, but I agree that it feels a little uglier than using None (though perhaps not surprising, given the already ugly special cases for tuples in the indexing protocol). Best, Stephan -------------- next part -------------- An HTML attachment was scrubbed... URL: From sebastian at sipsolutions.net Thu Sep 24 15:43:24 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Thu, 24 Sep 2020 14:43:24 -0500 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments In-Reply-To: References: Message-ID: <23d862330d1fdf2695db332973c4ff15506e2d23.camel@sipsolutions.net> On Wed, 2020-09-23 at 21:41 -0700, Stephan Hoyer wrote: > On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini < > stefano.borini at gmail.com> > wrote: > > > Hi Stefano -- thanks for pushing this proposal forward! I am sure > that > support for keyword indexing will be very welcome in the scientific > Python > ecosystem. > > I have not been following the full discussion on PEP 637, but I > recall > seeing another suggestion earlier for what this could be resolved > into: > > type(obj).__getitem__(obj, x=23) > > I.e., not passing a positional argument at all. > > The author of a class that supports keyword indexing could check this > sort > of case with a positional only argument with a default value, e.g., > > def __getitem__(self, key=MY_SENTINEL, /, **kwargs): > > where MY_SENTINEL could be any desired sentinel value, including > either > None or (). Is there a reason for rejecting this option? It seems > like a > nice explicit alternative to prespecifing the choice of sentinel > value. > > I guess the concern might be that this would not suffice for > __setitem__? > > > > > > You can see a detailed discussion in the PEP at L913 > I guess the case this would disallow is distinguishing between > obj[None, > x=23] and obj[x=23]? > > Yes, this could be a little awkward potentially. The tuple would > definitely > be more natural for NumPy users, given the that first step of > __getitem__/__setitem__ methods in the broader NumPy ecosystem is > typically > packing non-tuple keys into a tuple, e.g., > > def __getitem__(self, key): > if not isinstance(key, tuple): > key = (key,) > ... > > That said: > - NumPy itself is unlikely to support keyword indexing anytime soon. > - New packages could encourage using explicit aliases like > "np.newaxis" > instead of "None", which in general is a best practice already. > - The combined use of keyword indexing *and* insertion of new axes at > the > same time strikes me as something that would be unusual in practice. > From > what I've seen, it is most useful to either use entirely unnamed or > entirely named axes. In the later case, I might write something like > obj[x=None] to indicate inserting a new dimension with the name "x". > Just to briefly second these points and the general support thanks for the hard work! I do also wonder about the `key=custom_default` solution, or whether there may be other option to address this. For NumPy, I do hope we can play with the idea of adding support if this PEP lands. But agree that labeled axes in NumPy is unlikely to be on the immediate horizon, and I am not sure how feasible it is. My main in the discussion on python-ideas was `arr[]` doing something unexpected, but it was long decided that it will remain a SyntaxError. For the question at hand, it seems to me that mixing labeled and unlabeled indexing would be an error for array-like objects. In that case, the worst we get seems a quirk where `arr[None, x=4]` is not an error, when it should be an error. That does not really strike me as a blocker. I am not a fan of such quirks. But some trade-off seems unavoidable considering the backward compatibility constraints and differences between array-likes and typing use of `__getitem__`. - Sebastian > I think we could definitely live with it either way. I would lean > towards > using an empty tuple, but I agree that it feels a little uglier than > using > None (though perhaps not surprising, given the already ugly special > cases > for tuples in the indexing protocol). > > Best, > Stephan > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From asmeurer at gmail.com Thu Sep 24 17:21:30 2020 From: asmeurer at gmail.com (Aaron Meurer) Date: Thu, 24 Sep 2020 15:21:30 -0600 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments In-Reply-To: <23d862330d1fdf2695db332973c4ff15506e2d23.camel@sipsolutions.net> References: <23d862330d1fdf2695db332973c4ff15506e2d23.camel@sipsolutions.net> Message-ID: This PEP also opens the possibility of allowing a[] with nothing in the getitem. Has that been considered? Aaron Meurer On Thu, Sep 24, 2020 at 1:48 PM Sebastian Berg wrote: > On Wed, 2020-09-23 at 21:41 -0700, Stephan Hoyer wrote: > > On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini < > > stefano.borini at gmail.com> > > wrote: > > > > > > > > Hi Stefano -- thanks for pushing this proposal forward! I am sure > > that > > support for keyword indexing will be very welcome in the scientific > > Python > > ecosystem. > > > > I have not been following the full discussion on PEP 637, but I > > recall > > seeing another suggestion earlier for what this could be resolved > > into: > > > > type(obj).__getitem__(obj, x=23) > > > > I.e., not passing a positional argument at all. > > > > The author of a class that supports keyword indexing could check this > > sort > > of case with a positional only argument with a default value, e.g., > > > > def __getitem__(self, key=MY_SENTINEL, /, **kwargs): > > > > where MY_SENTINEL could be any desired sentinel value, including > > either > > None or (). Is there a reason for rejecting this option? It seems > > like a > > nice explicit alternative to prespecifing the choice of sentinel > > value. > > > > I guess the concern might be that this would not suffice for > > __setitem__? > > > > > > > > > > You can see a detailed discussion in the PEP at L913 > > > > > I guess the case this would disallow is distinguishing between > > obj[None, > > x=23] and obj[x=23]? > > > > Yes, this could be a little awkward potentially. The tuple would > > definitely > > be more natural for NumPy users, given the that first step of > > __getitem__/__setitem__ methods in the broader NumPy ecosystem is > > typically > > packing non-tuple keys into a tuple, e.g., > > > > def __getitem__(self, key): > > if not isinstance(key, tuple): > > key = (key,) > > ... > > > > That said: > > - NumPy itself is unlikely to support keyword indexing anytime soon. > > - New packages could encourage using explicit aliases like > > "np.newaxis" > > instead of "None", which in general is a best practice already. > > - The combined use of keyword indexing *and* insertion of new axes at > > the > > same time strikes me as something that would be unusual in practice. > > From > > what I've seen, it is most useful to either use entirely unnamed or > > entirely named axes. In the later case, I might write something like > > obj[x=None] to indicate inserting a new dimension with the name "x". > > > > Just to briefly second these points and the general support thanks for > the hard work! I do also wonder about the `key=custom_default` > solution, or whether there may be other option to address this. > > For NumPy, I do hope we can play with the idea of adding support if > this PEP lands. But agree that labeled axes in NumPy is unlikely to be > on the immediate horizon, and I am not sure how feasible it is. > > My main in the discussion on python-ideas was `arr[]` doing something > unexpected, but it was long decided that it will remain a SyntaxError. > > For the question at hand, it seems to me that mixing labeled and > unlabeled indexing would be an error for array-like objects. > In that case, the worst we get seems a quirk where `arr[None, x=4]` is > not an error, when it should be an error. > That does not really strike me as a blocker. > > I am not a fan of such quirks. But some trade-off seems unavoidable > considering the backward compatibility constraints and differences > between array-likes and typing use of `__getitem__`. > > - Sebastian > > > > I think we could definitely live with it either way. I would lean > > towards > > using an empty tuple, but I agree that it feels a little uglier than > > using > > None (though perhaps not surprising, given the already ugly special > > cases > > for tuples in the indexing protocol). > > > > Best, > > Stephan > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wieser.eric+numpy at gmail.com Fri Sep 25 10:22:13 2020 From: wieser.eric+numpy at gmail.com (Eric Wieser) Date: Fri, 25 Sep 2020 15:22:13 +0100 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments In-Reply-To: References: <23d862330d1fdf2695db332973c4ff15506e2d23.camel@sipsolutions.net> Message-ID: I agree with Stephan's suggestion of having no default value for positional indices, and letting the user supply it. It seems I replied badly to the mail on the python-ideas list, and my response ended up as a separate thread, at https://mail.python.org/archives/list/python-ideas at python.org/thread/ZQ4CHT37YUHYEFYFBQ423QNZMFCRULAW/ . Eric On Thu, 24 Sep 2020 at 22:22, Aaron Meurer wrote: > This PEP also opens the possibility of allowing a[] with nothing in the > getitem. Has that been considered? > > Aaron Meurer > > On Thu, Sep 24, 2020 at 1:48 PM Sebastian Berg > wrote: > >> On Wed, 2020-09-23 at 21:41 -0700, Stephan Hoyer wrote: >> > On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini < >> > stefano.borini at gmail.com> >> > wrote: >> >> >> >> > > >> > Hi Stefano -- thanks for pushing this proposal forward! I am sure >> > that >> > support for keyword indexing will be very welcome in the scientific >> > Python >> > ecosystem. >> > >> > I have not been following the full discussion on PEP 637, but I >> > recall >> > seeing another suggestion earlier for what this could be resolved >> > into: >> > >> > type(obj).__getitem__(obj, x=23) >> > >> > I.e., not passing a positional argument at all. >> > >> > The author of a class that supports keyword indexing could check this >> > sort >> > of case with a positional only argument with a default value, e.g., >> > >> > def __getitem__(self, key=MY_SENTINEL, /, **kwargs): >> > >> > where MY_SENTINEL could be any desired sentinel value, including >> > either >> > None or (). Is there a reason for rejecting this option? It seems >> > like a >> > nice explicit alternative to prespecifing the choice of sentinel >> > value. >> > >> > I guess the concern might be that this would not suffice for >> > __setitem__? >> > >> > >> > > >> > > You can see a detailed discussion in the PEP at L913 >> >> >> >> > I guess the case this would disallow is distinguishing between >> > obj[None, >> > x=23] and obj[x=23]? >> > >> > Yes, this could be a little awkward potentially. The tuple would >> > definitely >> > be more natural for NumPy users, given the that first step of >> > __getitem__/__setitem__ methods in the broader NumPy ecosystem is >> > typically >> > packing non-tuple keys into a tuple, e.g., >> > >> > def __getitem__(self, key): >> > if not isinstance(key, tuple): >> > key = (key,) >> > ... >> > >> > That said: >> > - NumPy itself is unlikely to support keyword indexing anytime soon. >> > - New packages could encourage using explicit aliases like >> > "np.newaxis" >> > instead of "None", which in general is a best practice already. >> > - The combined use of keyword indexing *and* insertion of new axes at >> > the >> > same time strikes me as something that would be unusual in practice. >> > From >> > what I've seen, it is most useful to either use entirely unnamed or >> > entirely named axes. In the later case, I might write something like >> > obj[x=None] to indicate inserting a new dimension with the name "x". >> > >> >> Just to briefly second these points and the general support thanks for >> the hard work! I do also wonder about the `key=custom_default` >> solution, or whether there may be other option to address this. >> >> For NumPy, I do hope we can play with the idea of adding support if >> this PEP lands. But agree that labeled axes in NumPy is unlikely to be >> on the immediate horizon, and I am not sure how feasible it is. >> >> My main in the discussion on python-ideas was `arr[]` doing something >> unexpected, but it was long decided that it will remain a SyntaxError. >> >> For the question at hand, it seems to me that mixing labeled and >> unlabeled indexing would be an error for array-like objects. >> In that case, the worst we get seems a quirk where `arr[None, x=4]` is >> not an error, when it should be an error. >> That does not really strike me as a blocker. >> >> I am not a fan of such quirks. But some trade-off seems unavoidable >> considering the backward compatibility constraints and differences >> between array-likes and typing use of `__getitem__`. >> >> - Sebastian >> >> >> > I think we could definitely live with it either way. I would lean >> > towards >> > using an empty tuple, but I agree that it feels a little uglier than >> > using >> > None (though perhaps not surprising, given the already ugly special >> > cases >> > for tuples in the indexing protocol). >> > >> > Best, >> > Stephan >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion at python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion at python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From einstein.edison at gmail.com Fri Sep 25 10:33:05 2020 From: einstein.edison at gmail.com (Hameer Abbasi) Date: Fri, 25 Sep 2020 16:33:05 +0200 Subject: [Numpy-discussion] Request for comments on PEP 637 - Support for indexing with keyword arguments In-Reply-To: References: <23d862330d1fdf2695db332973c4ff15506e2d23.camel@sipsolutions.net> Message-ID: <687885df-dfc8-467e-9ce9-1d3cb775c155@Canary> Hello, For consistency with the current API, I?d suggest an empty tuple. arr[] # arr.__setitem__(()) arr[1] # arr.__setitem__(1) (could be the only exception) arr[1, 2] # arr.__setitem__((1, 2)) # NOT a.__setitem__(1, 2), note the missing parantheses arr[*a, **kw] # arr.__setitem__(a, **kw), perhaps a future extension If we do a[] # arr.__setitem__() a[1] # arr.__setitem__(1) a[1, 2] # arr.__setitem__((1, 2)) a[1, 2, x=3] # arr.__setitem__((1, 2), x=3) a[*a, **kw] # arr.__setitem__(a, **kw) But honestly, if I?m being candid, the form I like most is: arr[*a, **kw] # arr.__setitem__(a, kw) arr[*a] # arr.__setitem__(a) arr[**kw] # arr.__setitem__((), kw) This is driven by my love for generality and hatred of special cases. So I?m +1 for empty tuple or the third form. Best regards, Hameer Abbasi -- Sent from Canary (https://canarymail.io) > On Friday, Sep 25, 2020 at 4:22 PM, Eric Wieser wrote: > I agree with Stephan's suggestion of having no default value for positional indices, and letting the user supply it. > > It seems I replied badly to the mail on the python-ideas list, and my response ended up as a separate thread, at https://mail.python.org/archives/list/python-ideas at python.org/thread/ZQ4CHT37YUHYEFYFBQ423QNZMFCRULAW/. > > Eric > On Thu, 24 Sep 2020 at 22:22, Aaron Meurer wrote: > > This PEP also opens the possibility of allowing a[] with nothing in the getitem. Has that been considered? > > > > Aaron Meurer > > On Thu, Sep 24, 2020 at 1:48 PM Sebastian Berg wrote: > > > On Wed, 2020-09-23 at 21:41 -0700, Stephan Hoyer wrote: > > > > On Wed, Sep 23, 2020 at 2:22 PM Stefano Borini < > > > > stefano.borini at gmail.com (mailto:stefano.borini at gmail.com)> > > > > wrote: > > > > > > > > > > > > > > > > > > Hi Stefano -- thanks for pushing this proposal forward! I am sure > > > > that > > > > support for keyword indexing will be very welcome in the scientific > > > > Python > > > > ecosystem. > > > > > > > > I have not been following the full discussion on PEP 637, but I > > > > recall > > > > seeing another suggestion earlier for what this could be resolved > > > > into: > > > > > > > > type(obj).__getitem__(obj, x=23) > > > > > > > > I.e., not passing a positional argument at all. > > > > > > > > The author of a class that supports keyword indexing could check this > > > > sort > > > > of case with a positional only argument with a default value, e.g., > > > > > > > > def __getitem__(self, key=MY_SENTINEL, /, **kwargs): > > > > > > > > where MY_SENTINEL could be any desired sentinel value, including > > > > either > > > > None or (). Is there a reason for rejecting this option? It seems > > > > like a > > > > nice explicit alternative to prespecifing the choice of sentinel > > > > value. > > > > > > > > I guess the concern might be that this would not suffice for > > > > __setitem__? > > > > > > > > > > > > > > > > > > You can see a detailed discussion in the PEP at L913 > > > > > > > > > > > > > I guess the case this would disallow is distinguishing between > > > > obj[None, > > > > x=23] and obj[x=23]? > > > > > > > > Yes, this could be a little awkward potentially. The tuple would > > > > definitely > > > > be more natural for NumPy users, given the that first step of > > > > __getitem__/__setitem__ methods in the broader NumPy ecosystem is > > > > typically > > > > packing non-tuple keys into a tuple, e.g., > > > > > > > > def __getitem__(self, key): > > > > if not isinstance(key, tuple): > > > > key = (key,) > > > > ... > > > > > > > > That said: > > > > - NumPy itself is unlikely to support keyword indexing anytime soon. > > > > - New packages could encourage using explicit aliases like > > > > "np.newaxis" > > > > instead of "None", which in general is a best practice already. > > > > - The combined use of keyword indexing *and* insertion of new axes at > > > > the > > > > same time strikes me as something that would be unusual in practice. > > > > From > > > > what I've seen, it is most useful to either use entirely unnamed or > > > > entirely named axes. In the later case, I might write something like > > > > obj[x=None] to indicate inserting a new dimension with the name "x". > > > > > > > > > > Just to briefly second these points and the general support thanks for > > > the hard work! I do also wonder about the `key=custom_default` > > > solution, or whether there may be other option to address this. > > > > > > For NumPy, I do hope we can play with the idea of adding support if > > > this PEP lands. But agree that labeled axes in NumPy is unlikely to be > > > on the immediate horizon, and I am not sure how feasible it is. > > > > > > My main in the discussion on python-ideas was `arr[]` doing something > > > unexpected, but it was long decided that it will remain a SyntaxError. > > > > > > For the question at hand, it seems to me that mixing labeled and > > > unlabeled indexing would be an error for array-like objects. > > > In that case, the worst we get seems a quirk where `arr[None, x=4]` is > > > not an error, when it should be an error. > > > That does not really strike me as a blocker. > > > > > > I am not a fan of such quirks. But some trade-off seems unavoidable > > > considering the backward compatibility constraints and differences > > > between array-likes and typing use of `__getitem__`. > > > > > > - Sebastian > > > > > > > > > > I think we could definitely live with it either way. I would lean > > > > towards > > > > using an empty tuple, but I agree that it feels a little uglier than > > > > using > > > > None (though perhaps not surprising, given the already ugly special > > > > cases > > > > for tuples in the indexing protocol). > > > > > > > > Best, > > > > Stephan > > > > _______________________________________________ > > > > NumPy-Discussion mailing list > > > > NumPy-Discussion at python.org (mailto:NumPy-Discussion at python.org) > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion at python.org (mailto:NumPy-Discussion at python.org) > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion at python.org (mailto:NumPy-Discussion at python.org) > > https://mail.python.org/mailman/listinfo/numpy-discussion > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Fri Sep 25 14:05:01 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Fri, 25 Sep 2020 15:05:01 -0300 Subject: [Numpy-discussion] Documentation Team meeting - Monday September 28 In-Reply-To: References: Message-ID: Hi all! This is a reminder that our next Documentation Team meeting will be on *Monday, September 28* at 3PM UTC**. If you wish to join on Zoom, you need to use this link https://zoom.us/j/420005230 Here's the permanent hackmd document with the meeting notes (still being updated in the next few days!): https://hackmd.io/oB_boakvRqKR-_2jRV-Qjg Hope to see you around! ** You can click this link to get the correct time at your timezone: https://www.timeanddate.com/worldclock/fixedtime.html?msg=NumPy+Documentation+Team+Meeting&iso=20200928T15&p1=1440&ah=1 *** You can add the NumPy community calendar to your google calendar by clicking this link: https://calendar.google.com/calendar/r?cid=YmVya2VsZXkuZWR1X2lla2dwaWdtMjMyamJobGRzZmIyYzJqODFjQGdyb3VwLmNhbGVuZGFyLmdvb2dsZS5jb20 - Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From lee.johnston.100 at gmail.com Sat Sep 26 10:52:13 2020 From: lee.johnston.100 at gmail.com (Lee Johnston) Date: Sat, 26 Sep 2020 09:52:13 -0500 Subject: [Numpy-discussion] datetime64/timedelta64 support in linspace Message-ID: I propose adding support for datetime64/timedelta64 in linspace and solicit feedback on the feature. As is, linspace raises UFuncTypeError when parameters start and stop are datetime64/timedelta64. The complementary function arange supports these types. Work was started on this feature in PR 14700 but has stalled and I would like to complete it, but there are some issues worth getting feedback on. 1. Supporting datetime64/timedelta64 will require a special case code path within linspace. The code path is selected based on the start parameter data type. 2. The output dtype has to be explicitly set. 3. The step size resolution is determined by the lesser resolution of start and dtype. Issue 3 may lead to an unexpected result for an end-user. For example, >>> import numpy as np >>> np.linspace(np.timedelta64(0, "s"), np.timedelta64(1, "s"), 4, dtype="timedelta64[ms]") array([ 0, 0, 0, 1000], dtype='timedelta64[ms]') The existing solution in PR 14700 does not override the end-user's start and dtype resolution. In this case, the end-user would have to set both start and dtype to "ms" resolution to get the expected result. >>> np.linspace(np.timedelta64(0, "ms"), np.timedelta64(1, "s"), 4, dtype="timedelta64[ms]") array([ 0, 333, 666, 1000], dtype='timedelta64[ms]') In PR 14700, there is some discussion of "NaT" handling. In my implementation, "NaT" works the same as "NaN" and I am not aware of any corner cases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.rogozhnikov at yandex.ru Sun Sep 27 01:51:16 2020 From: alex.rogozhnikov at yandex.ru (Alex Rogozhnikov) Date: Sun, 27 Sep 2020 08:51:16 +0300 Subject: [Numpy-discussion] Einops cross-linking from einsum Message-ID: <3191601184364@mail.yandex.ru> An HTML attachment was scrubbed... URL: From shoyer at gmail.com Sun Sep 27 02:08:58 2020 From: shoyer at gmail.com (Stephan Hoyer) Date: Sat, 26 Sep 2020 23:08:58 -0700 Subject: [Numpy-discussion] Einops cross-linking from einsum In-Reply-To: <3191601184364@mail.yandex.ru> References: <3191601184364@mail.yandex.ru> Message-ID: On Sat, Sep 26, 2020 at 10:53 PM Alex Rogozhnikov < alex.rogozhnikov at yandex.ru> wrote: > Hello all, > > I'm developer of einops - python package for readable and reliable tensor > operations. > Einops handles different types of tensors (including numpy, pytorch, jax, > tensorflow and others) and targeted as a verbose replacement to existing > numpy operations. > > As einops now is quite mature project, I suggest linking einops from > np.einsum function > (which was an initial point to appearance of this new interface, and many > einops users previously used einsum) > > Not sure about precise implementation - link in 'see also' works. > Alternatively, I can suggest a single-line description like: > Operations with similar verbose interface are provided by einops > package to cover additional > operations: transpose, reshape/flatten, repeat/tile, squeeze/unsqueeze and > reductions. > > Glad to hear opinions/recommendations. > Hi Alex, I think this would be a nice idea! Putting a note like this in the "See also" section seems appropriate to me. I would also suggest adding a reference to opt-einsum, which provides more flexible optimization routines for np.einsum. Cheers, Stephan > > Cheers, > Alex. > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ralf.gommers at gmail.com Sun Sep 27 05:30:24 2020 From: ralf.gommers at gmail.com (Ralf Gommers) Date: Sun, 27 Sep 2020 10:30:24 +0100 Subject: [Numpy-discussion] Einops cross-linking from einsum In-Reply-To: References: <3191601184364@mail.yandex.ru> Message-ID: On Sun, Sep 27, 2020 at 7:09 AM Stephan Hoyer wrote: > On Sat, Sep 26, 2020 at 10:53 PM Alex Rogozhnikov < > alex.rogozhnikov at yandex.ru> wrote: > >> Hello all, >> >> I'm developer of einops - python package for readable and reliable tensor >> operations. >> Einops handles different types of tensors (including numpy, pytorch, jax, >> tensorflow and others) and targeted as a verbose replacement to existing >> numpy operations. >> >> As einops now is quite mature project, I suggest linking einops from >> np.einsum function >> (which was an initial point to appearance of this new interface, and many >> einops users previously used einsum) >> >> Not sure about precise implementation - link in 'see also' works. >> Alternatively, I can suggest a single-line description like: >> Operations with similar verbose interface are provided by einops >> package to cover additional >> operations: transpose, reshape/flatten, repeat/tile, squeeze/unsqueeze and >> reductions. >> >> Glad to hear opinions/recommendations. >> > > Hi Alex, > > I think this would be a nice idea! Putting a note like this in the "See > also" section seems appropriate to me. > > I would also suggest adding a reference to opt-einsum, which provides more > flexible optimization routines for np.einsum. > +1 from me both for einops and opt-einsum in the See Also section of einsum. Thank Alex, einops is really nice! Cheers, Ralf -------------- next part -------------- An HTML attachment was scrubbed... URL: From melissawm at gmail.com Mon Sep 28 11:06:16 2020 From: melissawm at gmail.com (=?UTF-8?Q?Melissa_Mendon=C3=A7a?=) Date: Mon, 28 Sep 2020 12:06:16 -0300 Subject: [Numpy-discussion] Docs team meeting - zoom link Message-ID: Hi all, Due to a change in zoom setting the link to the Documentation team meeting happening now has changed: https://zoom.us/j/91539509177?pwd=dFlqSGxBQURBOXh4alRBVWgvcTZUUT09 Cheers, Melissa -------------- next part -------------- An HTML attachment was scrubbed... URL: From cimrman3 at ntc.zcu.cz Tue Sep 29 04:08:15 2020 From: cimrman3 at ntc.zcu.cz (Robert Cimrman) Date: Tue, 29 Sep 2020 10:08:15 +0200 Subject: [Numpy-discussion] ANN: SfePy 2020.3 Message-ID: <4f19f26f-8340-2d09-ee46-3f0566ef0bd7@ntc.zcu.cz> I am pleased to announce the release of SfePy 2020.3. Description ----------- SfePy (simple finite elements in Python) is a software for solving systems of coupled partial differential equations by finite element methods. It is distributed under the new BSD license. Home page: https://sfepy.org Mailing list: https://mail.python.org/mm3/mailman3/lists/sfepy.python.org/ Git (source) repository, issue tracker: https://github.com/sfepy/sfepy Highlights of this release -------------------------- - new script for visualizations based on pyvista - generalized Yeoh hyperelastic term + example For full release notes see [1]. Cheers, Robert Cimrman [1] http://docs.sfepy.org/doc/release_notes.html#id1 --- Contributors to this release in alphabetical order: Robert Cimrman Jan Heczko Vladimir Lukes From sebastian at sipsolutions.net Tue Sep 29 16:43:34 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 29 Sep 2020 15:43:34 -0500 Subject: [Numpy-discussion] datetime64/timedelta64 support in linspace In-Reply-To: References: Message-ID: <1a2b9a15d277023951f705f1e0c1bee64c38daca.camel@sipsolutions.net> On Sat, 2020-09-26 at 09:52 -0500, Lee Johnston wrote: > I propose adding support for datetime64/timedelta64 in linspace and > solicit > feedback on the feature. As is, linspace raises UFuncTypeError when > parameters start and stop are datetime64/timedelta64. The > complementary > function arange supports these types. Work was started on this > feature in PR > 14700 but has stalled and > I > would like to complete it, but there are some issues worth getting > feedback > on. > > 1. Supporting datetime64/timedelta64 will require a special case > code > path within linspace. The code path is selected based on the start > parameter data type. > 2. The output dtype has to be explicitly set. > 3. The step size resolution is determined by the lesser resolution > of > start and dtype. > > Issue 3 may lead to an unexpected result for an end-user. For > example, > > > > > import numpy as np > > > > np.linspace(np.timedelta64(0, "s"), np.timedelta64(1, "s"), 4, > dtype="timedelta64[ms]") > array([ 0, 0, 0, 1000], dtype='timedelta64[ms]') > > The existing solution in PR 14700 does not override the end-user's > start > and dtype resolution. In this case, the end-user would have to set > both > start and dtype to "ms" resolution to get the expected result. > > > > > np.linspace(np.timedelta64(0, "ms"), np.timedelta64(1, "s"), 4, > dtype="timedelta64[ms]") > array([ 0, 333, 666, 1000], dtype='timedelta64[ms]') Thanks for taking the time and looking into this! Can you explain why your solution of using the input units to represent the step size is better then using the provided one? If this turns out tricky, we could also make the rule: cast everything to a single unit (as long as the cast is considered "safe"), that may force the user to do the cast in the long run, but I maybe most users are not dealing with a mix of units here to begin with? The approach in the last state of the PR, had issues with the timedelta/datetime equivalent of: >>> np.diff(np.linspace(0, 1000, 33, dtype='int64')) array([31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32, 31, 31, 31, 32]) which has an uneven step size that was not spread out (note the 32 values). I assume you have a solution for that? Maybe it is best if you can just pick up the PR and create a new one (if possible pull in the existing commits, or tests for attribution as well), so we can discuss easier reading the tests. > > In PR 14700, there is some discussion of "NaT" handling. In my > implementation, "NaT" works the same as "NaN" and I am not aware of > any > corner cases. There may not be, I think this had to do with how we approached certain difficulties in the PR (around viewing as int64 or using floats, probably). We just should make sure to have tests for both start and end being NaT. Maybe NaT is not a big issue, because we can probably add an explicit code path if necessary. Cheers, Sebastian > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion at python.org > https://mail.python.org/mailman/listinfo/numpy-discussion -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: From sebastian at sipsolutions.net Tue Sep 29 17:06:23 2020 From: sebastian at sipsolutions.net (Sebastian Berg) Date: Tue, 29 Sep 2020 16:06:23 -0500 Subject: [Numpy-discussion] NumPy Community Meeting Wednesday Message-ID: <59c60b8f4a028bd3b1a431e957553a3674b8452d.camel@sipsolutions.net> Hi all, There will be a NumPy Community meeting Wednesday September 16th at 1pm Pacific Time (20:00 UTC). Everyone is invited and encouraged to join in and edit the work-in-progress meeting topics and notes at: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: This is a digitally signed message part URL: