At my job, we have 1577 Callable type hints scattered in 1063 Python files.
For comparison, this codebase also has 2754 dict annotations and 1835 list
ones.
On Mon, Dec 20, 2021 at 8:11 AM Christopher Barker
wrote:
> note: I wasn't thinking -- typeshed, of course, has a lot more than the
>
note: I wasn't thinking -- typeshed, of course, has a lot more than the
standard lib. But it's still a collection of widely used somewhat general
purpose libraries. So I think my hypothesis is still valid.
-CHB
On Sun, Dec 19, 2021 at 8:54 PM Christopher Barker
wrote:
> A question that came
A question that came up for me is:
How common is it to need to use Callable for type hints? particularly
complex versions, specifying what parameters the Callable takes? A more
compact and easier to read syntax is nice, but not very important if it
isn't used much.
My first thought on this was
These are binary wheel installs though, no? Which means 3.8 version and
3.10 version were compiled at different times, even for the same NumPy
version. Also for different platforms, I don't know which you are on.
I haven't checked what's on PyPI for each version. I think PyFFT is largely
using
> On 12/18/2021 3:13 PM, Batuhan Taskaya wrote:
>
> > tl;dr: I find it very troubling that we are going on a path where need
> > to increase the language complexity (syntax) only in the cause
> > 'easier' typing.
Which brings up the question is whether it's worth adding syntax for
typing, but
On Sun, Dec 19, 2021 at 1:46 PM MRAB wrote:
> On 2021-12-19 20:06, Tigran Aivazian wrote:
> > So far I have narrowed it down to a block of code in solve.py doing a
> lot of multi-threaded FFT (i.e. with fft(..., threads=6) of pyFFTW), as
> well as numpy exp() and other functions and pure Python
On 2021-12-19 20:06, Tigran Aivazian wrote:
So far I have narrowed it down to a block of code in solve.py doing a lot of multi-threaded FFT
(i.e. with fft(..., threads=6) of pyFFTW), as well as numpy exp() and other functions and pure
Python heavy list manipulation (yes, lists, not numpy
I have got it narrowed down to the "threads=6" argument of fft() and ifft()
functions of pyFFTW! Namely, if I do NOT pass "threads=6" to fft()/iff(), then
the parallel execution of multiple instances of the scripts is the same in
Python 3.8 and 3.10. But it is a bit slower than with
So far I have narrowed it down to a block of code in solve.py doing a lot of
multi-threaded FFT (i.e. with fft(..., threads=6) of pyFFTW), as well as numpy
exp() and other functions and pure Python heavy list manipulation (yes, lists,
not numpy arrays). All of this together (or some one part of
On 12/19/21 06:46, aivazian.tig...@gmail.com wrote:
> Hello,
>
> Being a programmer myself I realise that a report on performance degradation
> should ideally contain a small test program that clearly reproduces the
> problem. However, unfortunately, I do not have the time at present to isolate
I have created four different sets of initial data, one for each thread of
execution and no, unfortunately, that does NOT solve the problem. Still, when
four threads are executed in parallel, 3.8 outperforms 3.10 by a factor of 2.4.
So, there is some other point of contention between the
I think I have found something very interesting. Namely, I removed all
multiprocessing (which is done in the shell script, not in Python) and so
reduced the program to just a single thread of execution. And lo and behold,
Python 3.10 now consistently beats 3.8 by about 5%. However, this is not
On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote:
> To eliminate the possibility of being affected by the different
> versions of numpy I have just now upgraded numpy in Python 3.8
> environment to the latest version, so both 3.8 and 3.10 and using
> numpy 1.21.4 and still the timing is
Not the version, but the build. Did you compile NumPy from source using the
same compiler with both Python versions? If not, that remains my strong
hunch about performance difference.
Given what your programs do, it sure seems like the large majority of
runtime is spent in supporting numeric
In both cases I installed numpy using "sudo -H pip install numpy". And just now
I upgraded numpy in 3.8 using "sudo -H pip3.8 install --upgrade numpy".
I will try to simplify the program by removing all the higher level complexity
and see what I find.
Alas, it is exactly the same as previously reported, so the problem persists.
If it was exactly the same between Python versions I would celebrate and shout
for joy, seeing that the problem is narrowed down to numpy.
I can carefully upgrade all the other packages in 3.8 to match those in 3.10.
"Exactly the same" between Python versions, or exactly the same as
previously reported?
On Sun, 2021-12-19 at 18:48 +, Tigran Aivazian wrote:
> To eliminate the possibility of being affected by the different
> versions of numpy I have just now upgraded numpy in Python 3.8
> environment to the
To eliminate the possibility of being affected by the different versions of
numpy I have just now upgraded numpy in Python 3.8 environment to the latest
version, so both 3.8 and 3.10 and using numpy 1.21.4 and still the timing is
exactly the same.
___
My guess is that this difference is predominantly different builds of
NumPy. For example, the Intel optimized builds are very good, and a speed
difference of the magnitude shown in this note are typical. E.g.
On Sun, Dec 19, 2021, 11:49 AM Steven D'Aprano
> And both the download and the webpage listing the checksum are over https.
> If we don't trust https, the whole internet is broken and changing to a
> stronger checksum won't help. A hypothetical MITM attacker capable of
> breaking https and
Hello,
Being a programmer myself I realise that a report on performance degradation
should ideally contain a small test program that clearly reproduces the
problem. However, unfortunately, I do not have the time at present to isolate
the issue to a small test case. But the good news (or bad
On Wed, 15 Dec 2021, 3:18 am Eric Snow, wrote:
> Hi all,
>
> I'm still hoping to land a per-interpreter GIL for 3.11. There is
> still a decent amount of work to be done but little of it will require
> solving any big problems:
>
> * pull remaining static globals into _PyRuntimeState and
22 matches
Mail list logo
