Mailman 3 April 2020 - NumPy-Discussion

1.19.x branch
by Charles R Harris April 29, 2020

April 29, 2020

Hi All, I thinking of making the 1.19.x branch in about two weeks. If there are PRs that you feel need to be in that release please let me know. Chuck

1 0

NumPy Community Meeting Wednesday
by Sebastian Berg April 28, 2020

April 28, 2020

Hi all, There will be a NumPy Community meeting Wednesday April 29th 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: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg?both Best wishes Sebastian

1 0

Google Season of Docs Ideas
by Ben Nathanson April 27, 2020

April 27, 2020

> > NumPy serves many kinds of users....The challenge: provide ways to guide > those users to the parts of the documentation most relevant to them. > I have a thought on how to approach this. We know many of the communities NumPy serves; let's next identify (for ourselves, not the proposal) what each of them needs. It could be as simple as: *Educator* - knows... - needs to know... *Researcher* - knows... - needs to know.. A table like that would be useful for self-assessment and planning. It helps answer questions like: - Which communities are we most shortchanging right now? - Which communities do we feel most strongly about (our largest base, most disadvantaged, etc.)? - If doc D is our next doc, does it help those communities? Or maybe we want to go round-robin through communities with each new doc. - What assumptions can a writer make about audience background? We're also then equipped to bring user categories out to a web page and meet the big-tent challenge head-on, with links like: - If you're an educator... - If you're a researcher... each one taking the user to an Educator, Researcher,..., page containing links to the information they're most likely to want.

2 1

Google Season of Docs Ideas
by Melissa Mendonça April 27, 2020

April 27, 2020

Hello all, As some of you may know, we are aiming to participate in the Google Season of Docs program [1] again this year. The deadline for applications from open source organizations is May 4, so I've started on a proposal (heavily based on last year's version) here: https://github.com/numpy/numpy/wiki/Google-Season-of-Docs-2020-Project-Ideas If you have suggestions, especially for concrete project ideas, that would be great. Also, keep in mind this project is aimed at technical writers and not developers, so the focus should be mainly on writing/reviewing/organizing documentation content. Cheers, Melissa [1] https://developers.google.com/season-of-docs

2 1

Re: [Numpy-discussion] beginner introduction to group
by Tina Oberoi April 25, 2020

April 25, 2020

On Sat, Sat, 25 Apr 2020 01:59:57 Robert Kern <robert.kern(a)gmail.com> wrote: Welcome! Do you have an idea what you would like to work on? Hi Robert, Nothing specific for now, But I am at present trying to work on Issue #15961. Titled "Einsum indexing very fragile, because it tests for int(and int64 is not int). Tina Oberoi

1 0

Re: [Numpy-discussion] NumPy-Discussion Digest, Vol 163, Issue 23
by Inessa Pawson April 25, 2020

April 25, 2020

On Sat, Apr 25, 2020 at 4:50 PM <numpy-discussion-request(a)python.org> wrote: > Send NumPy-Discussion mailing list submissions to > numpy-discussion(a)python.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://mail.python.org/mailman/listinfo/numpy-discussion > or, via email, send a message with subject or body 'help' to > numpy-discussion-request(a)python.org > > You can reach the person managing the list at > numpy-discussion-owner(a)python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of NumPy-Discussion digest..." > Today's Topics: > > 1. Re: Feelings about type aliases in NumPy (Sebastian Berg) > 2. beginner introduction to group (Tina Oberoi) > 3. Re: beginner introduction to group (Robert Kern) > 4. Re: Feelings about type aliases in NumPy (Stephan Hoyer) > 5. Re: Feelings about type aliases in NumPy (Kevin Sheppard) > > > > ---------- Forwarded message ---------- > From: Sebastian Berg <sebastian(a)sipsolutions.net> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Fri, 24 Apr 2020 13:29:59 -0500 > Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy > On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote: > > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote: > > > But, Stephan pointed out that it might be confusing to users for > > > objects to only exist at typing time, so we came around to the > > > question of whether people are open to the idea of including the > > > type > > > aliases in NumPy itself. Ralf's concrete proposal was to make a > > > module > > > numpy.types (or maybe numpy.typing) to hold the aliases so that > > > they > > > don't pollute the top-level namespace. The module would initially > > > contain the types > > > > That sounds very sensible. Having types available with NumPy should > > also encourage their use, especially if we can add some documentation > > around it. > > I agree, I might have a small tendency for `numpy.types` if we ever > find any usage other than direct typing that may be the better name? > > Out of curiousity, I guess `ArrayLike` would be an ABC that a > downstream project can register with? > > - Sebastian > > > > > > Stéfan > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion(a)python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > ---------- Forwarded message ---------- > From: Tina Oberoi <oberoi011115tina(a)gmail.com> > To: numpy-discussion(a)python.org > Cc: > Bcc: > Date: Sat, 25 Apr 2020 10:30:38 +0530 > Subject: [Numpy-discussion] beginner introduction to group > Hi Everyone, > I am new to contributing to numpy. I have read the contributors guide and > done with the set-up. Hope to make some good contributions and also to > connect with all you great people in the numpy community. > Any suggestions and tips are always welcome. > > Thanks and Regards > Welcome, Tina! -- Inessa Pawson > > ---------- Forwarded message ---------- > From: Robert Kern <robert.kern(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Sat, 25 Apr 2020 01:59:57 -0400 > Subject: Re: [Numpy-discussion] beginner introduction to group > On Sat, Apr 25, 2020 at 1:02 AM Tina Oberoi <oberoi011115tina(a)gmail.com> > wrote: > >> Hi Everyone, >> I am new to contributing to numpy. I have read the contributors guide and >> done with the set-up. Hope to make some good contributions and also to >> connect with all you great people in the numpy community. >> Any suggestions and tips are always welcome. >> > > Welcome! Do you have an idea what you would like to work on? > > -- > Robert Kern > > > > ---------- Forwarded message ---------- > From: Stephan Hoyer <shoyer(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Fri, 24 Apr 2020 23:40:20 -0700 > Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy > > > On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg < > sebastian(a)sipsolutions.net> wrote: > >> On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote: >> > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote: >> > > But, Stephan pointed out that it might be confusing to users for >> > > objects to only exist at typing time, so we came around to the >> > > question of whether people are open to the idea of including the >> > > type >> > > aliases in NumPy itself. Ralf's concrete proposal was to make a >> > > module >> > > numpy.types (or maybe numpy.typing) to hold the aliases so that >> > > they >> > > don't pollute the top-level namespace. The module would initially >> > > contain the types >> > >> > That sounds very sensible. Having types available with NumPy should >> > also encourage their use, especially if we can add some documentation >> > around it. >> >> I agree, I might have a small tendency for `numpy.types` if we ever >> find any usage other than direct typing that may be the better name? > > > Unless we anticipate adding a long list of type aliases (more than the > three suggested so far), I would lean towards adding ArrayLike to the top > level NumPy namespace as np.ArrayLike. > > Type annotations are becoming an increasingly core part of modern Python > code. We should make it easy to appropriately type check functions that act > on NumPy arrays, and a top level np.ArrayLike is definitely more convenient > than np.types.ArrayLike. > > Out of curiousity, I guess `ArrayLike` would be an ABC that a >> downstream project can register with? > > > ArrayLike will be a typing Protocol, automatically recognizing attributes > like __array__ to indicate that something can be cast to an array. > > >> >> - Sebastian >> >> >> > >> > Stéfan >> > _______________________________________________ >> > NumPy-Discussion mailing list >> > NumPy-Discussion(a)python.org >> > https://mail.python.org/mailman/listinfo/numpy-discussion >> >> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion(a)python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > > > > ---------- Forwarded message ---------- > From: Kevin Sheppard <kevin.k.sheppard(a)gmail.com> > To: Discussion of Numerical Python <numpy-discussion(a)python.org> > Cc: > Bcc: > Date: Sat, 25 Apr 2020 07:49:58 +0100 > Subject: Re: [Numpy-discussion] Feelings about type aliases in NumPy > Typing is for library developers more than end users. I would also worry > that putting it into the top level might discourage other typing classes > since it is more difficult to add to the top level than to a lower level > module. np.typing seems very clear to me. > > On Sat, Apr 25, 2020, 07:41 Stephan Hoyer <shoyer(a)gmail.com> wrote: > >> >> >> On Fri, Apr 24, 2020 at 11:31 AM Sebastian Berg < >> sebastian(a)sipsolutions.net> wrote: >> >>> On Fri, 2020-04-24 at 11:10 -0700, Stefan van der Walt wrote: >>> > On Fri, Apr 24, 2020, at 08:45, Joshua Wilson wrote: >>> > > But, Stephan pointed out that it might be confusing to users for >>> > > objects to only exist at typing time, so we came around to the >>> > > question of whether people are open to the idea of including the >>> > > type >>> > > aliases in NumPy itself. Ralf's concrete proposal was to make a >>> > > module >>> > > numpy.types (or maybe numpy.typing) to hold the aliases so that >>> > > they >>> > > don't pollute the top-level namespace. The module would initially >>> > > contain the types >>> > >>> > That sounds very sensible. Having types available with NumPy should >>> > also encourage their use, especially if we can add some documentation >>> > around it. >>> >>> I agree, I might have a small tendency for `numpy.types` if we ever >>> find any usage other than direct typing that may be the better name? >> >> >> Unless we anticipate adding a long list of type aliases (more than the >> three suggested so far), I would lean towards adding ArrayLike to the top >> level NumPy namespace as np.ArrayLike. >> >> Type annotations are becoming an increasingly core part of modern Python >> code. We should make it easy to appropriately type check functions that act >> on NumPy arrays, and a top level np.ArrayLike is definitely more convenient >> than np.types.ArrayLike. >> >> Out of curiousity, I guess `ArrayLike` would be an ABC that a >>> downstream project can register with? >> >> >> ArrayLike will be a typing Protocol, automatically recognizing attributes >> like __array__ to indicate that something can be cast to an array. >> >> >>> >>> - Sebastian >>> >>> >>> > >>> > Stéfan >>> > _______________________________________________ >>> > NumPy-Discussion mailing list >>> > NumPy-Discussion(a)python.org >>> > https://mail.python.org/mailman/listinfo/numpy-discussion >>> >>> >>> _______________________________________________ >>> NumPy-Discussion mailing list >>> NumPy-Discussion(a)python.org >>> https://mail.python.org/mailman/listinfo/numpy-discussion >>> >> _______________________________________________ >> NumPy-Discussion mailing list >> NumPy-Discussion(a)python.org >> https://mail.python.org/mailman/listinfo/numpy-discussion >> > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion(a)python.org > https://mail.python.org/mailman/listinfo/numpy-discussion >

1 0

beginner introduction to group
by Tina Oberoi April 25, 2020

April 25, 2020

Hi Everyone, I am new to contributing to numpy. I have read the contributors guide and done with the set-up. Hope to make some good contributions and also to connect with all you great people in the numpy community. Any suggestions and tips are always welcome. Thanks and Regards

2 1

ANN: pvlib v0.7.2
by Dr. Mark Alexander Mikofski PhD April 23, 2020

April 23, 2020

pvlib has a new minor release, v0.7.2 Release Notes: https://pvlib-python.readthedocs.io/en/v0.7.2/whatsnew.html PyPI: https://pypi.org/project/pvlib/ Read the Docs: https://pvlib-python.readthedocs.io/en/latest/ GitHub: https://github.com/pvlib/pvlib-python Highlights: - add new module pvlib.snow to contain models related to snow coverage and effects on a PV system. (GH764< https://github.com/pvlib/pvlib-python/pull/764>) - Renamed pvlib.losses to pvlib.soiling. Additional loss models will go into code modules named for the loss or effect type. (GH935< https://github.com/pvlib/pvlib-python/issues/935>, GH891< https://github.com/pvlib/pvlib-python/issues/891>) - updated compatibility with cftime 1.1. (GH895< https://github.com/pvlib/pvlib-python/issues/895>) There are a few breaking API changes and bug fixes. Users are advised to read the release notes before updating. ---------- Forwarded message --------- From: Stark, Cameron Thomas via Python-announce-list < python-announce-list(a)python.org> Date: Wed, Apr 22, 2020, 5:58 PM Subject: pvlib v0.7.2 To: Cc: Stark, Cameron Thomas <ctstark(a)sandia.gov> pvlib has a new minor release, v0.7.2 Release Notes: https://pvlib-python.readthedocs.io/en/v0.7.2/whatsnew.html PyPI: https://pypi.org/project/pvlib/ Read the Docs: https://pvlib-python.readthedocs.io/en/latest/ GitHub: https://github.com/pvlib/pvlib-python Highlights: - add new module pvlib.snow to contain models related to snow coverage and effects on a PV system. (GH764< https://github.com/pvlib/pvlib-python/pull/764>) - Renamed pvlib.losses to pvlib.soiling. Additional loss models will go into code modules named for the loss or effect type. (GH935< https://github.com/pvlib/pvlib-python/issues/935>, GH891< https://github.com/pvlib/pvlib-python/issues/891>) - updated compatibility with cftime 1.1. (GH895< https://github.com/pvlib/pvlib-python/issues/895>) There are a few breaking API changes and bug fixes. Users are advised to read the release notes before updating. -- Python-announce-list mailing list -- python-announce-list(a)python.org To unsubscribe send an email to python-announce-list-leave(a)python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Support the Python Software Foundation: http://www.python.org/psf/donations/

1 0

NumPy Development Meeting - Triage Focus
by Sebastian Berg April 21, 2020

April 21, 2020

Hi all, Our bi-weekly triage-focused NumPy development meeting is tomorrow (Wednesday, April 22) 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

1 0

NEP 41: Is there still need to discuss DTypes vs. Scalars (or DType classes)?
by Sebastian Berg April 21, 2020

April 21, 2020

Hi all, the week has passed, and it has been discussed quite a bit longer, so I assume that NEP 41 can effectively be accepted. Even then, I will bring up one point again. I hope that if there is still need for discussion, it will hopefully happen in a timely manner, so that, I can go ahead with some changes proposed in NEP 41, and in the event of more concrete doubts/issues there will only be few changes that need to be undone. I would hate to revert large amount of work, simply because an important point/issue is raised in two months instead of two weeks. This whole thing is fairly complex, so please do not hesitate to ask for clarifications! I am also very happy to do a video conference with anyone interested at any time, or chat in private on Slack. So just in case: I will be available around 11:00 PDT (18 UTC) this Thursday on the NumPy Community Call zoom link [0]. As far as I am aware, there was only one (maybe 2, see point 2. below which may be independent) discussion points. In my proposal the DType class (i.e. `type(np.dtype("float64")`), is the core concept and different for every scalar type. It holds all the information on how to deal with array elements. This is some duplication of scalar types and it means that there would be (usually) exactly one DType for each (NumPy) scalar, possibly exposed using: np.dtype[scalar_type] e.g. np.dtype[np.float64] That does create a certain duality. For each scalar type/class, there is a corresponding DType class. And in theory the scalar does not even need to know that NumPy has a DType for it. From a typing theoretical point of view this is also a bit strange. The type of each array element is identical to the scalar type! But although there is only one type, there are two distinct classes: one for the scalar value, and one to explain them to NumPy and store them in an array. I lean in that direction because: 1. I wanted to modify scalars as little as possible, I am not sure we will enable this initially, but this is so that: * In principle you can create a DType for every Python type without touching the original Python scalar. * The scalar need not know about NumPy or DTypes thus creating no new dependency. (you can use the scalar without installing NumPy) 2. I somewhat like that DType classes have methods that get a "self" instance argument and are provided with the data by the array. * This makes functions `dtype.__get_array_item__(item_memory)` is implemented like a method: class DType: def __get_array_item__(self, item_memory): return item * There is an alternative approach to this, that I did not think about much, though. `item_memory` really is much like a scalar instance (it holds the actual value), so you can argue that `item_memory` is `self` here, and the dtype instance is the type of `item_memory` (the self). E.g. making `__get_array_item__` live on the dtype (not on the class). The dtype thus is the type/class of the array element. This is beautiful, but, in generally you still need to pass the dtype instance itself. For example strings cannot interpret without knowing their length. In other words, the scalar `self` is actually the tuple `(item_memory, dtype)`, which I think is why at least I do not have a clear grasp here. [1] 3. There may be `dtypes` without specific scalar types. I am not sure this is actually a tidy theoretical concept, but an example is the current Pandas Categorical. The type of the scalars within a categorical array are arbitrary. I am not actually sure that is theoretically tidy. E.g. Python uses `enum.Enum`, a class factory, for a similar purpose, and you have to use the `.value` attribute. But, desirable or not, it would seem less straight forward to potentially allow if we design this around the scalar type. The main downside to using DTypes as proposed in NEP 41 in my opinion is what I mentioned first: We must have a DType class for every scalar class, even though at least most scalars (i.e. all NumPy scalars, except the `object` dtype) can easily be expanded into including all necessary information, maybe they already include almost all of it. In the NEP 41 framework the scalar could be build from the DType in practice. Which may seem a bit strange. In general Scalar<->DType will form a Unit of a sort. And this means that somewhere we have to map scalars to DTypes. So, in many ways, I actually do find the scalar version tidier myself. But, I also find the "there is a DType class for every scalar type/class" a straight forward user story even if there will be subtle difference between DType and scalar class/type. The point 2. may be independent of the whole scalar story, I am conflating it here, because to me it applies more naturally in that context. Cheers, Sebastian [0] See the community meeting agenda document for the link: https://hackmd.io/76o-IxCjQX2mOXO_wwkcpg [1] These are thoughts mainly from: https://gist.github.com/eric-wieser/49c55bcab744b0e782f6c2740603180b#what-t… and a discussion on the pull request, and I will not claim to represent them quite correctly and especially fully here.

2 1