[Numpy-discussion] Officially drop Python 3.6 from NumPy 1.20 (was: NumPy 1.20.x branch in two weeks)
Hi all, just to note: We discussed this yesterday briefly and decided to drop official support for 3.6 in the 1.20 release. We never had ambition to support 1.20 and there seems advantage in dropping it, if mainly for clarity and consistency with many other projects. If you disagree with this decision, please just bring it up so we can reconsider. Cheers, Sebastian PS: We may keep testing on 3.6 for the moment, at least for PyPy for technical reasons. On Tue, 2020-11-03 at 11:58 -0800, Brigitta Sipocz wrote: > Hi, > > For what it's worth, python 3.6 is also dropped for astropy 4.2 (RC1 > to be > released in the next few days). We haven't yet formally adopted > NEP29, but > are very close to it peding some word smithing, and no one from the > dev > team was fighting for keeping support for 3.6. or numpy 1.16. > > Cheers, > Brigitta > > On Tue, 3 Nov 2020 at 10:53, Thomas Caswell > wrote: > > > I am in favor of dropping py36 for np1.20, I think it would be good > > to > > lead by example. > > > > Similar to pandas, the next Matplotlib release (3.4 targeted for > > Dec/Jan) > > will not support py36. > > > > Tom > > > > > > > > On Tue, Nov 3, 2020 at 9:18 AM Mark Harfouche < > > [email protected]> > > wrote: > > > > > Juan made a pretty good argument for keeping 3.6 support in the > > > next > > > scikit-image release, let me try to paraphrase: > > > > > > - Since nobody has made the PR to explicitly drop python 3.6 from > > > the > > > scikit-image build matrix, we will continue to support it, but if > > > somebody > > > were to make the PR, I (Juan) would support it. > > > > > > As for supporting PyPy: it already exists in the build matrix > > > AFAICT. > > > Breaking PyPy would be a deliberate action, as opposed to an > > > accidental > > > byproduct of dropping CPython 3.6. > > > > > > On Mon, Nov 2, 2020, 13:50 Sebastian Berg < > > > [email protected]> > > > wrote: > > > > > > > On Mon, 2020-11-02 at 06:49 -0600, Juan Nunez-Iglesias wrote: > > > > > I like Ralf's email, and most of all I agree that the > > > > > existing > > > > > wording is clearer. > > > > > > > > > > My view on the NEP is that it does not mandate dropping > > > > > support, but > > > > > encourage it. In my projects I would drop it if I had use for > > > > > Python > > > > > 3.7+ features. It so happens that we want to use PEP-593 so > > > > > we were > > > > > grateful for NEP-29 giving us "permission" to drop 3.6. > > > > > > > > > > I would suggest that 3.6 be dropped immediately if there are > > > > > any open > > > > > PRs that would benefit from it, or code cleanups that it > > > > > would > > > > > enable. The point of the NEP is to short-circuit discussion > > > > > about > > > > > whether it's "worth" dropping 3.6. If it's valuable at all, > > > > > do it. > > > > > > > > > > > > > Probably the only thing that requires 3.7 in NumPy at this time > > > > is the > > > > module level `__getattr__`, which is used only for deprecations > > > > (and to > > > > make the financial removal slightly more gentle). > > > > I am not sure if PyPy already has stable support for 3.7 yet? > > > > Although > > > > PyPy is maybe not a big priority. > > > > > > > > We don't have to support 3.6 and I don't care if we do. Until > > > > this > > > > discussion my assumption was we would probably drop it. > > > > > > > > But, current master is tested against 3.6, so the main work > > > > seems > > > > release related. If Chuck thinks that is no hassle I don't mind > > > > if > > > > NumPy is a bit more conservative than NEP 29. > > > > > > > > Or is there a danger of setting a precedent where projects are > > > > wrongly > > > > expected to keep support just because NumPy still has it, so > > > > that NumPy > > > > not being conservative actually helps everyone? > > > > > > > > - Sebastian > > > > > > > > > > > > > Thanks all, > > > > > > > > > > Juan. > > > > > > > > > > On Mon, 2 Nov 2020, at 2:01 AM, Ralf Gommers wrote: > > > > > > On Mon, Nov 2, 2020 at 7:47 AM Stephan Hoyer < > > > > > > [email protected]> > > > > > > wrote: > > > > > > > On Sun, Nov 1, 2020 at 7:47 PM Stefan van der Walt < > > > > > > > [email protected]> wrote: > > > > > > > > On Sun, Nov 1, 2020, at 18:54, Jarrod Millman wrote: > > > > > > > > > I also misunderstood the purpose of the NEP. I > > > > > > > > > assumed it > > > > > > > > > was > > > > > > > > > intended to encourage projects to drop old versions > > > > > > > > > of > > > > > > > > > Python. > > > > > > > > > > > > It was. It is. I think the NEP is very clear on that. > > > > > > Honestly we > > > > > > should just follow the NEP and drop 3.6 now for both NumPy > > > > > > and > > > > > > SciPy, I just am tired of arguing for it - which the NEP > > > > > > should > > > > > > have prevented being necessary, and I don't want to do > > > > > > again right > > > > > > now, so this will probably be my last email on this thread. > > > > > > > > > > > > > > >
Re: [Numpy-discussion] Add sliding_window_view method to numpy
Hi all, just a brief note that I merged this proposal: https://github.com/numpy/numpy/pull/17394 adding `np.sliding_window_view` into the 1.20 release of NumPy. There was only one public API change, and that is that the `shape` argument is now called `window_shape`. This is still a good time for feedback in case you have a better idea e.g. for the function or parameter names. Cheers, Sebastian On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: > Hello, > > I would like to draw the attention of this list to PR #17394 [1] that > adds the implementation of a sliding window view to numpy. > > Having a sliding window view in numpy is a longstanding open issue > (cf > #7753 [2] from 2016). A brief summary of the discussions surrounding > it > can be found in the description of the PR. > > This PR implements a sliding window view based on stride tricks. > Following the discussion in issue #7753, a first implementation was > provided by Fanjin Zeng in PR #10771. After some discussion, that PR > stalled and I picked up the issue in the present PR #17394. It is > based > on the first implementation, but follows the changed API as suggested > by > Eric Wieser. > > Code reviews have been provided by Bas van Beek, Stephen Hoyer, and > Eric > Wieser. Sebastian Berg added the "62 - Python API" label. > > > Do you think this is suitable for inclusion in numpy? > > Do you consider the PR ready? > > Do you have suggestions or requests? > > > Thanks for your time and consideration! > Klaus > > > [1] https://github.com/numpy/numpy/pull/17394 > [2] https://github.com/numpy/numpy/issues/7753 > ___ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion > signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add sliding_window_view method to numpy
On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg wrote: > Hi all, > > just a brief note that I merged this proposal: > > https://github.com/numpy/numpy/pull/17394 > > adding `np.sliding_window_view` into the 1.20 release of NumPy. > > There was only one public API change, and that is that the `shape` > argument is now called `window_shape`. > > This is still a good time for feedback in case you have a better idea > e.g. for the function or parameter names. > The old PR had this in the lib.stride_tricks namespace. Seeing it in the main namespace is unexpected and likely will lead to issues/questions, given that such an overlapping view is going to do behave in ways the average user will be surprised by. It may also lead to requests for other array/tensor libraries to implement this. I don't see any discussion on this in PR 17394, it looks like a decision by the PR author that no one commented on - reconsider that? Cheers, Ralf > > Cheers, > > Sebastian > > > > On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: > > Hello, > > > > I would like to draw the attention of this list to PR #17394 [1] that > > adds the implementation of a sliding window view to numpy. > > > > Having a sliding window view in numpy is a longstanding open issue > > (cf > > #7753 [2] from 2016). A brief summary of the discussions surrounding > > it > > can be found in the description of the PR. > > > > This PR implements a sliding window view based on stride tricks. > > Following the discussion in issue #7753, a first implementation was > > provided by Fanjin Zeng in PR #10771. After some discussion, that PR > > stalled and I picked up the issue in the present PR #17394. It is > > based > > on the first implementation, but follows the changed API as suggested > > by > > Eric Wieser. > > > > Code reviews have been provided by Bas van Beek, Stephen Hoyer, and > > Eric > > Wieser. Sebastian Berg added the "62 - Python API" label. > > > > > > Do you think this is suitable for inclusion in numpy? > > > > Do you consider the PR ready? > > > > Do you have suggestions or requests? > > > > > > Thanks for your time and consideration! > > Klaus > > > > > > [1] https://github.com/numpy/numpy/pull/17394 > > [2] https://github.com/numpy/numpy/issues/7753 > > ___ > > NumPy-Discussion mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] datetime64: Remove deprecation warning when constructing with timezone
Hi,
I suggest removing the deprecation warning when constructing a datetime64
with a timezone. For example, this is the current behavior:
>>> np.datetime64('2020-11-05 16:00+0200')
:1: DeprecationWarning: parsing timezone aware datetimes is
deprecated; this will raise an error in the future
numpy.datetime64('2020-11-05T14:00')
I suggest removing the deprecation warning because I find this to be a
useful behavior, and because it is a correct behavior. The manual says:
"The datetime object represents a single moment in time... Datetimes are
always stored based on POSIX time, with an epoch of 1970-01-01T00:00Z."
So 2020-11-05T16:00+0200 is indeed the moment in time represented by
np.datetime64('2020-11-05T14:00').
I just used this to restrict my data set to records created after a certain
moment. It was easier for me to write the moment in my local time and add
"+0200" than to figure out the moment representation in UTC.
So this is my simple suggestion: remove the deprecation warning.
Beyond that, I have 3 ideas for changing the repr of datetime64 that I
would like to discuss.
1. Add "Z" at the end, for example, numpy.datetime64('2020-11-05T14:00Z').
This will make it clear to which moment it refers. I think this is
significant - I had to dig quite a bit to realize that
datetime64('2020-11-05T14:00') means 14:00 UTC.
2. Replace the 'T' with a space. I just find it much easier to read
'2020-11-05 14:00Z' than '2020-11-05T14:00Z'. The long sequence of
characters makes it hard for my brain to parse.
3. This will require discussion, but will be very convenient: have the repr
display the time using the environment time zone, including a time offset.
So, in my specific time zone (+0200), I will have:
repr(np.datetime64('2020-11-05 14:00Z')) ==
"numpy.datetime64('2020-11-05T16:00+0200')"
I'm sure the pros and cons of having an environment-dependent repr should
be discussed. But I will list some pros:
1. It's very convenient - it's immediately obvious to me to which moment
2020-11-05 16:00+0200 refers.
2. It's well defined - I may collect timestamps from machines with
different time zones, and I will be able to know to which exact moment each
timestamp refers.
3. It's very simple - I could compare any two timestamps, I don't have to
worry about time zones.
I would be happy to hear your thoughts.
Thanks,
Noam
___
NumPy-Discussion mailing list
[email protected]
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add sliding_window_view method to numpy
On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers wrote: > > > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg > wrote: > >> Hi all, >> >> just a brief note that I merged this proposal: >> >> https://github.com/numpy/numpy/pull/17394 >> >> adding `np.sliding_window_view` into the 1.20 release of NumPy. >> >> There was only one public API change, and that is that the `shape` >> argument is now called `window_shape`. >> >> This is still a good time for feedback in case you have a better idea >> e.g. for the function or parameter names. >> > > The old PR had this in the lib.stride_tricks namespace. Seeing it in the > main namespace is unexpected and likely will lead to issues/questions, > given that such an overlapping view is going to do behave in ways the > average user will be surprised by. It may also lead to requests for other > array/tensor libraries to implement this. I don't see any discussion on > this in PR 17394, it looks like a decision by the PR author that no one > commented on - reconsider that? > > Cheers, > Ralf > +1 let's keep this in the lib.stride_tricks namespace. > > > > >> >> Cheers, >> >> Sebastian >> >> >> >> On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: >> > Hello, >> > >> > I would like to draw the attention of this list to PR #17394 [1] that >> > adds the implementation of a sliding window view to numpy. >> > >> > Having a sliding window view in numpy is a longstanding open issue >> > (cf >> > #7753 [2] from 2016). A brief summary of the discussions surrounding >> > it >> > can be found in the description of the PR. >> > >> > This PR implements a sliding window view based on stride tricks. >> > Following the discussion in issue #7753, a first implementation was >> > provided by Fanjin Zeng in PR #10771. After some discussion, that PR >> > stalled and I picked up the issue in the present PR #17394. It is >> > based >> > on the first implementation, but follows the changed API as suggested >> > by >> > Eric Wieser. >> > >> > Code reviews have been provided by Bas van Beek, Stephen Hoyer, and >> > Eric >> > Wieser. Sebastian Berg added the "62 - Python API" label. >> > >> > >> > Do you think this is suitable for inclusion in numpy? >> > >> > Do you consider the PR ready? >> > >> > Do you have suggestions or requests? >> > >> > >> > Thanks for your time and consideration! >> > Klaus >> > >> > >> > [1] https://github.com/numpy/numpy/pull/17394 >> > [2] https://github.com/numpy/numpy/issues/7753 >> > ___ >> > NumPy-Discussion mailing list >> > [email protected] >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> > >> >> ___ >> NumPy-Discussion mailing list >> [email protected] >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > ___ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion > ___ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime64: Remove deprecation warning when constructing with timezone
Without weighing in yet on how I feel about the deprecation, you can see
some discussion about why this was originally deprecated in the PR that
introduced the warning:
https://github.com/numpy/numpy/pull/6453
Eric
On Thu, Nov 5, 2020, 20:13 Noam Yorav-Raphael wrote:
> Hi,
>
> I suggest removing the deprecation warning when constructing a datetime64
> with a timezone. For example, this is the current behavior:
>
> >>> np.datetime64('2020-11-05 16:00+0200')
> :1: DeprecationWarning: parsing timezone aware datetimes is
> deprecated; this will raise an error in the future
> numpy.datetime64('2020-11-05T14:00')
>
> I suggest removing the deprecation warning because I find this to be a
> useful behavior, and because it is a correct behavior. The manual says:
> "The datetime object represents a single moment in time... Datetimes are
> always stored based on POSIX time, with an epoch of 1970-01-01T00:00Z."
> So 2020-11-05T16:00+0200 is indeed the moment in time represented by
> np.datetime64('2020-11-05T14:00').
>
> I just used this to restrict my data set to records created after a
> certain moment. It was easier for me to write the moment in my local time
> and add "+0200" than to figure out the moment representation in UTC.
>
> So this is my simple suggestion: remove the deprecation warning.
>
>
> Beyond that, I have 3 ideas for changing the repr of datetime64 that I
> would like to discuss.
>
> 1. Add "Z" at the end, for example, numpy.datetime64('2020-11-05T14:00Z').
> This will make it clear to which moment it refers. I think this is
> significant - I had to dig quite a bit to realize that
> datetime64('2020-11-05T14:00') means 14:00 UTC.
>
> 2. Replace the 'T' with a space. I just find it much easier to read
> '2020-11-05 14:00Z' than '2020-11-05T14:00Z'. The long sequence of
> characters makes it hard for my brain to parse.
>
> 3. This will require discussion, but will be very convenient: have the
> repr display the time using the environment time zone, including a time
> offset. So, in my specific time zone (+0200), I will have:
>
> repr(np.datetime64('2020-11-05 14:00Z')) ==
> "numpy.datetime64('2020-11-05T16:00+0200')"
>
> I'm sure the pros and cons of having an environment-dependent repr should
> be discussed. But I will list some pros:
> 1. It's very convenient - it's immediately obvious to me to which moment
> 2020-11-05 16:00+0200 refers.
> 2. It's well defined - I may collect timestamps from machines with
> different time zones, and I will be able to know to which exact moment each
> timestamp refers.
> 3. It's very simple - I could compare any two timestamps, I don't have to
> worry about time zones.
>
> I would be happy to hear your thoughts.
>
> Thanks,
> Noam
> ___
> NumPy-Discussion mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
[email protected]
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add sliding_window_view method to numpy
On Thu, 2020-11-05 at 12:51 -0800, Stephan Hoyer wrote: > On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers > wrote: > > > > > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg < > > [email protected]> > > wrote: > > > > > Hi all, > > > > > > just a brief note that I merged this proposal: > > > > > > https://github.com/numpy/numpy/pull/17394 > > > > > > adding `np.sliding_window_view` into the 1.20 release of NumPy. > > > > > > There was only one public API change, and that is that the > > > `shape` > > > argument is now called `window_shape`. > > > > > > This is still a good time for feedback in case you have a better > > > idea > > > e.g. for the function or parameter names. > > > > > > > The old PR had this in the lib.stride_tricks namespace. Seeing it > > in the > > main namespace is unexpected and likely will lead to > > issues/questions, > > given that such an overlapping view is going to do behave in ways > > the > > average user will be surprised by. It may also lead to requests for > > other > > array/tensor libraries to implement this. I don't see any > > discussion on > > this in PR 17394, it looks like a decision by the PR author that no > > one > > commented on - reconsider that? > > > > Cheers, > > Ralf > > > > +1 let's keep this in the lib.stride_tricks namespace. > I have no reservations against having it in the main namespace and am happy either way (it can still be exposed later in any case). It is the conservative choice and maybe it is an uncommon enough function that it deserves being a bit hidden... But I am curious, it sounds like you have both very strong reservations, and I would like to understand them better. The behaviour can be surprising, but that is why the default is a read- only view. I do not think it is worse than `np.broadcast_to` in this regard. (It is nowhere near as dangerous as `as_strided`.) It is true that it is specific to NumPy (memory model). So that is maybe a good enough reason right now. But I am not sure that stuffing things into a pretty hidden `np.lib.*` namespaces is a great long term solution either. There is very little useful functionality hidden away in `np.lib.*` currently. Cheers, Sebastian > > > > > > > > > > Cheers, > > > > > > Sebastian > > > > > > > > > > > > On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: > > > > Hello, > > > > > > > > I would like to draw the attention of this list to PR #17394 > > > > [1] that > > > > adds the implementation of a sliding window view to numpy. > > > > > > > > Having a sliding window view in numpy is a longstanding open > > > > issue > > > > (cf > > > > #7753 [2] from 2016). A brief summary of the discussions > > > > surrounding > > > > it > > > > can be found in the description of the PR. > > > > > > > > This PR implements a sliding window view based on stride > > > > tricks. > > > > Following the discussion in issue #7753, a first implementation > > > > was > > > > provided by Fanjin Zeng in PR #10771. After some discussion, > > > > that PR > > > > stalled and I picked up the issue in the present PR #17394. It > > > > is > > > > based > > > > on the first implementation, but follows the changed API as > > > > suggested > > > > by > > > > Eric Wieser. > > > > > > > > Code reviews have been provided by Bas van Beek, Stephen Hoyer, > > > > and > > > > Eric > > > > Wieser. Sebastian Berg added the "62 - Python API" label. > > > > > > > > > > > > Do you think this is suitable for inclusion in numpy? > > > > > > > > Do you consider the PR ready? > > > > > > > > Do you have suggestions or requests? > > > > > > > > > > > > Thanks for your time and consideration! > > > > Klaus > > > > > > > > > > > > [1] https://github.com/numpy/numpy/pull/17394 > > > > [2] https://github.com/numpy/numpy/issues/7753 > > > > ___ > > > > NumPy-Discussion mailing list > > > > [email protected] > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > ___ > > > NumPy-Discussion mailing list > > > [email protected] > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > ___ > > NumPy-Discussion mailing list > > [email protected] > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > ___ > NumPy-Discussion mailing list > [email protected] > https://mail.python.org/mailman/listinfo/numpy-discussion signature.asc Description: This is a digitally signed message part ___ NumPy-Discussion mailing list [email protected] https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] datetime64: Remove deprecation warning when constructing with timezone
I can try to dig up the old discussions, but datetime64 used to implement
both (1) and (3), and this was updated in a very intentional way.
Datetime64 now works like Python's own time-zone naive datetime.datetime
objects. The documentation referencing "Z" should be updated -- datetime64
can be in any timezone you like.
Timezone aware datetime objects are certainly useful, but NumPy's
datetime64 was restricted to UTC. The consensus was that it was worse to
have UTC-only rather than timezone-naive-only. NumPy's datetime64 is often
used for data analysis purposes, for which automatic conversion to the
local timezone of the computer running the analysis is often
counter-productive.
If you care about timezone conversions, I would highly recommend looking
into pandas's Timestamp class for this purpose. In the future, this would
be a good use-case for a new custom NumPy dtype. (The existing
np.datetime64 code cannot easily handle multiple timezones.)
On Thu, Nov 5, 2020 at 1:04 PM Eric Wieser
wrote:
> Without weighing in yet on how I feel about the deprecation, you can see
> some discussion about why this was originally deprecated in the PR that
> introduced the warning:
>
> https://github.com/numpy/numpy/pull/6453
>
> Eric
>
> On Thu, Nov 5, 2020, 20:13 Noam Yorav-Raphael wrote:
>
>> Hi,
>>
>> I suggest removing the deprecation warning when constructing a datetime64
>> with a timezone. For example, this is the current behavior:
>>
>> >>> np.datetime64('2020-11-05 16:00+0200')
>> :1: DeprecationWarning: parsing timezone aware datetimes is
>> deprecated; this will raise an error in the future
>> numpy.datetime64('2020-11-05T14:00')
>>
>> I suggest removing the deprecation warning because I find this to be a
>> useful behavior, and because it is a correct behavior. The manual says:
>> "The datetime object represents a single moment in time... Datetimes are
>> always stored based on POSIX time, with an epoch of 1970-01-01T00:00Z."
>> So 2020-11-05T16:00+0200 is indeed the moment in time represented by
>> np.datetime64('2020-11-05T14:00').
>>
>> I just used this to restrict my data set to records created after a
>> certain moment. It was easier for me to write the moment in my local time
>> and add "+0200" than to figure out the moment representation in UTC.
>>
>> So this is my simple suggestion: remove the deprecation warning.
>>
>>
>> Beyond that, I have 3 ideas for changing the repr of datetime64 that I
>> would like to discuss.
>>
>> 1. Add "Z" at the end, for example,
>> numpy.datetime64('2020-11-05T14:00Z'). This will make it clear to which
>> moment it refers. I think this is significant - I had to dig quite a bit to
>> realize that datetime64('2020-11-05T14:00') means 14:00 UTC.
>>
>> 2. Replace the 'T' with a space. I just find it much easier to read
>> '2020-11-05 14:00Z' than '2020-11-05T14:00Z'. The long sequence of
>> characters makes it hard for my brain to parse.
>>
>> 3. This will require discussion, but will be very convenient: have the
>> repr display the time using the environment time zone, including a time
>> offset. So, in my specific time zone (+0200), I will have:
>>
>> repr(np.datetime64('2020-11-05 14:00Z')) ==
>> "numpy.datetime64('2020-11-05T16:00+0200')"
>>
>> I'm sure the pros and cons of having an environment-dependent repr should
>> be discussed. But I will list some pros:
>> 1. It's very convenient - it's immediately obvious to me to which moment
>> 2020-11-05 16:00+0200 refers.
>> 2. It's well defined - I may collect timestamps from machines with
>> different time zones, and I will be able to know to which exact moment each
>> timestamp refers.
>> 3. It's very simple - I could compare any two timestamps, I don't have to
>> worry about time zones.
>>
>> I would be happy to hear your thoughts.
>>
>> Thanks,
>> Noam
>> ___
>> NumPy-Discussion mailing list
>> [email protected]
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
[email protected]
https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Add sliding_window_view method to numpy
On Thu, 2020-11-05 at 17:35 -0600, Sebastian Berg wrote: > On Thu, 2020-11-05 at 12:51 -0800, Stephan Hoyer wrote: > > On Thu, Nov 5, 2020 at 11:16 AM Ralf Gommers < > > [email protected]> > > wrote: > > > > > On Thu, Nov 5, 2020 at 4:56 PM Sebastian Berg < > > > [email protected]> > > > wrote: > > > > > > > Hi all, > > > > > > > > just a brief note that I merged this proposal: > > > > > > > > https://github.com/numpy/numpy/pull/17394 > > > > > > > > adding `np.sliding_window_view` into the 1.20 release of NumPy. > > > > > > > > There was only one public API change, and that is that the > > > > `shape` > > > > argument is now called `window_shape`. > > > > > > > > This is still a good time for feedback in case you have a > > > > better > > > > idea > > > > e.g. for the function or parameter names. > > > > > > > > > > The old PR had this in the lib.stride_tricks namespace. Seeing it > > > in the > > > main namespace is unexpected and likely will lead to > > > issues/questions, > > > given that such an overlapping view is going to do behave in ways > > > the > > > average user will be surprised by. It may also lead to requests > > > for > > > other > > > array/tensor libraries to implement this. I don't see any > > > discussion on > > > this in PR 17394, it looks like a decision by the PR author that > > > no > > > one > > > commented on - reconsider that? > > > > > > Cheers, > > > Ralf > > > > > > > +1 let's keep this in the lib.stride_tricks namespace. > > > > I have no reservations against having it in the main namespace and am > happy either way (it can still be exposed later in any case). It is > the > conservative choice and maybe it is an uncommon enough function that > it > deserves being a bit hidden... In any case, its the safe bet for NumPy 1.20 at least so I opened a PR: https://github.com/numpy/numpy/pull/17720 Name changes, etc. are also possible of course. I still think it might be nice to find a better place for this type of function that `np.lib.stride_tricks` though, but dunno... - Sebastian > > But I am curious, it sounds like you have both very strong > reservations, and I would like to understand them better. > > The behaviour can be surprising, but that is why the default is a > read- > only view. I do not think it is worse than `np.broadcast_to` in this > regard. (It is nowhere near as dangerous as `as_strided`.) > > It is true that it is specific to NumPy (memory model). So that is > maybe a good enough reason right now. But I am not sure that > stuffing > things into a pretty hidden `np.lib.*` namespaces is a great long > term > solution either. There is very little useful functionality hidden > away > in `np.lib.*` currently. > > Cheers, > > Sebastian > > > > > > > > > > > Cheers, > > > > > > > > Sebastian > > > > > > > > > > > > > > > > On Mon, 2020-10-12 at 08:39 +, Zimmermann Klaus wrote: > > > > > Hello, > > > > > > > > > > I would like to draw the attention of this list to PR #17394 > > > > > [1] that > > > > > adds the implementation of a sliding window view to numpy. > > > > > > > > > > Having a sliding window view in numpy is a longstanding open > > > > > issue > > > > > (cf > > > > > #7753 [2] from 2016). A brief summary of the discussions > > > > > surrounding > > > > > it > > > > > can be found in the description of the PR. > > > > > > > > > > This PR implements a sliding window view based on stride > > > > > tricks. > > > > > Following the discussion in issue #7753, a first > > > > > implementation > > > > > was > > > > > provided by Fanjin Zeng in PR #10771. After some discussion, > > > > > that PR > > > > > stalled and I picked up the issue in the present PR #17394. > > > > > It > > > > > is > > > > > based > > > > > on the first implementation, but follows the changed API as > > > > > suggested > > > > > by > > > > > Eric Wieser. > > > > > > > > > > Code reviews have been provided by Bas van Beek, Stephen > > > > > Hoyer, > > > > > and > > > > > Eric > > > > > Wieser. Sebastian Berg added the "62 - Python API" label. > > > > > > > > > > > > > > > Do you think this is suitable for inclusion in numpy? > > > > > > > > > > Do you consider the PR ready? > > > > > > > > > > Do you have suggestions or requests? > > > > > > > > > > > > > > > Thanks for your time and consideration! > > > > > Klaus > > > > > > > > > > > > > > > [1] https://github.com/numpy/numpy/pull/17394 > > > > > [2] https://github.com/numpy/numpy/issues/7753 > > > > > ___ > > > > > NumPy-Discussion mailing list > > > > > [email protected] > > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > > > > ___ > > > > NumPy-Discussion mailing list > > > > [email protected] > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > ___ >
