Re: [Numpy-discussion] 2020 NumPy survey results

[Ralf Gommers]

On Tue, Jun 22, 2021 at 11:41 PM Inessa Pawson  wrote:

> Hi, everyone!
> In 2020, the NumPy survey team in partnership with students and faculty
> from a Master’s course in Survey Methodology jointly hosted by the
> University of Michigan and the University of Maryland conducted the first
> official NumPy community survey. Over 1,200 users from 75 countries
> participated to help us map out a landscape of the NumPy community and
> voiced their thoughts about the future of the project.
>
> We are finally ready to share with you the findings of this survey. You
> can read the full report here: https://numpy.org/user-survey-2020.
>

Thank you Inessa and everyone who participated! The end result looks
amazing and is super valuable. It took a little while to complete, but such
is the nature of open source work - it's usually more complicated than
expected, and real life commitments come first. The quality of the final
pdf report, the infographic, and the detailed per-question analysis far
exceeded my expectations.

Cheers,
Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 2020 NumPy survey results

[Charles R Harris]

On Tue, Jun 22, 2021 at 3:41 PM Inessa Pawson  wrote:

> Hi, everyone!
> In 2020, the NumPy survey team in partnership with students and faculty
> from a Master’s course in Survey Methodology jointly hosted by the
> University of Michigan and the University of Maryland conducted the first
> official NumPy community survey. Over 1,200 users from 75 countries
> participated to help us map out a landscape of the NumPy community and
> voiced their thoughts about the future of the project.
>
> We are finally ready to share with you the findings of this survey. You
> can read the full report here: https://numpy.org/user-survey-2020.
>
> The inaugural NumPy community survey was an effort of an international
> group of volunteers who showed a remarkable dedication to the project
> amidst the extraordinary challenges of the year 2020. Each is listed
> alphabetically by type of contribution.
>
> *Survey Design and Analysis*
> Ross Barnowski
> Sebastian Berg
> Xiaoyi Deng
> Ralf Gommers
> Stephanie Mendoza
> Inessa Pawson
> Deji Suolang
> Mame Fatou Thiam
>
> *Translations*
> Eric Depagne
> Xiaoyi Deng
> Yuki Dunn
> Kiko Correoso Garcia
> Jose Guzman
> Andrei Ivanov
> Paul Ivanov
> Siddhartha Kapoor
> Tetsuo Koyama
> Guilherme Leobas
> Dayane Machado
> Mahfuza Humayra Mohona
> Aerik Pawson
> Inessa Pawson
> Zijie Poh
> Sumera Priyadarsini
> Fabrice Silva
> Shaloo Shalini
> Kriti Singh
> Alexandre de Siqueira
>
> *Special thanks*
> Frederick Conrad (Survey Research Center, Institute for Social Research,
> University of Michigan)
> Danuta Dzierżanowska
> Jim Lepkowski (Survey Research Center, Institute for Social Research,
> University of Michigan)
> Claire McKay Bowen (Urban Institute)
> Michael Traugott (Survey Research Center, Institute for Social Research,
> University of Michigan)
>
> Also, a huge thank you to everyone who took part in this survey. We
> couldn’t do it without your support.
>
> Inessa Pawson
> NumPy Survey Team
>
>
Very nice and quite informative. There went my morning . . .

Chuck
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] 2020 NumPy survey results

[Melissa Mendonça]

Huge thanks to Inessa and the entire survey team for their work on this!

There is a lot of good information to guide possible future actions... :)

Best,

- Melissa

On Wed, Jun 23, 2021 at 1:37 PM Charles R Harris 
wrote:

>
>
> On Tue, Jun 22, 2021 at 3:41 PM Inessa Pawson  wrote:
>
>> Hi, everyone!
>> In 2020, the NumPy survey team in partnership with students and faculty
>> from a Master’s course in Survey Methodology jointly hosted by the
>> University of Michigan and the University of Maryland conducted the first
>> official NumPy community survey. Over 1,200 users from 75 countries
>> participated to help us map out a landscape of the NumPy community and
>> voiced their thoughts about the future of the project.
>>
>> We are finally ready to share with you the findings of this survey. You
>> can read the full report here: https://numpy.org/user-survey-2020.
>>
>> The inaugural NumPy community survey was an effort of an international
>> group of volunteers who showed a remarkable dedication to the project
>> amidst the extraordinary challenges of the year 2020. Each is listed
>> alphabetically by type of contribution.
>>
>> *Survey Design and Analysis*
>> Ross Barnowski
>> Sebastian Berg
>> Xiaoyi Deng
>> Ralf Gommers
>> Stephanie Mendoza
>> Inessa Pawson
>> Deji Suolang
>> Mame Fatou Thiam
>>
>> *Translations*
>> Eric Depagne
>> Xiaoyi Deng
>> Yuki Dunn
>> Kiko Correoso Garcia
>> Jose Guzman
>> Andrei Ivanov
>> Paul Ivanov
>> Siddhartha Kapoor
>> Tetsuo Koyama
>> Guilherme Leobas
>> Dayane Machado
>> Mahfuza Humayra Mohona
>> Aerik Pawson
>> Inessa Pawson
>> Zijie Poh
>> Sumera Priyadarsini
>> Fabrice Silva
>> Shaloo Shalini
>> Kriti Singh
>> Alexandre de Siqueira
>>
>> *Special thanks*
>> Frederick Conrad (Survey Research Center, Institute for Social Research,
>> University of Michigan)
>> Danuta Dzierżanowska
>> Jim Lepkowski (Survey Research Center, Institute for Social Research,
>> University of Michigan)
>> Claire McKay Bowen (Urban Institute)
>> Michael Traugott (Survey Research Center, Institute for Social Research,
>> University of Michigan)
>>
>> Also, a huge thank you to everyone who took part in this survey. We
>> couldn’t do it without your support.
>>
>> Inessa Pawson
>> NumPy Survey Team
>>
>>
> Very nice and quite informative. There went my morning . . .
>
> Chuck
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

Perhaps it is also worth going back to explore our original motivation for 
making this change.

One reason was that Sebastian didn't like people doing `x.shape = ...`.  Users 
do that, presumably, to trigger an error if a copy needs to be made.  However, 
we can catch that already:

x = np.reshape(y, ...)
if np.may_share_memory(x, y):
...

We can fix Sebastian's issue by introducing a `copy` keyword to `reshape`, 
which currently has none:

x = np.reshape(y, copy='never')

For consistency, it would be nice to have `np.array` support copy=never, but if 
there is no urgency we can take the long route towards an API that uses strings 
(consistent with the rest of NumPy).

The arguments against string names *right now* is that, if users write code 
with `copy='if-needed'` it will not work correctly with old NumPy code, since 
old versions will evaluate `if-needed` to True.  The assessment was that this 
happens frequently, but we should consider how frequently, and how big of an 
issue it is.

So, I guess ultimately I am wondering if the change to `np.array` is needed 
right now, or whether we can get away without it for a while.

Stéfan

On Tue, Jun 22, 2021, at 15:21, bas van beek wrote:
> > Stefan, that sketch is more complicated than it needs to be - `np.copy` is 
> > a python function, so you can just attach the attributes directly! 
> > (although maybe there are implications for static typing)
> 
> For the type annotations we can simply use something akin to Stéfans proposed 
> `NpCopy` class; 
> probably in combination with `Protocol`.
> It's a bit more work compared to annotating a normal python function, but 
> it's quite easy nevertheless.
> 
> Regards, Bas
> 
> 
> *From:* NumPy-Discussion 
>  on behalf of 
> Eric Wieser 
> *Sent:* 21 June 2021 18:56
> *To:* Discussion of Numerical Python 
> *Subject:* Re: [Numpy-discussion] copy="never" discussion and no deprecation 
> cycle? 
>  
> 
> Stefan, that sketch is more complicated than it needs to be - `np.copy` is a 
> python function, so you can just attach the attributes directly! (although 
> maybe there are implications for static typing)
> ```
> class CopyFlag(enum.Enum):
> IF_NEEDED = 0
> ALWAYS = 1
> NEVER = 2
> 
> np.copy.IF_NEEDED = CopyFlag.IF_NEEDED
> np.copy.ALWAYS = CopyFlag.ALWAYS
> np.copy.NEVER = CopyFlag.NEVER
> ```
> It would also work nicely for the `True/False/other` version that was 
> proposed in the much older PR as `np.never_copy`:
> ```
> class _CopyNever:
> def __bool__(self): raise ValueError
> 
> np.copy.NEVER = _CopyNever()
> ```
> 
> All of these versions (and using the enum directly) seem fine to me.
> If we go down the enum route route, we probably want to add "new-style" 
> versions of `np.CLIP` and friends that are true enums / live within a more 
> obvious namespace.
> 
> Eric 
> 
> On Mon, 21 Jun 2021 at 17:24, Stefan van der Walt  
> wrote:
>> On Sun, Jun 20, 2021, at 20:46, Gagandeep Singh wrote:
>> > I have recently joined the mailing list and have gone through the previous 
>> > discussions on this thread. I would like to share my analysis (advantages 
>> > and disadvantages) of three possible alternatives (Enum, String, boolean) 
>> > to support the proposed feature.
>> 
>> Thanks for this thorough analysis, Gagandeep!
>> 
>> I'll throw one more heretical idea out there:
>> 
>> `np.copy.IF_NEEDED`, `np.copy.ALWAYS`, `np.copy.NEVER`.
>> 
>> This has the advantages of the enum, doesn't pollute the global namespace, 
>> and has an intuitive name.
>> 
>> `np.array(x, copy=np.copy.ALWAYS)`
>> 
>> It would be slightly more awkward to type, but is doable.  A rough Python 
>> version sketch would be:
>> 
>> class CopyFlag(enum.Enum):
>> IF_NEEDED = 0
>> ALWAYS = 1
>> NEVER = 2
>> 
>> class NpCopy:
>> IF_NEEDED : CopyFlag = CopyFlag.IF_NEEDED
>> ALWAYS : CopyFlag = CopyFlag.ALWAYS
>> NEVER : CopyFlag = CopyFlag.NEVER
>> 
>> def __call__(self, x):
>> return ...whatever copy returns...
>> 
>> np.copy = NpCopy()
>> 
>> 
>> Stéfan
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
> 
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

[Numpy-discussion] NumPy 1.21.0 release

[Charles R Harris]

Hi All,

On behalf of the NumPy team I am pleased to announce the release of NumPy
1.21.0. The highlights are


   - continued SIMD work covering more functions and platforms,
   - initial work on the new dtype infrastructure and casting,
   - universal2 wheels for Python 3.8 and Python 3.9 on Mac,
   - improved documentation,
   - improved annotations,
   - new ``PCG64DXSM`` bitgenerator for random numbers.


This NumPy release is the result of 581 merged pull requests contributed by
175 people. The Python versions supported for this release are 3.7-3.9,
support for Python 3.10 will be added after Python 3.10 is released. Wheels
can be downloaded from PyPI ; source
archives, release notes, and wheel hashes are available on Github
. Linux users will
need pip >= 0.19.3 in order to install manylinux2010 and manylinux2014
wheels.

*Contributors*

A total of 175 people contributed to this release.  People with a "+" by
their
names contributed a patch for the first time.


   - @8bitmp3 +
   - @DWesl +
   - @Endolith
   - @Illviljan +
   - @Lbogula +
   - @Lisa +
   - @Patrick +
   - @Scian +
   - @h-vetinari +
   - @h6197627 +
   - @jbCodeHub +
   - @legoffant +
   - @sfolje0 +
   - @tautaus +
   - @yetanothercheer +
   - Abhay Raghuvanshi +
   - Adrian Price-Whelan +
   - Aerik Pawson +
   - Agbonze Osazuwa +
   - Aitik Gupta +
   - Al-Baraa El-Hag
   - Alex Henrie
   - Alexander Hunt +
   - Alizé Papp +
   - Allan Haldane
   - Amarnath1904 +
   - Amrit Krishnan +
   - Andras Deak
   - AngelGris +
   - Anne Archibald
   - Anthony Vo +
   - Antony Lee
   - Atharva-Vidwans +
   - Ayush Verma +
   - Bas van Beek
   - Bharat Raghunathan
   - Bhargav V +
   - Brian Soto
   - Carl Michal +
   - Charles Harris
   - Charles Stern +
   - Chiara Marmo +
   - Chris Barnes +
   - Chris Vavaliaris
   - Christina Hedges +
   - Christoph Gohlke
   - Christopher Dahlin +
   - Christos Efstathiou +
   - Chunlin Fang
   - Constanza Fierro +
   - Daniel Evans +
   - Daniel Montes +
   - Dario Mory +
   - David Carlier +
   - David Stansby
   - Deepyaman Datta +
   - Derek Homeier
   - Dong Keun Oh +
   - Dylan Cutler +
   - Eric Larson
   - Eric Wieser
   - Eva Jau +
   - Evgeni Burovski
   - FX Coudert +
   - Faris A Chugthai +
   - Filip Ter +
   - Filip Trojan +
   - François Le Lay +
   - Ganesh Kathiresan
   - Giannis Zapantis +
   - Giulio Procopio +
   - Greg Lucas +
   - Hollow Man +
   - Holly Corbett +
   - I-Shen Leong +
   - Inessa Pawson
   - Isabela Presedo-Floyd
   - Ismael Jimenez +
   - Isuru Fernando
   - Jakob Jakobson
   - James Gerity +
   - Jamie Macey +
   - Jasmin Classen +
   - Jody Klymak +
   - Joseph Fox-Rabinovitz
   - Jérome Eertmans +
   - Jérôme Kieffer +
   - Kamil Choudhury +
   - Kasia Leszek +
   - Keller Meier +
   - Kenichi Maehashi
   - Kevin Sheppard
   - Kulin Seth +
   - Kumud Lakara +
   - Laura Kopf +
   - Laura Martens +
   - Leo Singer +
   - Leonardus Chen +
   - Lima Tango +
   - Lumir Balhar +
   - Maia Kaplan +
   - Mainak Debnath +
   - Marco Aurélio da Costa +
   - Marta Lemanczyk +
   - Marten van Kerkwijk
   - Mary Conley +
   - Marysia Winkels +
   - Mateusz Sokół +
   - Matt Haberland
   - Matt Hall +
   - Matt Ord +
   - Matthew Badin +
   - Matthias Bussonnier
   - Matthias Geier
   - Matti Picus
   - Matías Ríos +
   - Maxim Belkin +
   - Melissa Weber Mendonça
   - Meltem Eren Copur +
   - Michael Dubravski +
   - Michael Lamparski
   - Michal W. Tarnowski +
   - Michał Górny +
   - Mike Boyle +
   - Mike Toews
   - Misal Raj +
   - Mitchell Faas +
   - Mukulikaa Parhari +
   - Neil Girdhar +
   - Nicholas McKibben +
   - Nico Schlömer
   - Nicolas Hug +
   - Nilo Kruchelski +
   - Nirjas Jakilim +
   - Ohad Ravid +
   - Olivier Grisel
   - Pamphile ROY +
   - Panos Mavrogiorgos +
   - Patrick T. Komiske III +
   - Pearu Peterson
   - Peter Hawkins +
   - Raghuveer Devulapalli
   - Ralf Gommers
   - Raúl Montón Pinillos +
   - Rin Arakaki +
   - Robert Kern
   - Rohit Sanjay
   - Roman Yurchak
   - Ronan Lamy
   - Ross Barnowski
   - Ryan C Cooper
   - Ryan Polley +
   - Ryan Soklaski
   - Sabrina Simao +
   - Sayed Adel
   - Sebastian Berg
   - Shen Zhou +
   - Stefan van der Walt
   - Sylwester Arabas +
   - Takanori Hirano
   - Tania Allard +
   - Thomas J. Fan +
   - Thomas Orgis +
   - Tim Hoffmann
   - Tomoki, Karatsu +
   - Tong Zou +
   - Touqir Sajed +
   - Tyler Reddy
   - Wansoo Kim
   - Warren Weckesser
   - Weh Andreas +
   - Yang Hau
   - Yashasvi Misra +
   - Zolboo Erdenebaatar +
   - Zolisa Bleki


Cheers,

Charles Harris
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Juan Nunez-Iglesias]

Personally I was a fan of the Enum approach. People dislike it because it is 
not “Pythonic”, but imho that is an accident of history because Enums only 
appeared (iirc) in Python 3.4. In fact, they are the right data structure for 
this particular problem, so for my money we should *make it* Pythonic by 
starting to use it everywhere where we have a finite list of choices.

Juan.

> On 24 Jun 2021, at 4:09 am, Stefan van der Walt  wrote:
> 
> Perhaps it is also worth going back to explore our original motivation for 
> making this change.
> 
> One reason was that Sebastian didn't like people doing `x.shape = ...`.  
> Users do that, presumably, to trigger an error if a copy needs to be made.  
> However, we can catch that already:
> 
> x = np.reshape(y, ...)
> if np.may_share_memory(x, y):
>...
> 
> We can fix Sebastian's issue by introducing a `copy` keyword to `reshape`, 
> which currently has none:
> 
> x = np.reshape(y, copy='never')
> 
> For consistency, it would be nice to have `np.array` support copy=never, but 
> if there is no urgency we can take the long route towards an API that uses 
> strings (consistent with the rest of NumPy).
> 
> The arguments against string names *right now* is that, if users write code 
> with `copy='if-needed'` it will not work correctly with old NumPy code, since 
> old versions will evaluate `if-needed` to True.  The assessment was that this 
> happens frequently, but we should consider how frequently, and how big of an 
> issue it is.
> 
> So, I guess ultimately I am wondering if the change to `np.array` is needed 
> right now, or whether we can get away without it for a while.
> 
> Stéfan
> 
> On Tue, Jun 22, 2021, at 15:21, bas van beek wrote:
>>> Stefan, that sketch is more complicated than it needs to be - `np.copy` is 
>>> a python function, so you can just attach the attributes directly! 
>>> (although maybe there are implications for static typing)
>> 
>> For the type annotations we can simply use something akin to Stéfans 
>> proposed `NpCopy` class; 
>> probably in combination with `Protocol`.
>> It's a bit more work compared to annotating a normal python function, but 
>> it's quite easy nevertheless.
>> 
>> Regards, Bas
>> 
>> 
>> *From:* NumPy-Discussion 
>>  on behalf of 
>> Eric Wieser 
>> *Sent:* 21 June 2021 18:56
>> *To:* Discussion of Numerical Python 
>> *Subject:* Re: [Numpy-discussion] copy="never" discussion and no deprecation 
>> cycle? 
>> 
>> 
>> Stefan, that sketch is more complicated than it needs to be - `np.copy` is a 
>> python function, so you can just attach the attributes directly! (although 
>> maybe there are implications for static typing)
>> ```
>> class CopyFlag(enum.Enum):
>>IF_NEEDED = 0
>>ALWAYS = 1
>>NEVER = 2
>> 
>> np.copy.IF_NEEDED = CopyFlag.IF_NEEDED
>> np.copy.ALWAYS = CopyFlag.ALWAYS
>> np.copy.NEVER = CopyFlag.NEVER
>> ```
>> It would also work nicely for the `True/False/other` version that was 
>> proposed in the much older PR as `np.never_copy`:
>> ```
>> class _CopyNever:
>>def __bool__(self): raise ValueError
>> 
>> np.copy.NEVER = _CopyNever()
>> ```
>> 
>> All of these versions (and using the enum directly) seem fine to me.
>> If we go down the enum route route, we probably want to add "new-style" 
>> versions of `np.CLIP` and friends that are true enums / live within a more 
>> obvious namespace.
>> 
>> Eric 
>> 
>> On Mon, 21 Jun 2021 at 17:24, Stefan van der Walt  
>> wrote:
>>> On Sun, Jun 20, 2021, at 20:46, Gagandeep Singh wrote:
 I have recently joined the mailing list and have gone through the previous 
 discussions on this thread. I would like to share my analysis (advantages 
 and disadvantages) of three possible alternatives (Enum, String, boolean) 
 to support the proposed feature.
>>> 
>>> Thanks for this thorough analysis, Gagandeep!
>>> 
>>> I'll throw one more heretical idea out there:
>>> 
>>> `np.copy.IF_NEEDED`, `np.copy.ALWAYS`, `np.copy.NEVER`.
>>> 
>>> This has the advantages of the enum, doesn't pollute the global namespace, 
>>> and has an intuitive name.
>>> 
>>> `np.array(x, copy=np.copy.ALWAYS)`
>>> 
>>> It would be slightly more awkward to type, but is doable.  A rough Python 
>>> version sketch would be:
>>> 
>>> class CopyFlag(enum.Enum):
>>>IF_NEEDED = 0
>>>ALWAYS = 1
>>>NEVER = 2
>>> 
>>> class NpCopy:
>>>IF_NEEDED : CopyFlag = CopyFlag.IF_NEEDED
>>>ALWAYS : CopyFlag = CopyFlag.ALWAYS
>>>NEVER : CopyFlag = CopyFlag.NEVER
>>> 
>>>def __call__(self, x):
>>>return ...whatever copy returns...
>>> 
>>> np.copy = NpCopy()
>>> 
>>> 
>>> Stéfan
>>> ___
>>> NumPy-Discussion mailing list
>>> NumPy-Discussion@python.org
>>> https://mail.python.org/mailman/listinfo/numpy-discussion
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>> 
> _

Re: [Numpy-discussion] NumPy 1.21.0 release

[Tyler Reddy]

Thanks Chuck!
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Stefan van der Walt]

On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote:
> Personally I was a fan of the Enum approach. People dislike it because 
> it is not “Pythonic”, but imho that is an accident of history because 
> Enums only appeared (iirc) in Python 3.4. In fact, they are the right 
> data structure for this particular problem, so for my money we should 
> *make it* Pythonic by starting to use it everywhere where we have a 
> finite list of choices.

The enum definitely feels like the right abstraction. But the resulting API is 
clunky because of naming and top-level scarcity.

Hence the suggestion to tag it onto np.copy, but there is an argument to be 
made for consistency by placing all enums under np.flags or similar.

Still, np.flags.copy.IF_NEEDED gets long.

Stéfan 
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Benjamin Root]

> One reason was that Sebastian didn't like people doing `x.shape = ...`.
> Users do that, presumably, to trigger an error if a copy needs to be made.


Users do that because it is 1) easier than every other option, and 2) I am
pretty sure we were encouraged to do it this way for the past 10 years. The
whole "it won't copy" business (to me at least) was an added bonus. Most of
the time, I didn't want to copy anyway, so, sure!

`x.shape = ...` has been around for a long time, and you are going to have
a hard time convincing people to drop using such an easy-to-use property
setter in favor of an approach that adds more typing and takes a bit more
to read. There's also lots and lots of online tutorials, books, and
stackoverflow snippets that have this usage pattern. I think the horse has
long since left the barn, the chickens came to roost, and the cows came
home...


> We can fix Sebastian's issue by introducing a `copy` keyword to `reshape`,
> which currently has none:
>
>
This isn't a terrible idea to pursue, regardless of what I said above!
Explicit is better than implicit, and giving programmers the opportunity to
be explicit about what sort of copy semantics they intend in more places
would improve the library going forward.  I also like to highlight what
Chuck said a few posts ago about the fact that `copy=False` does not really
mean what people might think it means, and taking steps to address that
might also be good for the library.

Ben Root
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Benjamin Root]

Why not both? The definition of the enum might live in a proper namespace
location, but I see no reason why `np.copy.IF_NEEDED =
np.flags.CopyFlgs.IF_NEEDED` can't be done (I mean, adding the enum members
as attributes to the `np.copy()` function). Seems perfectly reasonable to
me, and reads pretty nicely, too. It isn't like we are dropping support for
the booleans, so those are still around for easy typing.

Ben Root

On Wed, Jun 23, 2021 at 10:26 PM Stefan van der Walt 
wrote:

> On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote:
> > Personally I was a fan of the Enum approach. People dislike it because
> > it is not “Pythonic”, but imho that is an accident of history because
> > Enums only appeared (iirc) in Python 3.4. In fact, they are the right
> > data structure for this particular problem, so for my money we should
> > *make it* Pythonic by starting to use it everywhere where we have a
> > finite list of choices.
>
> The enum definitely feels like the right abstraction. But the resulting
> API is clunky because of naming and top-level scarcity.
>
> Hence the suggestion to tag it onto np.copy, but there is an argument to
> be made for consistency by placing all enums under np.flags or similar.
>
> Still, np.flags.copy.IF_NEEDED gets long.
>
> Stéfan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] copy="never" discussion and no deprecation cycle?

[Gagandeep Singh]

To me, adding enums as attributes of the `np.copy` function seems like a
pretty good idea. This trick might resolve the only relatively important
issue with Enums. Then, the benefits of Enum might outweigh the
disadvantage of uncommon of usage of Enums in NumPy APIs. As an end user, I
would like Enums rather than strings as the former would provide fixed
number of choices (hence, easy debugging) as compared to the latter (in
which case, infinite choices for passing strings and the code may work
silently, imagine, passing, `if_neded` instead of `if_needed` and it
working perfectly fine (silently). This thing has happened to me while
using another library.

On Thu, Jun 24, 2021 at 8:05 AM Benjamin Root  wrote:

> Why not both? The definition of the enum might live in a proper namespace
> location, but I see no reason why `np.copy.IF_NEEDED =
> np.flags.CopyFlgs.IF_NEEDED` can't be done (I mean, adding the enum members
> as attributes to the `np.copy()` function). Seems perfectly reasonable to
> me, and reads pretty nicely, too. It isn't like we are dropping support for
> the booleans, so those are still around for easy typing.
>
> Ben Root
>
> On Wed, Jun 23, 2021 at 10:26 PM Stefan van der Walt 
> wrote:
>
>> On Wed, Jun 23, 2021, at 18:01, Juan Nunez-Iglesias wrote:
>> > Personally I was a fan of the Enum approach. People dislike it because
>> > it is not “Pythonic”, but imho that is an accident of history because
>> > Enums only appeared (iirc) in Python 3.4. In fact, they are the right
>> > data structure for this particular problem, so for my money we should
>> > *make it* Pythonic by starting to use it everywhere where we have a
>> > finite list of choices.
>>
>> The enum definitely feels like the right abstraction. But the resulting
>> API is clunky because of naming and top-level scarcity.
>>
>> Hence the suggestion to tag it onto np.copy, but there is an argument to
>> be made for consistency by placing all enums under np.flags or similar.
>>
>> Still, np.flags.copy.IF_NEEDED gets long.
>>
>> Stéfan
>> ___
>> NumPy-Discussion mailing list
>> NumPy-Discussion@python.org
>> https://mail.python.org/mailman/listinfo/numpy-discussion
>>
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
___
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion