date:20220104

[Python-Dev] Re: Python 3.11.0a4 is blocked

2022-01-04 Thread Mark Shannon


Hi Pablo,

Issue 43683 should not have been marked as a release blocker, as it is a 
performance issue, not a bug.

The related bug (which was a release blocker) is 
https://bugs.python.org/issue46009, and was fixed a while ago.

Cheers,
Mark.

On 04/01/2022 11:12 pm, Pablo Galindo Salgado wrote:

Hi everyone,

I am writing this to notify you that unfortunately the release of 3.11.0a4 is 
blocked as there are a bunch of release blockers
(some of them affect Python 3.10):

https://bugs.python.org/issue46263 
https://bugs.python.org/issue46208 
https://bugs.python.org/issue46006 
https://bugs.python.org/issue43683 

If this was a single release blocker I would think about moving forward but 
unfortunately, there are several of them and one of
them is that Python fails to compile FreeBSD, so I am halting the release until 
these are fixed.

Regards from rainy London,
Pablo Galindo Salgado

___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7OWGAL4UL5HNKKQFUGH6N6L4JDVPEN7R/
Code of Conduct: http://python.org/psf/codeofconduct/


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/HHKP32L4VE6UCQKQRLV5POC7CAMHSNIT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.11.0a4 is blocked

2022-01-04 Thread Pablo Galindo Salgado

Hi everyone,

I am writing this to notify you that unfortunately the release of 3.11.0a4
is blocked as there are a bunch of release blockers
(some of them affect Python 3.10):

https://bugs.python.org/issue46263
https://bugs.python.org/issue46208
https://bugs.python.org/issue46006
https://bugs.python.org/issue43683

If this was a single release blocker I would think about moving forward but
unfortunately, there are several of them and one of
them is that Python fails to compile FreeBSD, so I am halting the release
until these are fixed.

Regards from rainy London,
Pablo Galindo Salgado
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/7OWGAL4UL5HNKKQFUGH6N6L4JDVPEN7R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: RFC on Callable Syntax PEP

2022-01-04 Thread Petr Viktorin

On Thu, Dec 16, 2021 at 6:57 PM Steven Troxler  wrote:
>
> Hello all,
>
> Thanks everyone for comments on our earlier thread [1] about callable type 
> syntax. We now  have a draft PEP [2] proposing an arrow-based syntax for 
> callable types, for example:
>
> ```
> (int, str) -> bool # equivalent to Callable[[int, str], bool]
> ```
>
> In support of the PEP we also have:
> - a reference implementation of the parser [3] to ensure the grammar is 
> correct  (tests [5], [6], [7])
> - a detailed specification of planned runtime behavior [4], which is not yet 
> in the reference implementation
>
> We'd like to get your feedback about the PEP in general, and especially 
> details and edge cases we need to consider regarding runtime behavior.
>
> Cheers,
> Steven Troxler
>
> -
> [1] Earlier python-dev thread 
> https://mail.python.org/archives/list/python-dev@python.org/thread/VBHJOS3LOXGVU6I4FABM6DKHH65GGCUB/
> [2] PEP 677: https://www.python.org/dev/peps/pep-0677/
> [3] Reference implementation of Parser: 
> https://github.com/stroxler/cpython/tree/callable-type-syntax--shorthand
> [4] Details on the runtime behavior:  
> https://docs.google.com/document/d/15nmTDA_39Lo-EULQQwdwYx_Q1IYX4dD5WPnHbFG71Lk/edit
>
> [5] Ast tests for parser changes:
> https://github.com/stroxler/cpython/blob/20eb59fdca0d6d8dbe4efa3b04038c7c22024654/Lib/test/test_ast.py#L359-L392
> [6] Easy-read tests of examples from the PEP: 
> https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Lib/test/test_callable_type_examples_for_pep.py
> [7] Test sanity checking hundreds of examples pulled from typeshed:
> https://github.com/stroxler/cpython/blob/callable-type-syntax--shorthand/Lib/test/test_callable_type_examples_for_pep.py

Having a symbol (->) for typing when a similar expression uses a word
(lambda) seems somewhat backwards to me.
If wonder: back when lambda was added, were symbols like ->
considered? If so, how do the arguments for `lambda` vs. a symbol
compare with arguments for `Callable` vs. an arrow?

I also wonder how many of the cases would be made much more readable
by naming the callable type -- as you would do with any complex
expression -- especially if PEP 646 Variadic Generics enables you to
create specialized callable types like AsyncCallable or Decorator. For
example, this would be quite clear to me:

Customizer = AsyncCallable[[Response, list[UserSetting]], Response]
def customize_response(
response: Response,
customizer: Customizer,
) -> Response:
   ...

Naming probably won't help too much with more abstract higher-order
functions like the flat_map example. But, if `(int) -> list[int]`
makes things clear to you, Haskell might be a better choice than
Python...

---

BTW, has anyone thought about using a colon to parametrize Callable?
Callable[[Response, list[UserSetting]]: Response]
/joke
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/LTZWNG2G2BEUXIBWNM4JGOEETV2BH3T6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

2022-01-04 Thread Gregory P. Smith

On Tue, Jan 4, 2022 at 3:24 AM Tal Einat  wrote:

> I have a spare RPi zero that I could try to set up as a buildbot. Would
> that be useful?
>

No need. We've already got a 32-bit raspbian bot, adding another wouldn't
add value. The rpi0/1/2 are too slow to compile on anyways.

-gps

On Tue, Jan 4, 2022 at 10:59 AM Antoine Pitrou  wrote:
>
>> On Mon, 3 Jan 2022 22:40:25 -0800
>> "Gregory P. Smith"  wrote:
>> >
>> > rerunning a mere few of those in --rigorous mode for more runs does not
>> > significantly improve the stddev so I'm not going to let that finish.
>>
>> The one benchmark that is bigint-heavy is pidigits AFAIK, so you might
>> want to re-run that one if you want a more rigorous confirmation that
>> there is no regression.
>>
>> > my recommendation: proceed with removing 15-bit bignum digit support.
>> > 30-bit only future with simpler better code here we come.
>>
>> Sounds reasonable to me as well.
>>
>> Regards
>>
>> Antoine.
>>
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@python.org/message/MRE5HF3XRKJBEHF3YJNGXWXECLX7GQGG/
>> Code of Conduct: http://python.org/psf/codeofconduct/
>>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/FPYXF33EKE23AUYPALAOKDLGKE7LGUGX/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FZ7WAQGF6UVPVNG7SHIYTYWYBZXAPJSV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

2022-01-04 Thread Guido van Rossum

Perhaps relevant for perspective:

We did some review of the pyperformance benchmarks based on how noisy they
are:
https://github.com/faster-cpython/ideas/discussions/142

Note that pidigits is the noisiest -- its performance changes up to 11% for
no good reason. The regex bms are also very noisy.

On Mon, Jan 3, 2022 at 10:44 PM Gregory P. Smith  wrote:

>
> On Sun, Jan 2, 2022 at 2:37 AM Mark Dickinson  wrote:
>
>> On Sat, Jan 1, 2022 at 9:05 PM Antoine Pitrou  wrote:
>>
>>> Note that ARM is merely an architecture with very diverse
>>> implementations having quite differing performance characteristics.
>>>  [...]
>>>
>>
>> Understood. I'd be happy to see timings on a Raspberry Pi 3, say. I'm not
>> too worried about things like the RPi Pico - that seems like it would be
>> more of a target for MicroPython than CPython.
>>
>> Wikipedia thinks, and the ARM architecture manuals seem to confirm, that
>> most 32-bit ARM instruction sets _do_ support the UMULL
>> 32-bit-by-32-bit-to-64-bit multiply instruction. (From
>> https://en.wikipedia.org/wiki/ARM_architecture#Arithmetic_instructions:
>> "ARM supports 32-bit × 32-bit multiplies with either a 32-bit result or
>> 64-bit result, though Cortex-M0 / M0+ / M1 cores don't support 64-bit
>> results.") Division may still be problematic.
>>
>
> It's rather irrelevant anyways, the pi zero/one is the lowest spec arm
> that matters at all. Nobody is ever going to ship something worse than that
> capable of running CPython.
>
> Anyways I ran actual benchmarks on a pi3. On 32-bit raspbian I build
> CPython 3.10 with no configure flags and with --enable-big-digits (or
> however that's spelled) for 30-bit digits and ran pyperformance 1.0.2 on
> them.
>
> Caveat: This is not a good system to run benchmarks on.  widely variable
> performance (it has a tiny heatsink which never meaningfully got hot), and
> the storage is a random microsd card. Each full pyperformance run took 6
> hours. :P
>
> Results basically say: no notable difference.  Most do not change and the
> variability (look at those stddev's and how they overlap on the few things
> that produced a "significant" result at all) is quite high.  Things wholly
> unrelated to integers such as the various regex benchmarks showing up as
> faster demonstrate the unreliability of the numbers.  And also at how
> pointless caring about this fine level of detail for performance is on this
> platform.
>
> ```
> pi@pi3$ pyperf compare_to 15bit.json 30bit.json
> 2to3: Mean +- std dev: [15bit] 7.88 sec +- 0.39 sec -> [30bit] 8.02 sec +-
> 0.36 sec: 1.02x slower
> crypto_pyaes: Mean +- std dev: [15bit] 3.22 sec +- 0.34 sec -> [30bit]
> 3.40 sec +- 0.22 sec: 1.06x slower
> fannkuch: Mean +- std dev: [15bit] 13.4 sec +- 0.5 sec -> [30bit] 13.8 sec
> +- 0.5 sec: 1.03x slower
> pickle_list: Mean +- std dev: [15bit] 74.7 us +- 22.1 us -> [30bit] 85.7
> us +- 15.5 us: 1.15x slower
> pyflate: Mean +- std dev: [15bit] 19.6 sec +- 0.6 sec -> [30bit] 19.9 sec
> +- 0.6 sec: 1.01x slower
> regex_dna: Mean +- std dev: [15bit] 2.99 sec +- 0.24 sec -> [30bit] 2.81
> sec +- 0.22 sec: 1.06x faster
> regex_v8: Mean +- std dev: [15bit] 520 ms +- 71 ms -> [30bit] 442 ms +-
> 115 ms: 1.18x faster
> scimark_monte_carlo: Mean +- std dev: [15bit] 3.31 sec +- 0.24 sec ->
> [30bit] 3.22 sec +- 0.24 sec: 1.03x faster
> scimark_sor: Mean +- std dev: [15bit] 6.42 sec +- 0.34 sec -> [30bit] 6.27
> sec +- 0.33 sec: 1.03x faster
> spectral_norm: Mean +- std dev: [15bit] 4.85 sec +- 0.31 sec -> [30bit]
> 4.74 sec +- 0.20 sec: 1.02x faster
> unpack_sequence: Mean +- std dev: [15bit] 1.42 us +- 0.42 us -> [30bit]
> 1.60 us +- 0.33 us: 1.13x slower
>
> Benchmark hidden because not significant (47): chameleon, chaos,
> deltablue, django_template, dulwich_log, float, go, hexiom, json_dumps,
> json_loads, logging_format, logging_silent, logging_simple, mako,
> meteor_contest, nbody, nqueens, pathlib, pickle, pickle_dict,
> pickle_pure_python, pidigits, python_startup, python_startup_no_site,
> raytrace, regex_compile, regex_effbot, richards, scimark_fft, scimark_lu,
> scimark_sparse_mat_mult, sqlalchemy_declarative, sqlalchemy_imperative,
> sqlite_synth, sympy_expand, sympy_integrate, sympy_sum, sympy_str, telco,
> tornado_http, unpickle, unpickle_list, unpickle_pure_python,
> xml_etree_parse, xml_etree_iterparse, xml_etree_generate, xml_etree_process
> ```
>
> rerunning a mere few of those in --rigorous mode for more runs does not
> significantly improve the stddev so I'm not going to let that finish.
>
> my recommendation: proceed with removing 15-bit bignum digit support.
> 30-bit only future with simpler better code here we come.
>
> -gps
>
>
>>
>> --
>> Mark
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python.org/mailman3/lists/python-dev.python.org/
>> Message archived at
>> https://mail.python.org/archives/list/python-dev@p

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

2022-01-04 Thread Tal Einat

I have a spare RPi zero that I could try to set up as a buildbot. Would
that be useful?

On Tue, Jan 4, 2022 at 10:59 AM Antoine Pitrou  wrote:

> On Mon, 3 Jan 2022 22:40:25 -0800
> "Gregory P. Smith"  wrote:
> >
> > rerunning a mere few of those in --rigorous mode for more runs does not
> > significantly improve the stddev so I'm not going to let that finish.
>
> The one benchmark that is bigint-heavy is pidigits AFAIK, so you might
> want to re-run that one if you want a more rigorous confirmation that
> there is no regression.
>
> > my recommendation: proceed with removing 15-bit bignum digit support.
> > 30-bit only future with simpler better code here we come.
>
> Sounds reasonable to me as well.
>
> Regards
>
> Antoine.
>
>
> ___
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-le...@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/MRE5HF3XRKJBEHF3YJNGXWXECLX7GQGG/
> Code of Conduct: http://python.org/psf/codeofconduct/
>
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/FPYXF33EKE23AUYPALAOKDLGKE7LGUGX/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

2022-01-04 Thread Antoine Pitrou

On Mon, 3 Jan 2022 22:40:25 -0800
"Gregory P. Smith"  wrote:
> 
> rerunning a mere few of those in --rigorous mode for more runs does not
> significantly improve the stddev so I'm not going to let that finish.

The one benchmark that is bigint-heavy is pidigits AFAIK, so you might
want to re-run that one if you want a more rigorous confirmation that
there is no regression.

> my recommendation: proceed with removing 15-bit bignum digit support.
> 30-bit only future with simpler better code here we come.

Sounds reasonable to me as well.

Regards

Antoine.


___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at 
https://mail.python.org/archives/list/python-dev@python.org/message/MRE5HF3XRKJBEHF3YJNGXWXECLX7GQGG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python 3.11.0a4 is blocked

[Python-Dev] Python 3.11.0a4 is blocked

[Python-Dev] Re: RFC on Callable Syntax PEP

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

7 matches

Site Navigation

Mail list logo

Footer information