[Numpy-discussion] ANN: pvlib v0.7.2
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-l...@python.org> Date: Wed, Apr 22, 2020, 5:58 PM Subject: pvlib v0.7.2 To: Cc: Stark, Cameron Thomas 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-l...@python.org To unsubscribe send an email to python-announce-list-le...@python.org https://mail.python.org/mailman3/lists/python-announce-list.python.org/ Support the Python Software Foundation: http://www.python.org/psf/donations/ ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
[Numpy-discussion] Update the Code of Conduct Committee Membership (new members wanted)
Hi all, it has come up in the last community call that many of our committee membership lists have not been updated in a while. This is not a big issue as such. But, while these committees are not very active on a day-to-day basis, they are an important part of the community and it is better to update them regularly and thus also ensure they remain representative of the community. We would like to start by updating the members of the Code of Conduct (CoC) committee. The CoC committee is in charge of responding and following up to any reports of CoC breaches, as stated in: https://docs.scipy.org/doc/numpy/dev/conduct/code_of_conduct.html#incident-reporting-resolution-code-of-conduct-enforcement If you are interested in or happy to serve on our CoC committee please let me or e.g. Ralf Gommers know, join the next community meeting (April 29th, 11:00PDT/18:00UTC), or reply on the list. I hope we will be able to discuss and reach a consensus between those interested and involved quickly (possibly already on the next community call). In either case, before any changes they will be run by the mailing list to ensure community consensus. Cheers, Sebastian ___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Proposal: add `force=` or `copy=` kwarg to `__array__` interface
Hi everyone, > One bit of expressivity we would miss is “copy if necessary, but otherwise > don’t bother”, but there are workarounds to this. After a side discussion with Stéfan van der Walt, we came up with `allow_copy=True`, which would express to the downstream library that we don’t mind waiting, but that zero-copy would also be ok. > This sounds like the sort of thing that is use case driven. If enough > projects want to use it, then I have no objections to adding the keyword. > OTOH, we need to be careful about adding too many interoperability tricks as > they complicate the code and makes it hard for folks to determine the best > solution. Interoperability is a hot topic and we need to be careful not put > too leave behind too many experiments in the NumPy code. Do you have any > other ideas of how to achieve the same effect? Personally, I don’t have any other ideas, but would be happy to hear some! My view regarding API/experiment creep is that `__array__` is the oldest and most basic of all the interop tricks and that this can be safely maintained for future generations. Currently it only takes `dtype=` as a keyword argument, so it is a very lean API. I think this particular use case is very natural and I’ve encountered the reluctance to implicitly copy twice, so I expect it is reasonably common. Regarding difficulty in determining the best solution, I would be happy to contribute to the dispatch basics guide together with the new kwarg. I agree that the protocols are getting quite numerous and I couldn’t find a single place that gathers all the best practices together. But, to reiterate my point: `__array__` is the simplest of these and I think this keyword is pretty safe to add. For ease of discussion, here are the API options discussed so far, as well as a few extra that I don’t like but might trigger other ideas: np.asarray(my_duck_array, allow_copy=True) # default is False, or None -> leave it to the duck array to decide np.asarray(my_duck_array, copy=True) # always copies, but, if supported by the duck array, defers to it for the copy np.asarray(my_duck_array, copy=‘allow’) # could take values ‘allow’, ‘force’, ’no’, True(=‘force’), False(=’no’) np.asarray(my_duck_array, force_copy=False, allow_copy=True) # separate concepts, but unclear what force_copy=True, allow_copy=False means! np.asarray(my_duck_array, force=True) Juan.___ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
