Hi Michael,

> Python on Windows is and is supposed to be, as far as I get it, a dying
platform.
I would join Matti in thinking that it is a misconception.

Have you heard of the enormous daily updated unofficial repository
<https://www.lfd.uci.edu/~gohlke/pythonlibs/> of the binary windows
compilations of
almost 600 python libraries by Christoph Gohlke? (numpy and libs depending
on it are built with MKL there)
It is there for a reason.

If you look at the stats such as this one (Matti already mentioned them
while I was writing this text),

https://www.jetbrains.com/research/python-developers-survey-2018/
https://www.jetbrains.com/lp/python-developers-survey-2020/

you'll see (in addition to the fact that numpy is the #1 library in data
science ;) ) that in
the recent years the percentage of windows user among the developers is
quite high:
69% linux - 47% windows - 32% macos (2018)
68% linux - 48% windows - 29% macos (2020)
So it looks as if it is rather growing than dying.

This is due to the popularity of the above mentioned data science and AI,
which have skyrocketed in the
last 10 years. And the vast majority of data scientists work on windows.

Windows as a platform for developers as a whole is also quite flourishing
today.
According to the stackoverflow 2021 developer survey
<https://insights.stackoverflow.com/survey/2021#most-popular-technologies-op-sys>
45% of the respondents use Windows (25% linux, 25% macos).
Among the professional developers the numbers are 41% for windows, 30%
macos, 26% linux.

Also the primary audience of the tutorials like mine (as well as of
stackoverflow?) are windows users.
Linux users can easily figure things described there on their own, through
the docstrings, source code
or, as a last resort, through the docs )

>The more experienced the Python developers are, the more likely they are
to use Linux and macOS as development
> environments, and the less likely they are to choose Windows.
(from the same jetbrains survey of 2018)

I wouldn't like to go into holy wars, though. I'm equally literate in both
unix and windows (somewhat less in macos)
and in my opinion the interests of all the users of the the three operating
systems should be taken into account
in both the code of the library and the docs.

The documentation is sometimes pretty ignorant of mac/windows users, btw:
> Alias on this platform (Linux x86_64)
https://numpy.org/doc/stable/reference/arrays.scalars.html#numpy.int_
And what about the other platforms?

As for the particular issue of the difference in the default integer types,
in my opinion the default choice of int32 on windows for
array [1,2,3] fits the description

>" If not given, then the type will be determined as the minimum type
required to hold the objects in the sequence."
https://numpy.org/doc/stable/reference/generated/numpy.array.html

better than int64 on linux/macos.

Best regards,
Lev


On Sun, Dec 26, 2021 at 8:45 PM Michael Siebert <michael.sieber...@gmail.com>
wrote:

> Hey Lev,
>
> I‘ve forgotten to mention my MacBook M1,
> it‘s also int64 there.
>
> Python on Windows is and is supposed to be, as far as I get it, a dying
> platform. A billion things are broken there (HDF comes to my mind) and it
> seems even Microsoft wants developers to move away from native Windows with
> their introduction of WSL (Windows Subsystem for Linux). Its latest
> version, WSL2 even comes with an actual Linux kernel and since Windows 11,
> it has support for graphical applications (Xorg) out of the box. With
> Visual Studio Code (also Microsoft) and it’s remote capabilities, one does
> not even feel a difference between developing in an Ubuntu in a WSL in
> Windows and an actual Ubuntu.
>
> Considering the „traditional“ C datatypes, fixed types and prioritizing
> them in Numpy documentation, that‘s what my issue (see below) is about. I
> think they have summarized it nicely in
>
> https://matt.sh/howto-c
>
> Best regards, Michael
>
> On 26. Dec 2021, at 13:49, Lev Maximov <lev.maxi...@gmail.com> wrote:
>
> 
> Dear Michael,
>
> Thank you for your feedback!
>
> I've fixed the x86_64 typo.
>
> I'll think how to reformulate the int32 part. I work on debian x86_64 and
> windows 10 64bit. Constructing an array with np.array([1,2,3]) as well as
> np.array([1,2,3], dtype=np.int_) gives me int64 dtype on linux, and int32
> on windows.
>
> As suggested by Matti, I've put the rst source (and images) into a
> separate github repository
>
> https://github.com/axil/numpy-data-types
>
> PRs are welcome. My primary concern is to exclude serious typos/mistakes
> that might mislead/harm the readers if used.
>
> My personal preference is towards explicit width types like np.int32, but
> from reading the docs I have a feeling there's a trend of migrating towards
> the c-style notation.
>
> Best regards,
> Lev
>
> On Sun, Dec 26, 2021 at 7:05 PM Michael Siebert <
> michael.sieber...@gmail.com> wrote:
>
>> Dear Lev,
>>
>> thank you a lot! Something like this should be part of the Numpy
>> documentation. I like the diagram, looks very nice! Also, I’ve opened an
>> issue regarding data types
>>
>> https://github.com/numpy/numpy/issues/20662
>>
>> Some feedback from my side:
>>
>> 1. When calling numpy.array([1,2,3,4]) it gives me an int64 data type
>> most of the time (two x86_64 systems, one arm64 system). The only time I’ve
>> got int32 was on a Raspberry Pi, which is a software limitation, since the
>> CPU is 64 bit and they have even replaced their so-far 32bit only Raspberry
>> Pi Zero with a 64bit version (yes, one day Raspberry OS with 64 bit might
>> actually become the default!). I don’t know what machine you are working
>> on, but int64 should be the default.
>> 2. x64 refers to the obsolete Intel Itanium architecture (mentioned
>> once). Should be x86_64.
>> 3. np.errstate looks nice, I could use that for my pull request as well.
>>
>> Many thanks & best regards, Michael
>>
>>
>> On 25. Dec 2021, at 10:02, Lev Maximov <lev.maxi...@gmail.com> wrote:
>>
>> Hi everyone,
>>
>> I'm almost done with the article about numpy types – something I haven't
>> covered in Numpy Illustrated.
>>
>> Would someone please have a look to confirm I haven't written anything
>> anti-climatic there?
>>
>> https://axil.github.io/numpy-data-types.html
>>
>> --
>> Best regards,
>> Lev
>>
>> PS Earlier today I've mistakenly sent an email with the wrong link.
>> _______________________________________________
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: michael.sieber...@gmail.com
>>
>>
>> _______________________________________________
>> NumPy-Discussion mailing list -- numpy-discussion@python.org
>> To unsubscribe send an email to numpy-discussion-le...@python.org
>> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
>> Member address: lev.maxi...@gmail.com
>>
> _______________________________________________
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: michael.sieber...@gmail.com
>
> _______________________________________________
> NumPy-Discussion mailing list -- numpy-discussion@python.org
> To unsubscribe send an email to numpy-discussion-le...@python.org
> https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
> Member address: lev.maxi...@gmail.com
>
_______________________________________________
NumPy-Discussion mailing list -- numpy-discussion@python.org
To unsubscribe send an email to numpy-discussion-le...@python.org
https://mail.python.org/mailman3/lists/numpy-discussion.python.org/
Member address: arch...@mail-archive.com

Reply via email to