[Python-Dev] Re: Retiring this mailing list ?

[Marc-Andre Lemburg]

Hello everyone,

the python-dev mailing list has now been put into read-only mode and
archived.

The discussions have moved on to Discourse. Please follow-up there:

https://discuss.python.org/c/core-dev/23

Thanks to everyone who participated in discussions on this list over the
years. The archives will remain available for reference and software
archeologists:

https://mail.python.org/archives/list/python-dev@python.org/

Thanks,
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 25 2023)

Python Projects, Coaching and Support ...https://www.egenix.com/
Python Product Development ...https://consulting.egenix.com/



::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/




On 13.11.2023 11:17, Marc-Andre Lemburg wrote:

Hello everyone,

for quite a while now, core discussions have moved to Discourse and 
people are obviously enjoying things there:


https://discuss.python.org/c/core-dev/23

The Discourse mailing list mode works reasonably well, so is a suitable 
replacement for this mailing list.


Posts to this list are now mostly spam, mailer error reports and the 
occasional release postings:


https://mail.python.org/archives/list/python-dev@python.org/latest
(you can't see much of the spam, since we filter most of it)


Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

Thanks,

___
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/GUU3JS5W6KOCGXV3JJRHT2UTDJTXRLY7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Marc-Andre Lemburg]

On 13.11.2023 16:47, Guido van Rossum wrote:

But how would Tim Peters keep himself entertained in his retirement?
Oh, he's on Discourse as well :-) and I'm sure he'd appreciate not 
having to moderate this list anymore (he's one of the other 3 maintainers).


Seriously, let’s kill it. I thought it was already deprecated.
I'll wait until next week and then get the process of archiving the list 
going.


--Guido (mobile)


On Mon, Nov 13, 2023 at 02:19 Marc-Andre Lemburg  wrote:

Hello everyone,

for quite a while now, core discussions have moved to Discourse and
people are obviously enjoying things there:

https://discuss.python.org/c/core-dev/23

The Discourse mailing list mode works reasonably well, so is a
suitable
replacement for this mailing list.

Posts to this list are now mostly spam, mailer error reports and the
occasional release postings:

https://mail.python.org/archives/list/python-dev@python.org/latest
(you can't see much of the spam, since we filter most of it)


Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

Thanks,
-- 
Marc-Andre Lemburg

eGenix.com

Professional Python Services directly from the Experts (#1, Nov 13
2023)
 >>> Python Projects, Coaching and Support ... https://www.egenix.com/
 >>> Python Product Development ... https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and
costs :::

    eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
     D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
            Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/

___
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/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
Code of Conduct: http://python.org/psf/codeofconduct/


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


--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 16 2023)

Python Projects, Coaching and Support ...https://www.egenix.com/
Python Product Development ...https://consulting.egenix.com/



::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48

D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/UEOM2F523L3ZYFJKU7BENBKY5NTPHTXM/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Marc-Andre Lemburg]

On 14.11.2023 19:21, Steve Holden wrote:

On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg  wrote:

[...]

Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

[...]

Hi Marc-Andre,

Maybe just require senders to be members of the python.org 
 domain, and retain the release announcements?
Well, the point is to reduce maintenance and keeping the ML alive would 
not lower this effort, since we get quite a bit of spam to the list.


Kind regards,
Steve

PS: Your mail triggered a visit to 
https://www.python.org/community/lists/ - it seems it could use some 
updates. For example, comp.lang.python-announce is a news URL, which 
in this day and age will baffle most visitors! At the very least 
the page could point to the Discourse list.


Yes, the page could use some editing.

c.l.p.a does have a corresponding ML associated with it. It's probably 
better to point to that instead of the newsgroup.


If you have suggestions for edits, please forward them offline. I can 
then put them up there.


Thanks,

--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 15 2023)

Python Projects, Coaching and Support ...https://www.egenix.com/
Python Product Development ...https://consulting.egenix.com/



::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48

D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/
___
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/RMQEC3Z3POPSYIYAGWSUME6QSFGY4TOW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Baptiste Carvello]

Le 13/11/2023 à 11:17, Marc-Andre Lemburg a écrit :
> Hello everyone,

Hello,

> for quite a while now, core discussions have moved to Discourse and
> people are obviously enjoying things there: […]

Enjoying is a big word. I for one am more or less coping with it, using
rss for now (read-only and with holes in discussions).

> The Discourse mailing list mode works reasonably well, so is a suitable
> replacement for this mailing list.

It is not, as every user needs to waste time configuring category
filters, which most won't do anyway. Those problems were discussed here
some months ago, to no avail. Discourse is designed for logged-in
reading with the web interface, everything else is second class citizen.

> Posts to this list are now mostly spam, mailer error reports and the
> occasional release postings:

This is sadly the fact.

> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)

Indeed.

Cheers,
Baptiste
___
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/R6HLH7I7LSQJ2TBOHD7E4BJPL4YWSOTY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Barry Warsaw]

Yep, fine with me too.

-Barry

> On Nov 13, 2023, at 02:17, Marc-Andre Lemburg  wrote:
> 
> Hello everyone,
> 
> for quite a while now, core discussions have moved to Discourse and people 
> are obviously enjoying things there:
> 
> https://discuss.python.org/c/core-dev/23
> 
> The Discourse mailing list mode works reasonably well, so is a suitable 
> replacement for this mailing list.
> 
> Posts to this list are now mostly spam, mailer error reports and the 
> occasional release postings:
> 
> https://mail.python.org/archives/list/python-dev@python.org/latest
> (you can't see much of the spam, since we filter most of it)
> 
> 
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
> 
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
> 
> Professional Python Services directly from the Experts (#1, Nov 13 2023)
> >>> Python Projects, Coaching and Support ...https://www.egenix.com/
> >>> Python Product Development ...https://consulting.egenix.com/
> 
> 
> ::: We implement business ideas - efficiently in both time and costs :::
> 
>   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>   Registered at Amtsgericht Duesseldorf: HRB 46611
>   https://www.egenix.com/company/contact/
> https://www.malemburg.com/
> 
> ___
> 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/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/BGHNYRDHQ2CHWQEVNHTCEWZ2S5FVLK2B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Senthil Kumaran]

On Mon, Nov 13, 2023 at 2:21 AM Marc-Andre Lemburg  wrote:

> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)

+1 to retiring and archiving.

Less overhead for maintainers and information concentrated at a single
source, that is, discuss.python.org .

Thanks,
Senthil
___
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/ZAGR7F6V6SKAYEBYGQIWHZKEFVGTBFBY/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Eric V. Smith via Python-Dev]

On 11/14/2023 1:21 PM, Steve Holden wrote:

On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg  wrote:

[...]

Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

[...]

Hi Marc-Andre,

Maybe just require senders to be members of the python.org 
 domain, and retain the release announcements?


I think the python-announce list serves that purpose. Any time there's 
an announcement here, I also see a separate copy of it on 
python-announce (where I'm a moderator).


Eric
___
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/SHV5KJIBK67IYSCPTFDO5HEQV6YKM76O/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Steve Holden]

On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg  wrote:

> [...]
>
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
>
> [...]

Hi Marc-Andre,

Maybe just require senders to be members of the python.org domain, and
retain the release announcements?

Kind regards,
Steve

PS: Your mail triggered a visit to https://www.python.org/community/lists/
- it seems it could use some updates. For example,
comp.lang.python-announce is a news URL, which in this day and age will
baffle most visitors! At the very least the page could point to the
Discourse list.
___
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/SXLIZEV2Y6NHYYFWAMWL43JIIHR2AODD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Retiring this mailing list ?

[Guido van Rossum]

But how would Tim Peters keep himself entertained in his retirement?

Seriously, let’s kill it. I thought it was already deprecated.

--Guido (mobile)


On Mon, Nov 13, 2023 at 02:19 Marc-Andre Lemburg  wrote:

> Hello everyone,
>
> for quite a while now, core discussions have moved to Discourse and
> people are obviously enjoying things there:
>
> https://discuss.python.org/c/core-dev/23
>
> The Discourse mailing list mode works reasonably well, so is a suitable
> replacement for this mailing list.
>
> Posts to this list are now mostly spam, mailer error reports and the
> occasional release postings:
>
> https://mail.python.org/archives/list/python-dev@python.org/latest
> (you can't see much of the spam, since we filter most of it)
>
>
> Question: Should we retire and archive this mailing list ?
> (I'm asking as one of the maintainers of the ML)
>
> Thanks,
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Nov 13 2023)
>  >>> Python Projects, Coaching and Support ...https://www.egenix.com/
>  >>> Python Product Development ...https://consulting.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
> eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
>  D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
> Registered at Amtsgericht Duesseldorf: HRB 46611
> https://www.egenix.com/company/contact/
>   https://www.malemburg.com/
>
> ___
> 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/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
> 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/ZMDHUGHVBAK3KBY6V4CMPCXIWU6PD5RE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Retiring this mailing list ?

[Marc-Andre Lemburg]

Hello everyone,

for quite a while now, core discussions have moved to Discourse and 
people are obviously enjoying things there:


https://discuss.python.org/c/core-dev/23

The Discourse mailing list mode works reasonably well, so is a suitable 
replacement for this mailing list.


Posts to this list are now mostly spam, mailer error reports and the 
occasional release postings:


https://mail.python.org/archives/list/python-dev@python.org/latest
(you can't see much of the spam, since we filter most of it)


Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)

Thanks,
--
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Nov 13 2023)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   https://www.egenix.com/company/contact/
 https://www.malemburg.com/

___
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/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Proposal: Allow non-default after default arguments

[Samuel T.]

+1 on this. Typeshed is full of examples of extra overloads due to this. Mainly 
because of a case where a parameter with a default argument isn't actually 
optional (ie, using the default argument would necessary lead to an error). 
openpyxl stubs in particular is chockful of them.
___
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/KCH45DFSBMHFTEMQADTAN7XPIHLF2RHJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: detecting statements which result is not stored

[Steve Holden]

Sounds like you might want the "Python Help" group on https;//
discuss.python.org - the dev conversation migrated there quite a while ago
now, so thighs channel is more or less announcements only.

Good luck with your project!

Kind regards,
Steve


On Thu, 5 Oct 2023 at 16:07, Guenther Sohler 
wrote:

>
> Hi Python Developers, after  some investigation i consider dev the correct
> mailing list.
> I got python embedded into OpenSCAD and i'd like to make more use out of
> it.
>
> statements like these do exactly what they should:
>
> width= 3*5
> solid = make_nice_solid(width)
> other_solid = solid.size(1)
> print(" Everything fine")
>
> But i'd like to be able to write lines like these:  These are expressions
> which create a value,
> which is apparently NOT stored in a variable
>
> solid *3
> other_solid - solid
>
> instead of wasting them, I'd like to collect them in an array and display
> send it to the display engine
> after  python evaluation has  finished.
>
> Is there some way how i can collect the orphaned expressions ?
>
>
>
> ___
> 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/D7GI2EAE73OSYOQI7QKQOCB6SRRYOUWV/
> 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/MOXK3OETDDEI24VOM2OY726REYBFOVSF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] detecting statements which result is not stored

[Guenther Sohler]

Hi Python Developers, after  some investigation i consider dev the correct
mailing list.
I got python embedded into OpenSCAD and i'd like to make more use out of it.

statements like these do exactly what they should:

width= 3*5
solid = make_nice_solid(width)
other_solid = solid.size(1)
print(" Everything fine")

But i'd like to be able to write lines like these:  These are expressions
which create a value,
which is apparently NOT stored in a variable

solid *3
other_solid - solid

instead of wasting them, I'd like to collect them in an array and display
send it to the display engine
after  python evaluation has  finished.

Is there some way how i can collect the orphaned expressions ?
___
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/D7GI2EAE73OSYOQI7QKQOCB6SRRYOUWV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.5, 3.10.13, 3.9.18, and 3.8.18 is now available

[Łukasz Langa]

There’s security content in the releases, let’s dive right in.

gh-108310 : Fixed an issue 
where instances of ssl.SSLSocket 
 were 
vulnerable to a bypass of the TLS handshake and included protections (like 
certificate verification) and treating sent unencrypted data as if it were 
post-handshake TLS encrypted data. Security issue reported as CVE-2023-40217 1 
 by Aapo Oksman. 
Patch by Gregory P. Smith.
Upgrading is highly recommended to all users of affected versions.

 
Python
 3.11.5

Get it here: https://www.python.org/downloads/release/python-3115/

This release was held up somewhat by the resolution of this CVE, which is why 
it includes a whopping 328 new commits since 3.11.4 (compared to 238 commits 
between 3.10.4 and 3.10.5). Among those, there is a fix for CVE-2023-41105 
which affected 
Python 3.11.0 - 3.11.4. See gh-106242 
 for details.

There are also some fixes for crashes, check out the change log 
 to see all 
information.

Most importantly, the release notes on the downloads page 
 include a description 
of the Larmor precession. I understood some of the words there!

 
Python
 3.10.13

Get it here: https://www.python.org/downloads/release/python-31013/

16 commits.

 
Python
 3.9.18

Get it here: https://www.python.org/downloads/release/python-3918/

11 commits.

 
Python
 3.8.18

Get it here: https://www.python.org/downloads/release/python-3818/

9 commits.

 
Stay
 safe and upgrade!

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

--
Łukasz Langa @ambv 
on behalf of your friendly release team,

Ned Deily @nad 
Steve Dower @steve.dower 
Pablo Galindo Salgado @pablogsal 
Łukasz Langa @ambv 
Thomas Wouters @thomas 


signature.asc
Description: Message signed with OpenPGP
___
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/2VDJP6JU7DO7PKIVZQMVD6H3F2MDDQZQ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.12.0 release candidate 1 released

[Thomas Wouters]

 I'm pleased to announce the release of Python 3.12.0rc1:
https://www.python.org/downloads/release/python-3120rc1/
This is the first release candidate of Python 3.12.0

This release, *3.12.0rc1*, is the penultimate release preview. Entering the
release candidate phase, only reviewed code changes which are clear bug
fixes are allowed between this release candidate and the final release. The
second candidate (and the last planned release preview) is scheduled for
Monday, 2023-09-04, while the official release of 3.12.0 is scheduled for
Monday, 2023-10-02.

There will be *no ABI changes* from this point forward in the 3.12 series,
and the goal is that there will be as few code changes as possible.
Call
to action

We strongly encourage maintainers of third-party Python projects to prepare
their projects for 3.12 compatibilities during this phase, and where
necessary publish Python 3.12 wheels on PyPI to be ready for the final
release of 3.12.0. Any binary wheels built against Python 3.12.0rc1 will
work with future versions of Python 3.12. As always, report any issues to the
Python bug tracker .

Please keep in mind that this is a preview release and while it’s as close
to the final release as we can get it, its use is *not* recommended for
production environments.
Core
developers: time to work on documentation now

   - Are all your changes properly documented?
   - Are they mentioned in What’s New
   ?
   - Did you notice other changes you know of to have insufficient
   documentation?

Major
new features of the 3.12 series, compared to 3.11
New
features

   - More flexible f-string parsing
   
,
   allowing many things previously disallowed (PEP 701
   ).
   - Support for the buffer protocol
   

   in Python code (PEP 688 ).
   - A new debugging/profiling API (PEP 669
   ).
   - Support for isolated subinterpreters
   

   with separate Global Interpreter Locks (PEP 684
   ).
   - Even more improved error messages
   .
   More exceptions potentially caused by typos now make suggestions to the
   user.
   - Support for the Linux perf profiler
    to report
   Python function names in traces.
   - Many large and small performance improvements
    (like PEP
   709 ), delivering an estimated 5%
   overall performance improvementcitation needed.

Type
annotations

   - New type annotation syntax
   

   for generic classes (PEP 695 ).
   - New override decorator
   

   for methods (PEP 698 ).


Deprecations

   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   . The setuptools package continues to
   provide the distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods  have
   been removed.
   - Invalid backslash escape sequences in strings now warn with
   SyntaxWarning instead of DeprecationWarning, making them more visible.
   (They will become syntax errors in the future.)
   - The internal 

[Python-Dev] Re: Some pattern annoyance

[Christian Tismer-Sperling]

Hi Steve,

Yes I am well aware that this regex example is not well suited for SPM.
This was a proof of concept. Pushing things no the extreme is my
way of understanding things deeply, so this was something I needed.

For some reason, I love and hate regex. I hate it because it is
unpythonic, char only and ugly. I love it because it is fast, and by the
use of the verbose flag also quite readable.

But getting rid of regex in favor of something even more capable was
a long-standing wish that is yet not fulfilled, because the nature of
both features is (still) pretty different.

I would love to have similar building blocks as in regex, but with a
pythonic syntax, and extending the basic string matching to general
objects. At the moment I don't see this in SPM because there are basic
flexible patterns missing. The only flexible thing in sequences is
the star operator, but in my example this is always eaten by the need
of an open end in the pattern. This is something that might improve.

As a drive-by, while looking into the Pilgrim algorithm for Roman
literals, I found by chance a faster algorithm :)
Not only that my SPM craziness is now really faster than the regex
solution, but I found something better, based on Pilgrim's `toRoman`
part of the algorithm :D

Given one of the basic algorithms in the internet which are fast
and incomplete, this here is much faster than using regex:

def from_roman_fastest(numeral):
if numeral == 'N':
return 0
num = from_roman_numeral(numeral)
cmp = roman.toRoman(num)
if numeral != cmp:
raise InvalidRomanNumeralError(f"Invalid Roman numeral: 
{numeral}")

return num

This follows the old observation "Listening is much harder than talking",
so this algorithm does not try a complex solution, but uses a simple one
and checks if the input string was correctly reconstructed.

Cheers -- Chris


On 02.08.23 22:30, Steve Holden wrote:

Hi Chris,

Nice to see you on the list.

While this is definitely off-topic, I trust I might be given license by 
the list's few remaining readers to point out that the match-case 
construct is for _structural_ pattern matching. As I wrote in the latest 
Nutshell: "Resist the temptation to use match unless there is a need to 
analyse the _structure_ of an object."


I don't believe it's accidental that match-case sequence patterns won't 
match str, bytes or bytearrray objects - regexen are the tool already 
optimised for that purpose, so it's quite impressive that you are 
managing to approach the same level of performance!


Kind regards,
Steve


On Wed, 2 Aug 2023 at 18:26, Christian Tismer-Sperling 
mailto:tis...@stackless.com>> wrote:


On 02.08.23 18:30, Paul Moore wrote:
 > On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull
 > mailto:turnbull.stephen...@u.tsukuba.ac.jp>
 > >> wrote:
 >
 >     Partly because that's where the other discussants are (the
network
 >     externality is undeniably powerful), and partly (I believe)
because
 >     effective use of email is a skill that requires effort to
acquire.
 >     Popular mail clients are designed to be popular, not to make that
 >     expertise easy to acquire and exercise.  Clunky use of email
makes
 >     lists much less pleasant for everyone than they could be.
 >
 >     I guess that's sad (I am, after all, a GNU Mailman
developer), but
 >     it's reality.
 >
 >
 > Personally, I'm sad because some people whose contributions I
enjoy (you
 > being one of them :-)) didn't move to Discourse. But like you
say, it's
 > how things are.
 >
 > Christian - you can make named constants using class attributes
(or an
 > enum):
 >
 > class A:
 >      M = "M"
 >
 > match seq:
 >      case A.M, A.M, A.M, A.M, *r:
 >          return 4*1000, r
 >
 > Basically, the "names are treated as variables to assign to" rule
 > doesn't apply to attributes.
 >
 > I'm not sure how helpful that is (it's not particularly
*shorter*) but I
 > think the idea was that most uses of named constants in a match
 > statement would be enums or module attributes. And compromises
had to be
 > made.
 >
 > Cheers,
 > Paul

Thanks a lot, everybody!

I have tried a lot now, using classes which becomes more readable
but - funnily - slower! Using the clumsy if-guards felt slow but isn't.

Then I generated functions even, with everything as constants,
and now the SPM version in fact out-performs the regex slightly!

But at last, I found an even faster and correct algorithm
by a different approach, which ends now this story :)

Going to the Discourse tite, now.

Cheers -- Chris
-- 
Christian Tismer-Sperling    :^) tis...@stackless.com

[Python-Dev] Re: Some pattern annoyance

[Steve Holden]

Hi Chris,

Nice to see you on the list.

While this is definitely off-topic, I trust I might be given license by the
list's few remaining readers to point out that the match-case construct is
for _structural_ pattern matching. As I wrote in the latest Nutshell:
"Resist the temptation to use match unless there is a need to analyse the
_structure_ of an object."

I don't believe it's accidental that match-case sequence patterns won't
match str, bytes or bytearrray objects - regexen are the tool already
optimised for that purpose, so it's quite impressive that you are
managing to approach the same level of performance!

Kind regards,
Steve


On Wed, 2 Aug 2023 at 18:26, Christian Tismer-Sperling 
wrote:

> On 02.08.23 18:30, Paul Moore wrote:
> > On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull
> >  > > wrote:
> >
> > Partly because that's where the other discussants are (the network
> > externality is undeniably powerful), and partly (I believe) because
> > effective use of email is a skill that requires effort to acquire.
> > Popular mail clients are designed to be popular, not to make that
> > expertise easy to acquire and exercise.  Clunky use of email makes
> > lists much less pleasant for everyone than they could be.
> >
> > I guess that's sad (I am, after all, a GNU Mailman developer), but
> > it's reality.
> >
> >
> > Personally, I'm sad because some people whose contributions I enjoy (you
> > being one of them :-)) didn't move to Discourse. But like you say, it's
> > how things are.
> >
> > Christian - you can make named constants using class attributes (or an
> > enum):
> >
> > class A:
> >  M = "M"
> >
> > match seq:
> >  case A.M, A.M, A.M, A.M, *r:
> >  return 4*1000, r
> >
> > Basically, the "names are treated as variables to assign to" rule
> > doesn't apply to attributes.
> >
> > I'm not sure how helpful that is (it's not particularly *shorter*) but I
> > think the idea was that most uses of named constants in a match
> > statement would be enums or module attributes. And compromises had to be
> > made.
> >
> > Cheers,
> > Paul
>
> Thanks a lot, everybody!
>
> I have tried a lot now, using classes which becomes more readable
> but - funnily - slower! Using the clumsy if-guards felt slow but isn't.
>
> Then I generated functions even, with everything as constants,
> and now the SPM version in fact out-performs the regex slightly!
>
> But at last, I found an even faster and correct algorithm
> by a different approach, which ends now this story :)
>
> Going to the Discourse tite, now.
>
> Cheers -- Chris
> --
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Strandstraße 37  : https://github.com/PySide
> 24217 Schönberg  : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
>
> ___
> 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/OFLAU34KWAKREKG4H2M5GES3PGT6VBAU/
> 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/DYTVT7CUFVVGIDPXG2MKIOELWJPG3W73/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Christian Tismer-Sperling]

On 02.08.23 18:30, Paul Moore wrote:
On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull 
> wrote:


Partly because that's where the other discussants are (the network
externality is undeniably powerful), and partly (I believe) because
effective use of email is a skill that requires effort to acquire.
Popular mail clients are designed to be popular, not to make that
expertise easy to acquire and exercise.  Clunky use of email makes
lists much less pleasant for everyone than they could be.

I guess that's sad (I am, after all, a GNU Mailman developer), but
it's reality.


Personally, I'm sad because some people whose contributions I enjoy (you 
being one of them :-)) didn't move to Discourse. But like you say, it's 
how things are.


Christian - you can make named constants using class attributes (or an 
enum):


class A:
     M = "M"

match seq:
     case A.M, A.M, A.M, A.M, *r:
         return 4*1000, r

Basically, the "names are treated as variables to assign to" rule 
doesn't apply to attributes.


I'm not sure how helpful that is (it's not particularly *shorter*) but I 
think the idea was that most uses of named constants in a match 
statement would be enums or module attributes. And compromises had to be 
made.


Cheers,
Paul


Thanks a lot, everybody!

I have tried a lot now, using classes which becomes more readable
but - funnily - slower! Using the clumsy if-guards felt slow but isn't.

Then I generated functions even, with everything as constants,
and now the SPM version in fact out-performs the regex slightly!

But at last, I found an even faster and correct algorithm
by a different approach, which ends now this story :)

Going to the Discourse tite, now.

Cheers -- Chris
--
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Strandstraße 37  : https://github.com/PySide
24217 Schönberg  : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023

___
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/OFLAU34KWAKREKG4H2M5GES3PGT6VBAU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Paul Moore]

On Wed, 2 Aug 2023 at 15:24, Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:

> Partly because that's where the other discussants are (the network
> externality is undeniably powerful), and partly (I believe) because
> effective use of email is a skill that requires effort to acquire.
> Popular mail clients are designed to be popular, not to make that
> expertise easy to acquire and exercise.  Clunky use of email makes
> lists much less pleasant for everyone than they could be.
>
> I guess that's sad (I am, after all, a GNU Mailman developer), but
> it's reality.
>

Personally, I'm sad because some people whose contributions I enjoy (you
being one of them :-)) didn't move to Discourse. But like you say, it's how
things are.

Christian - you can make named constants using class attributes (or an
enum):

class A:
M = "M"

match seq:
case A.M, A.M, A.M, A.M, *r:
return 4*1000, r

Basically, the "names are treated as variables to assign to" rule doesn't
apply to attributes.

I'm not sure how helpful that is (it's not particularly *shorter*) but I
think the idea was that most uses of named constants in a match statement
would be enums or module attributes. And compromises had to be made.

Cheers,
Paul
___
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/Z4RJIDUDC475Y3A6UPXKDTGDTFJX2W5C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Stephen J. Turnbull]

Christian Tismer-Sperling writes:

 > I thought this list would always stay intact as an alternatice
 > to the web things. How sad!

The list is alive.  You got an immediate answer, did you not?  It's
just that almost all of the people who are engaged with discussion
every day have found alternative platforms more productive.

Partly because that's where the other discussants are (the network
externality is undeniably powerful), and partly (I believe) because
effective use of email is a skill that requires effort to acquire.
Popular mail clients are designed to be popular, not to make that
expertise easy to acquire and exercise.  Clunky use of email makes
lists much less pleasant for everyone than they could be.

I guess that's sad (I am, after all, a GNU Mailman developer), but
it's reality.

Steve
___
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/7IBBTTSI3Q3WX3MXBGMFJ2GKX6MTE67V/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Christian Tismer-Sperling]

On 02.08.23 13:23, Barry wrote:



On 2 Aug 2023, at 12:03, Christian Tismer-Sperling 
 wrote:


Hi folks,

I just used Structural Pattern Matching quite intensively and I'm
pretty amazed of the new possibilities.

But see this code, trying to implement Mark Pilgrim's regex
algorithm for roman literals with SPM:

With constants, I can write

   match seq:
   case "M", "M", "M", "M", *r:
   return 4 * 1000, r

But if I want to use abbreviations by assignment, this is no longer
possible, and I have to write something weird like:

   M = "M"
   match seq:
   case a, b, c, d, *r if M == a == b == c == d:
   return 4 * 1000, r

So what is missing seems to be a notion of const-ness, which
could be dynamically deduced. Am I missing something?


Try asking for help at https://discuss.python.org/ 


This list is not for help or ideas, also its basically dead.



Thanks, Barry.
I thought this list would always stay intact as an alternatice
to the web things. How sad!

Cheers -- Chris

--
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Strandstraße 37  : https://github.com/PySide
24217 Schönberg  : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023

___
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/DTSEGLLMPJZLSF65BUZADFO36RCYVM6D/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Some pattern annoyance

[Barry]

> On 2 Aug 2023, at 12:03, Christian Tismer-Sperling  
> wrote:
> 
> Hi folks,
> 
> I just used Structural Pattern Matching quite intensively and I'm
> pretty amazed of the new possibilities.
> 
> But see this code, trying to implement Mark Pilgrim's regex
> algorithm for roman literals with SPM:
> 
> With constants, I can write
> 
>match seq:
>case "M", "M", "M", "M", *r:
>return 4 * 1000, r
> 
> But if I want to use abbreviations by assignment, this is no longer
> possible, and I have to write something weird like:
> 
>M = "M"
>match seq:
>case a, b, c, d, *r if M == a == b == c == d:
>return 4 * 1000, r
> 
> So what is missing seems to be a notion of const-ness, which
> could be dynamically deduced. Am I missing something?

Try asking for help at https://discuss.python.org/
This list is not for help or ideas, also its basically dead.

Barry
> 
> -- 
> Christian Tismer-Sperling:^)   tis...@stackless.com
> Software Consulting  : http://www.stackless.com/
> Strandstraße 37  : https://github.com/PySide
> 24217 Schönberg  : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776  fax +49 (30) 700143-0023
> ___
> 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/5MKBWCSVYZKR3S7OVY6KBF6FE7WYB5LC/
> 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/IN472AS2RMBFSLNUKCSOGWKTD3EN2ZX4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Some pattern annoyance

[Christian Tismer-Sperling]

Hi folks,

I just used Structural Pattern Matching quite intensively and I'm
pretty amazed of the new possibilities.

But see this code, trying to implement Mark Pilgrim's regex
algorithm for roman literals with SPM:

With constants, I can write

match seq:
case "M", "M", "M", "M", *r:
return 4 * 1000, r

But if I want to use abbreviations by assignment, this is no longer
possible, and I have to write something weird like:

M = "M"
match seq:
case a, b, c, d, *r if M == a == b == c == d:
return 4 * 1000, r

So what is missing seems to be a notion of const-ness, which
could be dynamically deduced. Am I missing something?

--
Christian Tismer-Sperling:^)   tis...@stackless.com
Software Consulting  : http://www.stackless.com/
Strandstraße 37  : https://github.com/PySide
24217 Schönberg  : GPG key -> 0xFB7BEE0E
phone +49 173 24 18 776  fax +49 (30) 700143-0023
___
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/5MKBWCSVYZKR3S7OVY6KBF6FE7WYB5LC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Python multithreading without the GIL

[Reza Roboubi]

I'm suspicious of pyperformance testing for this reason:

The point of Python is operating OK despite GIL because "most of the time is 
spent in 'external' libraries."

Pyperformance tests "typical" python performance where supposedly most tests 
are "ok" despite GIL. You need multithreading in atypical situations which may 
involve a lot of raw-python-object "thrashing," with high ref-counting, locks, 
etc. How do we know that pyperformance actually tests these cases well?
___
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/UA4VX3JFRRHI6TXPEBCZRWSPDOWQWM2G/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.12.0 beta 4 released

[Thomas Wouters]

Not much time left! I’ve released 3.12.0 beta 4. We’re now in the run-up to
rc1, so keep that in mind when you backport to the 3.12 branch.

https://www.python.org/downloads/release/python-3120b4/


*This is a beta preview of Python 3.12*
Python 3.12 is still in development. This release, 3.12.0b4, is the final
of four beta release previews of 3.12.

Beta release previews are intended to give the wider community the
opportunity to test new features and bug fixes and to prepare their
projects to support the new feature release.

We *strongly encourage* maintainers of third-party Python projects to *test
with 3.12* during the beta phase and report issues found to the Python bug
tracker  as soon as possible.
While the release is planned to be feature complete entering the beta
phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2023-07-31). Our goal is to have no ABI changes after this release, and as
few code changes as possible after 3.12.0rc1, the first release candidate.
To achieve that, it will be *extremely important* to get as much exposure
for 3.12 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is *not
*recommended
for production environments.


*Major new features of the 3.12 series, compared to 3.11*
Some of the new major new features and changes in Python 3.12 are:


   - New type annotation syntax for generic classes (PEP 695
   ).
   - More flexible f-string parsing, allowing many things previously
   disallowed (PEP 701 ).
   - Support for the buffer protocol in Python code (PEP 688
   ).
   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Many large and small performance improvements (like PEP 709
   ).
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   . The setuptools package continues to
   provide the distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - Invalid backslash escape sequences in strings now warn with SyntaxWarning
   instead of DeprecationWarning, making them more visible. (They will
   become syntax errors in the future.)
   - The internal representation of integers has changed in preparation for
   performance enhancements. (This should not affect most users as it is an
   internal detail, but it may cause problems for Cython-generated code.)
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Thomas know .)

For more details on the changes to Python 3.12, see What’s new in Python
3.12 . The next
pre-release of Python 3.12 will be 3.12.0rc1, the *first release candidate*,
currently scheduled for 2023-07-31.


*More resources*
Online Documentation .
PEP 693 , the Python 3.12
Release Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .


*We hope you enjoy the new releases!*
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation .

Regards from the alternating thunderstorms and heat waves in Amsterdam,
Thomas Wouters.

Your release team,
Ned Deily
Steve Dower
Łukasz Langa

-- 
Thomas Wouters 
___
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/Y75WBFCC6JXKHLKG2YK7CRYCJPVXN5OG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.12.0 beta 3 released

[Thomas Wouters]

We’re getting close! 3.12.0 beta 3 has been released:

https://www.python.org/downloads/release/python-3120b3/


*This is a beta preview of Python 3.12*
Python 3.12 is still in development. This release, 3.12.0b3, is the third
of four beta release previews of 3.12.

Beta release previews are intended to give the wider community the
opportunity to test new features and bug fixes and to prepare their
projects to support the new feature release.

We *strongly encourage* maintainers of third-party Python projects to* test
with 3.12* during the beta phase and report issues found to [the Python bug
tracker (https://github.com/python/cpython/issues) as soon as possible.
While the release is planned to be feature complete entering the beta
phase, it is possible that features may be modified or, in rare cases,
deleted up until the start of the release candidate phase (Monday,
2023-07-31). Our goal is to have no ABI changes after beta 4 and as few
code changes as possible after 3.12.0rc1, the first release candidate. To
achieve that, it will be *extremely important* to get as much exposure for
3.12 as possible during the beta phase.

Please keep in mind that this is a preview release and its use is *not
*recommended
for production environments.


*Major new features of the 3.12 series, compared to 3.11*
Some of the new major new features and changes in Python 3.12 are:


   - New type annotation syntax for generic classes (PEP 695
   ).
   - More flexible f-string parsing, allowing many things previously
   disallowed (PEP 701 ).
   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Many large and small performance improvements (like PEP 709
   ).
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   . The setuptools package continues to
   provide the distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - Invalid backslash escape sequences in strings now warn with
   SyntaxWarning instead of DeprecationWarning, making them more visible.
   (They will become syntax errors in the future.)
   - The internal representation of integers has changed in preparation for
   performance enhancements. (This should not affect most users as it is an
   internal detail, but it may cause problems for Cython-generated code.)
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Thomas know .)

For more details on the changes to Python 3.12, see What's new in Python
3.12 . The next pre-release
of Python 3.12 will be 3.12.0b4, the last beta release, currently scheduled
for 2023-07-10.


*More resources*Online Documentation .
PEP 693 , the Python 3.12
Release Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .


*We hope you enjoy the new releases!*
Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from a suddenly very stormy Amsterdam,
Thomas Wouters

Your release team,
Ned Deily
Steve Dower
Łukasz Langa

-- 
Thomas Wouters 
___
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/HNFVMG3L577ZFLBDH2Y54J7KGLUWTLEL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.4, 3.10.12, 3.9.17, 3.8.17, 3.7.17, and 3.12.0 beta 2 are now available

[Łukasz Langa]

Greetings! Time for another combined release of six separate versions of Python!

 
Before
 you scroll away to the download links

Please test the 3.12 beta! Downloading it and trying it out helps us a lot in 
ensuring Python 3.12.0 will be as polished as possible.

We welcome 3.10 to the prestigious club of security-only releases. It’s 
officially an old version of Python now! If you haven’t rewritten all your 
if:elif:else:s with pattern matching yet, are you even still writing Python?

At the same time, it looks like 3.7 is reaching end-of-life. Unless another 
security release happens in June, 3.7.17 will be the final release of Python 
3.7. I mean, now that I typed it out for all you to read, I’m sure I jinxed it. 
But in case I didn’t, I would like to thank Ned Deily for serving as the 
release manager of Python 3.6 and Python 3.7. He was my mentor as Release 
Manager, and continues serving Python as the provider of Mac installers for new 
releases. Thank you, Ned!

Speaking of installers, Steve Dower used to be the sole provider of Windows 
installers for Python releases for years now. His secret was a well-automated 
Azure pipeline that let him build, sign, and publish releases with minimal 
manual effort. Now he extended the power to press the blue “Run pipeline” 
button to more members of the team. Thank you, Steve! This is an important bus 
factor increment. In fact, the Windows installers for both 3.12.0b2 and 3.11.4 
were made by meinitiated by me 
.
 If there’s anything wrong with them, well, I guess that means I pressed the 
button wrong.

 
Security
 fixes in today’s releases

Updating is recommended due to security content:

3.7 - 3.12: gh-103142 : The 
version of OpenSSL used in Windows and Mac installers has been upgraded to 
1.1.1u to address CVE-2023-2650, CVE-2023-0465, CVE-2023-0466, CVE-2023-0464, 
as well as CVE-2023-0286, CVE-2022-4303, and CVE-2022-4303 fixed previously in 
1.1.1t (gh-101727).
3.7 - 3.11: gh-102153 : 
urllib.parse.urlsplit() now strips leading C0 control and space characters 
following the specification for URLs defined by WHATWG in response to 
CVE-2023-24329.
3.7 - 3.11: gh-99889 : Fixed a 
security in flaw in uu.decode() that could allow for directory traversal based 
on the input if no out_file was specified.
3.7 - 3.11: gh-104049 : Do not 
expose the local on-disk location in directory indexes produced by 
http.client.SimpleHTTPRequestHandler.
3.7 - 3.11: gh-101283 : 
subprocess.Popen now uses a safer approach to find cmd.exe when launching with 
shell=True.
3.8 - 3.11: gh-103935 : 
trace.__main__ now uses io.open_code() for files to be executed instead of raw 
open().
3.8 - 3.11: gh-102953 : The 
extraction methods in tarfile, and shutil.unpack_archive(), have a new 
filterargument that allows limiting tar features than may be surprising or 
dangerous, such as creating files outside the destination directory. See 
Extraction filters 
 for details.
3.9: gh-102126 : Fixed a 
deadlock at shutdown when clearing thread states if any finalizer tries to 
acquire the runtime head lock.
3.9: gh-100892 : Fixed a crash 
due to a race while iterating over thread states in clearing threading.local.
Python 3.12.0 beta 2

Get it here: 3.12.0b2 
116 new commits since 3.12.0 beta 1.

Python 3.11.4

Get it here: 3.11.4 
233 new commits.

Python 3.10.12

Get it here: 3.10.12 
Security-only release with no binaries. 20 new commits.

Python 3.9.17

Get it here: 3.9.17 
Security-only release with no binaries. 26 commits.

Python 3.8.17

Get it here: 3.8.17 
Security-only release with no binaries. 24 commits.

Python 3.7.17

Get it here as it might be the last release of 3.7 ever 
:
3.7.17 
Security-only release with no binaries. 21 commits.

[Python-Dev] [RELEASE] Python 3.12.0 beta 1 released.

[Thomas Wouters]

I'm pleased to announce the release of Python 3.12 beta 1 (and feature
freeze for Python 3.12).

https://www.python.org/downloads/release/python-3120b1/
This is a beta preview of Python 3.12

Python 3.12 is still in development. This release, 3.12.0b1, is the first
of four planned beta release previews of 3.12.

Beta release previews are intended to give the wider community the
opportunity to test new features and bug fixes and to prepare their
projects to support the new feature release.

We strongly encourage maintainers of third-party Python projects to test
with 3.12 during the beta phase and report issues found to [the Python bug
tracker (Issues · python/cpython · GitHub) as soon as possible. While the
release is planned to be feature complete entering the beta phase, it is
possible that features may be modified or, in rare cases, deleted up until
the start of the release candidate phase (Monday, 2023-07-31). Our goal is
to have no ABI changes after beta 4 and as few code changes as possible
after 3.12.0rc1, the first release candidate. To achieve that, it will be
extremely important to get as much exposure for 3.12 as possible during the
beta phase.

Please keep in mind that this is a preview release and its use is not
recommended for production environments.


Major new features of the 3.12 series, compared to 3.11

Some of the new major new features and changes in Python 3.12 are:


   - New type annotation syntax for generic classes (PEP 695
   ).
   - More flexible f-string parsing, allowing many things previously
   disallowed (PEP 701 ).
   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Many large and small performance improvements (like PEP 709
   ).
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   . The setuptools package (installed
   by default in virtualenvs and many other places) continues to provide the
   distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - Invalid backslash escape sequences in strings now warn with
   SyntaxWarning instead of DeprecationWarning, making them more visible.
   (They will become syntax errors in the future.)
   - The internal representation of integers has changed in preparation for
   performance enhancements. (This should not affect most users as it is an
   internal detail, but it may cause problems for Cython-generated code.)
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Thomas know .)

For more details on the changes to Python 3.12, see What’s new in Python
3.12 . The next pre-release
of Python 3.12 will be 3.12.0b2, currently scheduled for 2023-05-29.


More resources

Online Documentation .
PEP 693 , the Python 3.12
Release Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .


And now for something completely different

As the first beta release marks the point at which we fork off the release
branch from the main development branch, here’s a poem about forks in the
road.

Two roads diverged in a yellow wood,
And sorry I could not travel both
And be one traveler, long I stood
And looked down one as far as I could
To where it bent in the undergrowth;

Then took the other, as just as fair,
And having perhaps the better claim,
Because it was grassy and wanted wear;
Though as for that the passing there
Had worn them really about the same,

And both that morning equally lay
In leaves, no step had trodden black.
Oh, I kept the first for another day!
Yet knowing how way leads on to way,
I doubted if I should ever come back.

I shall be telling this with a sigh
Somewhere ages and ages hence:
Two roads diverged in a wood, and I —
I took the one less traveled by,
And that has made all the difference.


*The Road Not Taken*, by Robert Frost.

Enjoy the new release

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Your release team,
Thomas 

[Python-Dev] Re: Mixed Python/C debugging

[Wes Turner]

"Debugging a Mixed Python and C Language Stack" (2023)
https://developer.nvidia.com/blog/debugging-mixed-python-and-c-language-stack/
https://news.ycombinator.com/item?id=35706687

On Mon, Dec 2, 2019, 10:59 AM Skip Montanaro 
wrote:

> Thanks for the responses. I know there are multiple tools out there (to
> wit, Wes's response), but I'm really after what people actually use and
> find works. I apologize that wasn't clear. I did neglect to mention that my
> environment is Linux (specifically Ubuntu 18.04), so Windows-based
> solutions aren't likely to be workable for me.
>
> For the time being, I've been working through one or two of the
> docs/tutorials about the parsing/compiler internals which focus on the C
> side, so gdb with curses display enabled (Ctrl-X a) and built-in PyObject
> support has been sufficient. I will eventually need mixed language
> debugging though. And, as an Emacs user, how this might play in that
> sandbox is of interest.
>
> Skip
> ___
> 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/IZRJX3YYOBJWJ6UAE5PIAJBPKB7IOHS2/
> 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/WSJWVGLZKF3JD7Y6LDHWYKAT3AJ7LETS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [RELEASE] Python 3.11.3, 3.10.11 and 3.12.0 alpha 7 released

[Thomas Wouters]

It's time for another set of Python releases! *Python 3.11.3, 3.10.11 and
3.12 alpha 7 are now available*.

Python 3.12.0 alpha 7

The final alpha release of Python 3.12! The next release will be beta 1,
which is also the feature freeze. Last chance to get your new features and
API changes into 3.12!

https://www.python.org/downloads/release/python-3120a7/


*246 new commits since 3.12.0a6.*
Python 3.11.3

More bugfixes and security fixes for the best Python version (so far).

https://www.python.org/downloads/release/python-3113/


*167 new commits since 3.11.2*
Python 3.10.11

The final regular bugfix release for Python 3.10! It is now entering
security-fix-only mode. This also means this is the last version for which
we will ship Windows and macOS installers. If you rely on these binary
releases, it's time to upgrade to Python 3.11.

https://www.python.org/downloads/release/python-31011/


*121 new commits since 3.10.10.*
We hope you enjoy the new releases!

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

https://www.python.org/psf/

>From the release team,

Thomas Wouters @thomas
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv
Ned Deily @nad
Steve Dower @steve.dower
___
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/GYWTANKM34WYRDN55VKNZO3VTDI26CE6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[avi.e.gross]

Sadly, between Daylight Savings time and a  newer irrational PI π Day, I am 
afraid some April Foolers got thrown off albeit some may shower us with 
nonsense  in May I.

-Original Message-
From: Python-list  On 
Behalf Of Barry Warsaw
Sent: Monday, April 3, 2023 8:31 PM
To: Skip Montanaro 
Cc: Python ; Python Dev 
Subject: Re: [Python-Dev] Small lament...

I heard it on reasonably believable authority that the FLUFL took the year off. 
 Lamentable.

-Barry

> On Apr 1, 2023, at 11:19, Skip Montanaro  wrote:
> 
> Just wanted to throw this out there... I lament the loss of waking up on 
> April 1st to see a creative April Fool's Day joke on one or both of these 
> lists, often from our FLUFL... Maybe such frivolity still happens, just not 
> in the Python ecosystem? I know you can still import "this" or "antigravity", 
> but those are now old (both introduced before 2010). When was the last time a 
> clever easter egg was introduced or an April Fool's Day joke played?
> 
> ¯\_(ツ)_/¯
> 
> Skip
> 
> ___
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> 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/MN7Z3DLX4V24WZLTJ2CABS4UUVTXBEKI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Damian Shaw]

In case people missed it, this Pip PR:
https://github.com/pypa/pip/pull/11914

On Mon, Apr 3, 2023 at 8:41 PM Barry Warsaw  wrote:

> I heard it on reasonably believable authority that the FLUFL took the year
> off.  Lamentable.
>
> -Barry
>
> > On Apr 1, 2023, at 11:19, Skip Montanaro 
> wrote:
> >
> > Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not
> in the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
> >
> > ¯\_(ツ)_/¯
> >
> > Skip
> >
> > ___
> > 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> > 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/NGP4A6GN76T4NGBILAGYTZO4OQORBZM4/
> 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/RPZWBDDGYWYKYCTFFT323N6NMNBGIFBC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Barry Warsaw]

I heard it on reasonably believable authority that the FLUFL took the year off. 
 Lamentable.

-Barry

> On Apr 1, 2023, at 11:19, Skip Montanaro  wrote:
> 
> Just wanted to throw this out there... I lament the loss of waking up on 
> April 1st to see a creative April Fool's Day joke on one or both of these 
> lists, often from our FLUFL... Maybe such frivolity still happens, just not 
> in the Python ecosystem? I know you can still import "this" or "antigravity", 
> but those are now old (both introduced before 2010). When was the last time a 
> clever easter egg was introduced or an April Fool's Day joke played?
> 
> ¯\_(ツ)_/¯
> 
> Skip
> 
> ___
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> Code of Conduct: http://python.org/psf/codeofconduct/



signature.asc
Description: Message signed with OpenPGP
___
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/NGP4A6GN76T4NGBILAGYTZO4OQORBZM4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Guido van Rossum]

A bit late, this reached my inbox:
https://peternorvig.medium.com/new-python-operators-9f31b56ddcc7

On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro 
wrote:

> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not in
> the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
>
> ¯\_(ツ)_/¯
>
> Skip
>
> ___
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
--Guido van Rossum (python.org/~guido)
*Pronouns: he/him **(why is my pronoun here?)*

___
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/LMMRU7FO72UGZQ3UFRVWFYOKRMBCVEHA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Jim Schwartz]

Yea, it is funny.  I commented on it.

-Original Message-
From: Python-list  On
Behalf Of Eryk Sun
Sent: Saturday, April 1, 2023 2:23 PM
To: Skip Montanaro 
Cc: Python ; python-dev Dev 
Subject: Re: [Python-Dev] Small lament...

On 4/1/23, Skip Montanaro  wrote:
> Just wanted to throw this out there... I lament the loss of waking up 
> on April 1st to see a creative April Fool's Day joke on one or both of 
> these lists, often from our FLUFL... Maybe such frivolity still 
> happens, just not in the Python ecosystem?

I thought this one was funny:

https://github.com/python/cpython/issues/103172
--
https://mail.python.org/mailman/listinfo/python-list

___
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/PC3Q3CT3PJ46T6KWD4XXXGCFZTDLRB6Q/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Richard Mateosian]

I got something from MalWareBytes today:

Have you ever thought to yourself, “Why hasn’t Malwarebytes created an app
that can detect threats in the real world?” Well, guess what? We just did.
Say hello to *WorldBytes!*

[image: Graphics]
Powered by our world-class malware scanning engine and paired with
next-level AI technology, *WorldBytes* lets you scan the world around you
and get real-time threat assessments of anything and everything. And we
mean anything.

Creepy dolls, toilets with threatening auras, pukka shell necklaces, and
even cats (you know the ones). Just scan it with your phone’s camera and
*WorldBytes* will instantly tell you about any potential security concerns.

On Sat, Apr 1, 2023 at 12:28 PM Eryk Sun  wrote:

> On 4/1/23, Skip Montanaro  wrote:
> > Just wanted to throw this out there... I lament the loss of waking up on
> > April 1st to see a creative April Fool's Day joke on one or both of these
> > lists, often from our FLUFL... Maybe such frivolity still happens, just
> not
> > in the Python ecosystem?
>
> I thought this one was funny:
>
> https://github.com/python/cpython/issues/103172
> ___
> 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/G2Z7QUZA4E3J6BE7HLIWM6R3FWHFYWTV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

Richard Mateosian
Berkeley, California
___
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/LGYELJ5FR3TR2DZBFH2YAL6ZK3ISUJM6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Eryk Sun]

On 4/1/23, Skip Montanaro  wrote:
> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not
> in the Python ecosystem?

I thought this one was funny:

https://github.com/python/cpython/issues/103172
___
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/G2Z7QUZA4E3J6BE7HLIWM6R3FWHFYWTV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Mariatta]

Last I heard is that some core devs are forming the duo PEP Shop Boys.
Their debut album will be titled "Please merge".


On Sat, Apr 1, 2023, 11:22 AM Skip Montanaro 
wrote:

> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not in
> the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
>
> ¯\_(ツ)_/¯
>
> Skip
>
> ___
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> 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/PJXR6PAYN4HLICZNIYNV2IM7OFHNNJX2/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Small lament...

[Eric Fahlgren]

Oh, man, it has been a while.  The last one I remember is PEP 404 (if you
can find it :) ), dated 2011 and it wasn't an April Fool's...

On Sat, Apr 1, 2023 at 11:23 AM Skip Montanaro 
wrote:

> Just wanted to throw this out there... I lament the loss of waking up on
> April 1st to see a creative April Fool's Day joke on one or both of these
> lists, often from our FLUFL... Maybe such frivolity still happens, just not in
> the Python ecosystem? I know you can still import "this" or
> "antigravity", but those are now old (both introduced before 2010). When
> was the last time a clever easter egg was introduced or an April Fool's Day
> joke played?
>
> ¯\_(ツ)_/¯
>
> Skip
>
> ___
> 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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
> 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/TIBOHJYFSHVSAIBZQPMEXHUH2KWPJMCC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Small lament...

[Skip Montanaro]

Just wanted to throw this out there... I lament the loss of waking up on
April 1st to see a creative April Fool's Day joke on one or both of these
lists, often from our FLUFL... Maybe such frivolity still happens, just not in
the Python ecosystem? I know you can still import "this" or "antigravity",
but those are now old (both introduced before 2010). When was the last time
a clever easter egg was introduced or an April Fool's Day joke played?

¯\_(ツ)_/¯

Skip
___
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/Q62W2Q6R6XMX57WK2CUGEENHMT3C3REF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 448 review

[Ethan Furman]

On 3/29/23 13:23, Brett Cannon wrote:

Wow, we are now getting Canadian-specific spam!

Since the volume on this mailing list is so low, should we change everyone to be moderated to start and then remove that 
after they have posted appropriately? Or did this get through by accident?


Accident.  I set the user to always discard, and then clicked on the green button instead of the yellow one.  Green to 
me says "Do what I asked for." but green to MM3 says "Do what I asked for AND accept the message."


--
~Ethan~
___
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/SY26KTV3YOZUS5ZGFNBVFUAGV2GV5MLD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 448 review

[Ethan Furman]

My apologies for the accidentally accepted spam.

If you reply to that original message, please remove the link before sending.

Thanks.  ;-)

--
~Ethan~
___
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/ABUAQHFRBCPENJ47ZZ22XBN7JEEQW6TN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 448 review

[Oleg Broytman]

ChatGPT spam, specifically generated for Python mailing list filters. :mad:

On Wed, Mar 29, 2023 at 01:23:03PM -0700, Brett Cannon  wrote:
> Wow, we are now getting Canadian-specific spam!
> 
> Since the volume on this mailing list is so low, should we change everyone
> to be moderated to start and then remove that after they have posted
> appropriately? Or did this get through by accident?
> 
> On Wed, Mar 29, 2023 at 12:19???PM  wrote:
> 
> > It seems like you have thoroughly read through the PEP and the discussion
> > thread and have formed an opinion about the proposed changes. It's great
> > that you have taken the time to understand the proposal and the reasoning
> > behind it.
> >
> > Georg Brandl's comments and Greg Ewing's explanations do shed light on
> > some of the concerns raised by the proposal. However, it is good to see
> > that you find the sequence and dict flattening syntax proposals to be clean
> > and logical.
> >
> > Regarding the comprehensions part of the proposal, it appears that you are
> > ambivalent about it. You acknowledge that it provides a way to flatten a
> > sequence of sequences, but you also point out some of the odd edge cases
> > that you discovered while experimenting in the interpreter. It's good to
> > see that you are taking a cautious approach and are not rushing to endorse
> > this part of the proposal.
> >
> > Overall, your analysis is thoughtful and well-reasoned. It's good to see
> > that you are engaging with the proposal in a critical manner and taking
> > into account the different perspectives presented in the discussion thread.
> > Regards: 


Oleg.
-- 
Oleg Broytmanhttps://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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/BQYY7ZTOARFCEQE4FC4ECVFRPMHIMLB7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 448 review

[Brett Cannon]

Wow, we are now getting Canadian-specific spam!

Since the volume on this mailing list is so low, should we change everyone
to be moderated to start and then remove that after they have posted
appropriately? Or did this get through by accident?

On Wed, Mar 29, 2023 at 12:19 PM  wrote:

> It seems like you have thoroughly read through the PEP and the discussion
> thread and have formed an opinion about the proposed changes. It's great
> that you have taken the time to understand the proposal and the reasoning
> behind it.
>
> Georg Brandl's comments and Greg Ewing's explanations do shed light on
> some of the concerns raised by the proposal. However, it is good to see
> that you find the sequence and dict flattening syntax proposals to be clean
> and logical.
>
> Regarding the comprehensions part of the proposal, it appears that you are
> ambivalent about it. You acknowledge that it provides a way to flatten a
> sequence of sequences, but you also point out some of the odd edge cases
> that you discovered while experimenting in the interpreter. It's good to
> see that you are taking a cautious approach and are not rushing to endorse
> this part of the proposal.
>
> Overall, your analysis is thoughtful and well-reasoned. It's good to see
> that you are engaging with the proposal in a critical manner and taking
> into account the different perspectives presented in the discussion thread.
> Regards: https://www.extraappliance.ca/washing-machine-repair-edmonton/
> ___
> 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/6BP32AXSJAJPWHU274M3RBLLFUBSQUC6/
> 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/4ACX7TQV3YV6UDZ65AHPMM7UAWCJARYI/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 448 review

[extraappliance2022]

It seems like you have thoroughly read through the PEP and the discussion 
thread and have formed an opinion about the proposed changes. It's great that 
you have taken the time to understand the proposal and the reasoning behind it.

Georg Brandl's comments and Greg Ewing's explanations do shed light on some of 
the concerns raised by the proposal. However, it is good to see that you find 
the sequence and dict flattening syntax proposals to be clean and logical.

Regarding the comprehensions part of the proposal, it appears that you are 
ambivalent about it. You acknowledge that it provides a way to flatten a 
sequence of sequences, but you also point out some of the odd edge cases that 
you discovered while experimenting in the interpreter. It's good to see that 
you are taking a cautious approach and are not rushing to endorse this part of 
the proposal.

Overall, your analysis is thoughtful and well-reasoned. It's good to see that 
you are engaging with the proposal in a critical manner and taking into account 
the different perspectives presented in the discussion thread.
Regards: https://www.extraappliance.ca/washing-machine-repair-edmonton/
___
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/6BP32AXSJAJPWHU274M3RBLLFUBSQUC6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Debugging of native extensions on windows

[Eryk Sun]

On 3/13/23, Rokas Kupstys  wrote:
> I eventually stumbled on to process list showing
> ".venv/Scripts/python.exe" having spawned a subprocess... Which led me
> to "PC/launcher.c" which is what ".venv/Scripts/python.exe" really is.

For a standard Python installation, you can create a virtual
environment with the --symlinks option instead of the default
configuration that uses the venv launcher. Note, however, that using
symlinks doesn't work with the store app distribution of Python.

If your system doesn't have developer mode enabled, creating symlinks
requires "SeCreateSymbolicLinkPrivilege". By default this privilege is
only granted to administrators. However, an administrator can use the
management console "secpol.msc" snap-in to grant the symlink privilege
directly to a user account, or to one of the account's default enabled
groups such as "Authenticated Users". Add the user or group to the
"Create symbolic links" policy in "Security Settings" -> "Local
Policies" -> "User Rights Assignment". You'll have to log off and back
on again to get a new access token that has the symlink privilege.

Unfortunately, the shell API -- e.g. os.startfile() -- resolves the
final path of an executable before running it. This allows using
filesystem symlinks as if they're shortcuts (LNK files), but it
prevents using a symlink to change the name or path of an executable
to get different expected behavior, such as a Python virtual
environment that uses symlinks.
___
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/3PJJDU6WVNV7K65RZEDMBERCCAVIS5P6/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Debugging of native extensions on windows

[Steve Dower]

On 3/14/2023 7:13 AM, Rokas Kupstys wrote:
> Still, i think there can be an improvement in this area, and it would
> likely be quite cheap. The biggest problem is people being unaware what
> is going on. IsDebuggerPresent()/CheckRemoteDebuggerPresent() could be
> used for checking debugger presence and when debugging state of main
> process and child process do not match, launcher could print some link
> to documentation describing what is going on and how situation could be
> solved. I am just not sure about any possible race conditions (no idea
> how fast debuggers attack to child processes).

Detecting when a debugger is attached and printing a debug message on 
exit from the launcher might be a neat idea. Care to submit a bug at 
https://github.com/python/cpython?


The change would likely have to go into PC\launcher.c (for venvs) as 
well as PC\launcher2.c right now (for py.exe).


Native debuggers usually hook process creation, so they should attach 
immediately with no risk of missing anything.


Cheers,
Steve

___
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/2NH3T2KZTXIIWSPPUTYA3S66XEDG56MK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: please consider changing --enable-unicode default to ucs4

[Brett Cannon]

Python no longer has `--enable-unicode` as part of `./configure`.

On Tue, Mar 14, 2023 at 9:26 AM Jonathan Benson via Python-Dev <
python-dev@python.org> wrote:

>
>
> Sent from my iPhone
> ___
> 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/TA3MZ2TSDGVAJ7NTTR5F37V7AVRM7ELR/
> 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/RH364BR4UKCJ5FY37PMOB55BX7O4S7GU/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Debugging of native extensions on windows

[Rokas Kupstys]

As Steve suggested i think most friction-less path is to run python 
interpreter directly while specifying site-packages of virtualenv in 
PYTHONPATH. I already specify additional paths there anyway, since 
extensions are built with cmake and i wanted to achieve fast iteration 
times, being able to use extensions directly built by cmake, without 
going through installation problem.


Still, i think there can be an improvement in this area, and it would 
likely be quite cheap. The biggest problem is people being unaware what 
is going on. IsDebuggerPresent()/CheckRemoteDebuggerPresent() could be 
used for checking debugger presence and when debugging state of main 
process and child process do not match, launcher could print some link 
to documentation describing what is going on and how situation could be 
solved. I am just not sure about any possible race conditions (no idea 
how fast debuggers attack to child processes).


-- Rokas Kupstys

On 2023-03-14 08:35, Christopher Barker wrote:
Is it easier to simply run python outside a virtualenv? They are 
great, but maybe when debugging an extension module, it's not so hard 
to just not use it :-)


You also might want to give conda environments a try -- they include 
Python, so probably won't have the same issue.


-CHB



On Mon, Mar 13, 2023 at 4:58 PM Steve Dower  
wrote:


Hi Rokas

The typical solution (which I myself use frequently) is to enable
your
debugger to attach to child processes automatically. It can make
things
a bit noisier, but it's generally manageable, especially if you've
got
breakpoints set in your own code.

Another option is to not use the virtual environment, but set
PYTHONPATH
to your environment's Lib\site-packages directory and then run the
base
interpreter directly. Most of the time, this will be identical,
but it
avoids the extra process.

Unfortunately, for a variety of reasons, we can't get away from the
redirector process as long as virtual environments keep their current
design. As changing the design would be just as disruptive, we've not
done anything yet, nor do we have any plans to change anything.

Finally, most discussion about Python occurs at
https://discuss.python.org/ these days. You'll likely find more
help and
discussion over there.

Cheers,
Steve

On 3/13/2023 3:25 PM, Rokas Kupstys wrote:
> Hello!
>
> I am dropping this mail to bring up an issue which cost me three
good
> evenings of time. Now that i figured it out i believe it is quite a
> serious usability problem.
>
> Gist of the problem: i have some C++ code wrapped with SWIG, so
a native
> extension. As with all software - there was a bug. However, no
matter
> what i did - i could not debug it in a native debugger. I ran
> ".venv/Scripts/python.exe script.py" in a native debugger and
> breakpoints would not be hit, application would crash
eventually. This
> was especially confusing, because exact same setup worked just
fine on
> linux. I eventually stumbled on to process list showing
> ".venv/Scripts/python.exe" having spawned a subprocess... Which
led me
> to "PC/launcher.c" which is what ".venv/Scripts/python.exe"
really is. I
> cant find much information about this behavior in documentation
even
> after the fact. All in all, this was quite confusing. So now
every time
> i want to debug a native extension i have to start a program and
then
> attach a debugger to it, instead of just hitting "Debug" button
in IDE.
> It gets worse if crash happens immediately, which means i have
to resort
> to things like adding a message box somewhere to block execution
and
> give me enough time to attach the debugger. It works in the end,
but
> user experience is really not great. But whats worse - this is
such a
> non-obvious behavior that many more people may trip on it and waste
> their time. Documenting this behavior would be of little help
too, as
> there is no clear path from the issue to the documentation on
the matter...
>
> So there it is. I am sure it is the way it is for a good reason.
> However, this is a very error-prone process which is likely to
waste
> people's time. So maybe this behavior could be reconsidered? Or
maybe
> there is a solution already, which escaped me?
>

___
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/424LIHYHRQWM5VLQF2PAMLKGCNCKSJDF/
Code of Conduct: http://python.org/psf/codeofconduct/



--
Christopher Barker, PhD (Chris)

Python Language Consulting

[Python-Dev] Re: please consider changing --enable-unicode default to ucs4

[Jonathan Benson via Python-Dev]



Sent from my iPhone
___
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/TA3MZ2TSDGVAJ7NTTR5F37V7AVRM7ELR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Debugging of native extensions on windows

[Christopher Barker]

Is it easier to simply run python outside a virtualenv? They are great, but
maybe when debugging an extension module, it's not so hard to just not use
it :-)

You also might want to give conda environments a try -- they include
Python, so probably won't have the same issue.

-CHB



On Mon, Mar 13, 2023 at 4:58 PM Steve Dower  wrote:

> Hi Rokas
>
> The typical solution (which I myself use frequently) is to enable your
> debugger to attach to child processes automatically. It can make things
> a bit noisier, but it's generally manageable, especially if you've got
> breakpoints set in your own code.
>
> Another option is to not use the virtual environment, but set PYTHONPATH
> to your environment's Lib\site-packages directory and then run the base
> interpreter directly. Most of the time, this will be identical, but it
> avoids the extra process.
>
> Unfortunately, for a variety of reasons, we can't get away from the
> redirector process as long as virtual environments keep their current
> design. As changing the design would be just as disruptive, we've not
> done anything yet, nor do we have any plans to change anything.
>
> Finally, most discussion about Python occurs at
> https://discuss.python.org/ these days. You'll likely find more help and
> discussion over there.
>
> Cheers,
> Steve
>
> On 3/13/2023 3:25 PM, Rokas Kupstys wrote:
> > Hello!
> >
> > I am dropping this mail to bring up an issue which cost me three good
> > evenings of time. Now that i figured it out i believe it is quite a
> > serious usability problem.
> >
> > Gist of the problem: i have some C++ code wrapped with SWIG, so a native
> > extension. As with all software - there was a bug. However, no matter
> > what i did - i could not debug it in a native debugger. I ran
> > ".venv/Scripts/python.exe script.py" in a native debugger and
> > breakpoints would not be hit, application would crash eventually. This
> > was especially confusing, because exact same setup worked just fine on
> > linux. I eventually stumbled on to process list showing
> > ".venv/Scripts/python.exe" having spawned a subprocess... Which led me
> > to "PC/launcher.c" which is what ".venv/Scripts/python.exe" really is. I
> > cant find much information about this behavior in documentation even
> > after the fact. All in all, this was quite confusing. So now every time
> > i want to debug a native extension i have to start a program and then
> > attach a debugger to it, instead of just hitting "Debug" button in IDE.
> > It gets worse if crash happens immediately, which means i have to resort
> > to things like adding a message box somewhere to block execution and
> > give me enough time to attach the debugger. It works in the end, but
> > user experience is really not great. But whats worse - this is such a
> > non-obvious behavior that many more people may trip on it and waste
> > their time. Documenting this behavior would be of little help too, as
> > there is no clear path from the issue to the documentation on the
> matter...
> >
> > So there it is. I am sure it is the way it is for a good reason.
> > However, this is a very error-prone process which is likely to waste
> > people's time. So maybe this behavior could be reconsidered? Or maybe
> > there is a solution already, which escaped me?
> >
>
> ___
> 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/424LIHYHRQWM5VLQF2PAMLKGCNCKSJDF/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
Christopher Barker, PhD (Chris)

Python Language Consulting
  - Teaching
  - Scientific Software Development
  - Desktop GUI and Web Development
  - wxPython, numpy, scipy, Cython
___
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/R3FSGSRCYIRYQL43TVJOKSSKA6YWEMZ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Debugging of native extensions on windows

[Steve Dower]

Hi Rokas

The typical solution (which I myself use frequently) is to enable your 
debugger to attach to child processes automatically. It can make things 
a bit noisier, but it's generally manageable, especially if you've got 
breakpoints set in your own code.


Another option is to not use the virtual environment, but set PYTHONPATH 
to your environment's Lib\site-packages directory and then run the base 
interpreter directly. Most of the time, this will be identical, but it 
avoids the extra process.


Unfortunately, for a variety of reasons, we can't get away from the 
redirector process as long as virtual environments keep their current 
design. As changing the design would be just as disruptive, we've not 
done anything yet, nor do we have any plans to change anything.


Finally, most discussion about Python occurs at 
https://discuss.python.org/ these days. You'll likely find more help and 
discussion over there.


Cheers,
Steve

On 3/13/2023 3:25 PM, Rokas Kupstys wrote:

Hello!

I am dropping this mail to bring up an issue which cost me three good 
evenings of time. Now that i figured it out i believe it is quite a 
serious usability problem.


Gist of the problem: i have some C++ code wrapped with SWIG, so a native 
extension. As with all software - there was a bug. However, no matter 
what i did - i could not debug it in a native debugger. I ran 
".venv/Scripts/python.exe script.py" in a native debugger and 
breakpoints would not be hit, application would crash eventually. This 
was especially confusing, because exact same setup worked just fine on 
linux. I eventually stumbled on to process list showing 
".venv/Scripts/python.exe" having spawned a subprocess... Which led me 
to "PC/launcher.c" which is what ".venv/Scripts/python.exe" really is. I 
cant find much information about this behavior in documentation even 
after the fact. All in all, this was quite confusing. So now every time 
i want to debug a native extension i have to start a program and then 
attach a debugger to it, instead of just hitting "Debug" button in IDE. 
It gets worse if crash happens immediately, which means i have to resort 
to things like adding a message box somewhere to block execution and 
give me enough time to attach the debugger. It works in the end, but 
user experience is really not great. But whats worse - this is such a 
non-obvious behavior that many more people may trip on it and waste 
their time. Documenting this behavior would be of little help too, as 
there is no clear path from the issue to the documentation on the matter...


So there it is. I am sure it is the way it is for a good reason. 
However, this is a very error-prone process which is likely to waste 
people's time. So maybe this behavior could be reconsidered? Or maybe 
there is a solution already, which escaped me?




___
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/424LIHYHRQWM5VLQF2PAMLKGCNCKSJDF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Debugging of native extensions on windows

[Rokas Kupstys]

Hello!

I am dropping this mail to bring up an issue which cost me three good 
evenings of time. Now that i figured it out i believe it is quite a 
serious usability problem.


Gist of the problem: i have some C++ code wrapped with SWIG, so a native 
extension. As with all software - there was a bug. However, no matter 
what i did - i could not debug it in a native debugger. I ran 
".venv/Scripts/python.exe script.py" in a native debugger and 
breakpoints would not be hit, application would crash eventually. This 
was especially confusing, because exact same setup worked just fine on 
linux. I eventually stumbled on to process list showing 
".venv/Scripts/python.exe" having spawned a subprocess... Which led me 
to "PC/launcher.c" which is what ".venv/Scripts/python.exe" really is. I 
cant find much information about this behavior in documentation even 
after the fact. All in all, this was quite confusing. So now every time 
i want to debug a native extension i have to start a program and then 
attach a debugger to it, instead of just hitting "Debug" button in IDE. 
It gets worse if crash happens immediately, which means i have to resort 
to things like adding a message box somewhere to block execution and 
give me enough time to attach the debugger. It works in the end, but 
user experience is really not great. But whats worse - this is such a 
non-obvious behavior that many more people may trip on it and waste 
their time. Documenting this behavior would be of little help too, as 
there is no clear path from the issue to the documentation on the matter...


So there it is. I am sure it is the way it is for a good reason. 
However, this is a very error-prone process which is likely to waste 
people's time. So maybe this behavior could be reconsidered? Or maybe 
there is a solution already, which escaped me?


--
-- Rokas Kupstys

___
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/2BHNPL7DHLPRQYMN7FQBJQRZ6H6SDIVE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.12.0 alpha 6 released

[Thomas Wouters]

I'm pleased to announce the release of Python 3.12 alpha 6.

https://www.python.org/downloads/release/python-3120a6/


*This is an early developer preview of Python 3.12.*
Major new features of the 3.12 series, compared to 3.11

Python 3.12 is still in development. This release, 3.12.0a6 is the sixth of
seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2023-05-08) and, if necessary, may be modified or deleted up
until the release candidate phase (2023-07-31). Please keep in mind that
this is a preview release and its use is not recommended for production
environments.

Many new features for Python 3.12 are still being planned and written.
Among the new major new features and changes so far:


   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   . The setuptools package (installed by
   default in virtualenvs and many other places) continues to provide the
   distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - Invalid backslash escape sequences in strings now warn with
   SyntaxWarning instead of DeprecationWarning, making them more visible.
   (They will become syntax errors in the future.)
   - The internal representation of integers has changed in preparation for
   performance enhancements. (This should not affect most users as it is an
   internal detail, but it may cause problems for Cython-generated code.)
   - (Hey, fellow core developer, if a feature you find important is
   missing from this list, let Thomas know .)

For more details on the changes to Python 3.12, see What's new in Python
3.12. The next pre-release of Python 3.12 will be 3.12.0a7, currently
scheduled for 2023-04-03.

More resources

Online Documentation .
PEP 693 , the Python 3.12 Release
Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .

And now for something completely different

Let me not to the marriage of true minds
> Admit impediments. Love is not love
> Which alters when it alteration finds,
> Or bends with the remover to remove:
> O, no! it is an ever-fixed mark,
> That looks on tempests and is never shaken;
> It is the star to every wandering bark,
> Whose worth’s unknown, although his height be taken.
> Love’s not Time’s fool, though rosy lips and cheeks
> Within his bending sickle’s compass come;
> Love alters not with his brief hours and weeks,
> But bears it out even to the edge of doom.


> If this be error, and upon me prov’d,
> I never writ, nor no man ever lov’d.


*Sonnet 116*, by William Shakespeare.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from unexpectedly chilly California,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower

-- 
Thomas Wouters 
___
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/DZTOHOQGRABWP5WXKFAFUC4FTAFIT2ML/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Wes Turner]

Heads up: if CPython is JIT faster, it may then be (even more) vulnerable
to branch prediction vulns like Spectre and Meltdown:
https://groups.google.com/g/dev-python/c/67Et2KtpzG4

There's not a PEP for this work either, and one will need to be rebased
first, and are there even merge collisions?

On Thu, Feb 23, 2023, 9:00 PM Kevin Modzelewski  wrote:

> Ah ok thanks for the tip, I re-posted this as
> https://discuss.python.org/t/contributing-the-pyston-jit/24195
>
> On Thu, Feb 23, 2023 at 6:02 PM Brett Cannon  wrote:
>
>> FYI you will probably get more engagement if you posted this to
>> discuss.python.org .
>>
>> On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski  wrote:
>>
>>> Hello all, we on the Pyston team would like to propose the contribution
>>> of our JIT
>>>  
>>> into
>>> CPython main. We're interested in some initial feedback on this idea before
>>> putting in the work to rebase the jit to 3.12 for a PEP and more formal
>>> discussion.
>>>
>>> Our jit is designed to be simple and to generate code quickly, so we
>>> believe it's a good point on the design tradeoff curve for potential
>>> inclusion. The runtime behavior is intentionally kept almost completely the
>>> same as the interpreter, just lowered to machine code and with
>>> optimizations applied.
>>>
>>> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
>>> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
>>> potential speedup of our jit rebased onto 3.12 because there is overlap
>>> between what our jit does and the optimizations that have gone into the
>>> interpreter since 3.8, but there are several optimizations that would be
>>> additive with the current performance work:
>>> - Eliminating bytecode dispatch overhead
>>> - Mostly-eliminating stack management overhead
>>> - Reducing the number of reference count operations in the interpreter
>>> - Faster function calls, particularly of C functions
>>> - More specialization opportunities, both because a jit is not limited
>>> by bytecode limits, but also because it is able to do dynamic
>>> specializations that are not possible in an interpreter context
>>>
>>> There is also room for more optimizations -- in Pyston we've
>>> co-optimized the interpreter+jit combination such as by doing more
>>> extensive profiling in the interpreter. Our plan would be to submit an
>>> initial version that does not contain these optimizations in order to
>>> minimize the diff, and add them later.
>>>
>>> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
>>> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
>>> x86_64. Now that we have two architectures supported, adding additional
>>> ones is not too much work.
>>>
>>> We think that our jit fits nicely in the technical roadmap of the Faster
>>> CPython project, but conflicts with their plan to build a new custom
>>> tracing jit.
>>>
>>>
>>> As mentioned, we'd love to get feedback about the overall appetite for
>>> including a jit in CPython!
>>>
>>> kmod
>>> ___
>>> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
>>> 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/TUTSBGG7D7HW6MFHVX46IQDWAF3MJJLS/
> 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/6DUSEL5UHLS3NDIAFN4K3LOUAR5C72QF/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Kevin Modzelewski]

Ah ok thanks for the tip, I re-posted this as
https://discuss.python.org/t/contributing-the-pyston-jit/24195

On Thu, Feb 23, 2023 at 6:02 PM Brett Cannon  wrote:

> FYI you will probably get more engagement if you posted this to
> discuss.python.org .
>
> On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski  wrote:
>
>> Hello all, we on the Pyston team would like to propose the contribution
>> of our JIT
>>  
>> into
>> CPython main. We're interested in some initial feedback on this idea before
>> putting in the work to rebase the jit to 3.12 for a PEP and more formal
>> discussion.
>>
>> Our jit is designed to be simple and to generate code quickly, so we
>> believe it's a good point on the design tradeoff curve for potential
>> inclusion. The runtime behavior is intentionally kept almost completely the
>> same as the interpreter, just lowered to machine code and with
>> optimizations applied.
>>
>> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
>> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
>> potential speedup of our jit rebased onto 3.12 because there is overlap
>> between what our jit does and the optimizations that have gone into the
>> interpreter since 3.8, but there are several optimizations that would be
>> additive with the current performance work:
>> - Eliminating bytecode dispatch overhead
>> - Mostly-eliminating stack management overhead
>> - Reducing the number of reference count operations in the interpreter
>> - Faster function calls, particularly of C functions
>> - More specialization opportunities, both because a jit is not limited by
>> bytecode limits, but also because it is able to do dynamic specializations
>> that are not possible in an interpreter context
>>
>> There is also room for more optimizations -- in Pyston we've co-optimized
>> the interpreter+jit combination such as by doing more extensive profiling
>> in the interpreter. Our plan would be to submit an initial version that
>> does not contain these optimizations in order to minimize the diff, and add
>> them later.
>>
>> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
>> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
>> x86_64. Now that we have two architectures supported, adding additional
>> ones is not too much work.
>>
>> We think that our jit fits nicely in the technical roadmap of the Faster
>> CPython project, but conflicts with their plan to build a new custom
>> tracing jit.
>>
>>
>> As mentioned, we'd love to get feedback about the overall appetite for
>> including a jit in CPython!
>>
>> kmod
>> ___
>> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
>> 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/TUTSBGG7D7HW6MFHVX46IQDWAF3MJJLS/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Brett Cannon]

FYI you will probably get more engagement if you posted this to
discuss.python.org .

On Thu, Feb 23, 2023, 10:18 Kevin Modzelewski  wrote:

> Hello all, we on the Pyston team would like to propose the contribution of
> our JIT
>  
> into
> CPython main. We're interested in some initial feedback on this idea before
> putting in the work to rebase the jit to 3.12 for a PEP and more formal
> discussion.
>
> Our jit is designed to be simple and to generate code quickly, so we
> believe it's a good point on the design tradeoff curve for potential
> inclusion. The runtime behavior is intentionally kept almost completely the
> same as the interpreter, just lowered to machine code and with
> optimizations applied.
>
> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
> potential speedup of our jit rebased onto 3.12 because there is overlap
> between what our jit does and the optimizations that have gone into the
> interpreter since 3.8, but there are several optimizations that would be
> additive with the current performance work:
> - Eliminating bytecode dispatch overhead
> - Mostly-eliminating stack management overhead
> - Reducing the number of reference count operations in the interpreter
> - Faster function calls, particularly of C functions
> - More specialization opportunities, both because a jit is not limited by
> bytecode limits, but also because it is able to do dynamic specializations
> that are not possible in an interpreter context
>
> There is also room for more optimizations -- in Pyston we've co-optimized
> the interpreter+jit combination such as by doing more extensive profiling
> in the interpreter. Our plan would be to submit an initial version that
> does not contain these optimizations in order to minimize the diff, and add
> them later.
>
> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
> x86_64. Now that we have two architectures supported, adding additional
> ones is not too much work.
>
> We think that our jit fits nicely in the technical roadmap of the Faster
> CPython project, but conflicts with their plan to build a new custom
> tracing jit.
>
>
> As mentioned, we'd love to get feedback about the overall appetite for
> including a jit in CPython!
>
> kmod
> ___
> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
> 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/ZUF5ZYFNFHVMVPCJMSQA23MCVM2OPJTN/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Brett Cannon]

On Thu, Feb 23, 2023, 11:34 Wes Turner  wrote:

> Please consider colesbury/nogil in rebasing?
> https://github.com/colesbury/nogil
>

It's very premature for anyone to concern themselves with Sam's nogil work
when it comes to their own work as PEP 703 has not been sent to the SC (let
alone been accepted).


>
> On Thu, Feb 23, 2023, 1:20 PM Kevin Modzelewski  wrote:
>
>> Hello all, we on the Pyston team would like to propose the contribution
>> of our JIT
>>  
>> into
>> CPython main. We're interested in some initial feedback on this idea before
>> putting in the work to rebase the jit to 3.12 for a PEP and more formal
>> discussion.
>>
>> Our jit is designed to be simple and to generate code quickly, so we
>> believe it's a good point on the design tradeoff curve for potential
>> inclusion. The runtime behavior is intentionally kept almost completely the
>> same as the interpreter, just lowered to machine code and with
>> optimizations applied.
>>
>> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
>> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
>> potential speedup of our jit rebased onto 3.12 because there is overlap
>> between what our jit does and the optimizations that have gone into the
>> interpreter since 3.8, but there are several optimizations that would be
>> additive with the current performance work:
>> - Eliminating bytecode dispatch overhead
>> - Mostly-eliminating stack management overhead
>> - Reducing the number of reference count operations in the interpreter
>> - Faster function calls, particularly of C functions
>> - More specialization opportunities, both because a jit is not limited by
>> bytecode limits, but also because it is able to do dynamic specializations
>> that are not possible in an interpreter context
>>
>> There is also room for more optimizations -- in Pyston we've co-optimized
>> the interpreter+jit combination such as by doing more extensive profiling
>> in the interpreter. Our plan would be to submit an initial version that
>> does not contain these optimizations in order to minimize the diff, and add
>> them later.
>>
>> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
>> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
>> x86_64. Now that we have two architectures supported, adding additional
>> ones is not too much work.
>>
>> We think that our jit fits nicely in the technical roadmap of the Faster
>> CPython project, but conflicts with their plan to build a new custom
>> tracing jit.
>>
>>
>> As mentioned, we'd love to get feedback about the overall appetite for
>> including a jit in CPython!
>>
>> kmod
>> ___
>> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
>> 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/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/
> 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/6QS5NJUIX4OB645IFIGMQM2UHNECSQMG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Contributing the Pyston jit?

[Wes Turner]

Please consider colesbury/nogil in rebasing?
https://github.com/colesbury/nogil

On Thu, Feb 23, 2023, 1:20 PM Kevin Modzelewski  wrote:

> Hello all, we on the Pyston team would like to propose the contribution of
> our JIT
>  
> into
> CPython main. We're interested in some initial feedback on this idea before
> putting in the work to rebase the jit to 3.12 for a PEP and more formal
> discussion.
>
> Our jit is designed to be simple and to generate code quickly, so we
> believe it's a good point on the design tradeoff curve for potential
> inclusion. The runtime behavior is intentionally kept almost completely the
> same as the interpreter, just lowered to machine code and with
> optimizations applied.
>
> Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
> speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
> potential speedup of our jit rebased onto 3.12 because there is overlap
> between what our jit does and the optimizations that have gone into the
> interpreter since 3.8, but there are several optimizations that would be
> additive with the current performance work:
> - Eliminating bytecode dispatch overhead
> - Mostly-eliminating stack management overhead
> - Reducing the number of reference count operations in the interpreter
> - Faster function calls, particularly of C functions
> - More specialization opportunities, both because a jit is not limited by
> bytecode limits, but also because it is able to do dynamic specializations
> that are not possible in an interpreter context
>
> There is also room for more optimizations -- in Pyston we've co-optimized
> the interpreter+jit combination such as by doing more extensive profiling
> in the interpreter. Our plan would be to submit an initial version that
> does not contain these optimizations in order to minimize the diff, and add
> them later.
>
> Our jit uses the DynASM assembler library (part of LuaJIT) to generate
> machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
> x86_64. Now that we have two architectures supported, adding additional
> ones is not too much work.
>
> We think that our jit fits nicely in the technical roadmap of the Faster
> CPython project, but conflicts with their plan to build a new custom
> tracing jit.
>
>
> As mentioned, we'd love to get feedback about the overall appetite for
> including a jit in CPython!
>
> kmod
> ___
> 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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
> 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/EL7O7TJNYBFH2MRAV2AZCBUWV2TVUXMW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Contributing the Pyston jit?

[Kevin Modzelewski]

Hello all, we on the Pyston team would like to propose the contribution of
our JIT
 into
CPython main. We're interested in some initial feedback on this idea before
putting in the work to rebase the jit to 3.12 for a PEP and more formal
discussion.

Our jit is designed to be simple and to generate code quickly, so we
believe it's a good point on the design tradeoff curve for potential
inclusion. The runtime behavior is intentionally kept almost completely the
same as the interpreter, just lowered to machine code and with
optimizations applied.

Our jit currently targets Python 3.7-3.10, and on 3.8 it achieves a 10%
speedup on macrobenchmarks (similar to 3.11). It's hard to estimate the
potential speedup of our jit rebased onto 3.12 because there is overlap
between what our jit does and the optimizations that have gone into the
interpreter since 3.8, but there are several optimizations that would be
additive with the current performance work:
- Eliminating bytecode dispatch overhead
- Mostly-eliminating stack management overhead
- Reducing the number of reference count operations in the interpreter
- Faster function calls, particularly of C functions
- More specialization opportunities, both because a jit is not limited by
bytecode limits, but also because it is able to do dynamic specializations
that are not possible in an interpreter context

There is also room for more optimizations -- in Pyston we've co-optimized
the interpreter+jit combination such as by doing more extensive profiling
in the interpreter. Our plan would be to submit an initial version that
does not contain these optimizations in order to minimize the diff, and add
them later.

Our jit uses the DynASM assembler library (part of LuaJIT) to generate
machine code. Our jit currently supports Mac and Linux, 64-bit ARM and
x86_64. Now that we have two architectures supported, adding additional
ones is not too much work.

We think that our jit fits nicely in the technical roadmap of the Faster
CPython project, but conflicts with their plan to build a new custom
tracing jit.


As mentioned, we'd love to get feedback about the overall appetite for
including a jit in CPython!

kmod
___
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/7HTSM36GBTP4H5HEUV4JMCDSVYVFFGGV/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.11.2, 3.10.10

[אורי]

Hi,

I was surprised that Python 3.11.2 and 3.10.10 have been released without a
notice to this mailing list. What happened?

Thanks,
Uri.
אורי
u...@speedy.net


On Wed, Dec 7, 2022 at 1:03 AM Łukasz Langa  wrote:

> Greetings! We bring you a slew of releases this fine Saint Nicholas /
> Sinterklaas day. Six simultaneous releases has got to be some record.
> There’s one more record we broke this time, you’ll see below.
>
> In any case, updating is recommended due to security content:
>
> 3.7 - 3.12: gh-98739 :
> Updated bundled libexpat to 2.5.0 to fix CVE-2022-43680 <
> https://nvd.nist.gov/vuln/detail/CVE-2022-43680> (heap use-after-free).
> 3.7 - 3.12: gh-98433 :
> The IDNA codec decoder used on DNS hostnames by socket or asyncio related
> name resolution functions no longer involves a quadratic algorithm to fix
> CVE-2022-45061 . This
> prevents a potential CPU denial of service if an out-of-spec excessive
> length hostname involving bidirectional characters were decoded. Some
> protocols such as urllib http 3xx redirects potentially allow for an
> attacker to supply such a name.
> 3.7 - 3.12: gh-11 :
> python -m http.server no longer allows terminal control characters sent
> within a garbage request to be printed to the stderr server log.
> 3.8 - 3.12: gh-87604 :
> Avoid publishing list of active per-interpreter audit hooks via the gc
> module.
> 3.9 - 3.10 (already released in 3.11+ before): gh-97514 <
> https://github.com/python/cpython/issues/97514>: On Linux the
> multiprocessing module returns to using filesystem backed unix domain
> sockets for communication with the forkserver process instead of the Linux
> abstract socket namespace. Only code that chooses to use the “forkserver”
> start method is affected. This prevents Linux CVE-2022-42919 <
> https://nvd.nist.gov/vuln/detail/CVE-2022-42919> (potential privilege
> escalation) as abstract sockets have no permissions and could allow any
> user on the system in the same network namespace (often the whole system)
> to inject code into the multiprocessing forkserver process. This was a
> potential privilege escalation. Filesystem based socket permissions
> restrict this to the forkserver process user as was the default in Python
> 3.8 and earlier.
> 3.7 - 3.10: gh-98517 :
> Port XKCP’s fix for the buffer overflows in SHA-3 to fix CVE-2022-37454 <
> https://nvd.nist.gov/vuln/detail/CVE-2022-37454>.
> 3.7 - 3.9 (already released in 3.10+ before): gh-68966 <
> https://github.com/python/cpython/issues/68966>: The deprecated mailcap
> module now refuses to inject unsafe text (filenames, MIME types,
> parameters) into shell commands to address CVE-2015-20107 <
> https://nvd.nist.gov/vuln/detail/CVE-2015-20107>. Instead of using such
> text, it will warn and act as if a match was not found (or for test
> commands, as if the test failed).
>  <
> https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3120-alpha-3-1>Python
> 3.12.0 alpha 3
>
> Get it here, read the change log, sing a GPT-3-generated Sinterklaas song:
>
> https://www.python.org/downloads/release/python-3120a3/ <
> https://www.python.org/downloads/release/python-3120a3/>
>
> 216 new commits since 3.12.0 alpha 2 last month.
>
>  <
> https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3111-2>Python
> 3.11.1
>
> Get it here, see the change log, read the recipe for quark soup:
>
> https://www.python.org/downloads/release/python-3111/ <
> https://www.python.org/downloads/release/python-3111/>
>
> A whopping 495 new commits since 3.11.0. This is a massive increase of
> changes comparing to 3.10 at the same stage in the release cycle: there
> were “only” 339 commits between 3.10.0 and 3.10.1.
>
>  <
> https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3109-3>Python
> 3.10.9
>
> Get it here, read the change log, see circular patterns:
>
> https://www.python.org/downloads/release/python-3109/ <
> https://www.python.org/downloads/release/python-3109/>
>
> 165 new commits.
>
>  <
> https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3916-4>Python
> 3.9.16
>
> Get it here, read the change log, consider upgrading to a newer version:
>
> https://www.python.org/downloads/release/python-3916/ <
> https://www.python.org/downloads/release/python-3916/>
>
> Security-only release with no binaries. 10 commits.
>
>  <
> https://discuss.python.org/t/python-3-11-1-3-10-9-3-9-16-3-8-16-3-7-16-and-3-12-0-alpha-3-are-now-available/21724#python-3816-5>Python
> 

[Python-Dev] [RELEASE] Python 3.11.2, Python 3.10.10 and 3.12.0 alpha 5 are available

[Pablo Galindo Salgado]

Hi everyone,

I am happy to report that after solving some last-time problems we have a
bunch of fresh releases for you:

### Python 3.12.0 alpha 5

Check the new alpha of 3.12 with some Star Trek vibes:

https://www.python.org/downloads/release/python-3120a5/

210 new commits since 3.12.0a4 last month

### Python 3.11.2

A shipment of bugfixes and security releases for the newest Python!

https://www.python.org/downloads/release/python-3112/

194 new commits since 3.11.1

### Python 3.10.10

Your trusty Python3.10 just got more stable and secure!

https://www.python.org/downloads/release/python-31010/

131 new commits since 3.10.9

## We hope you enjoy the new releases!

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

https://www.python.org/psf/

Your friendly release team,

Ned Deily @nad
Steve Dower @steve.dower
Pablo Galindo Salgado @pablogsal
Łukasz Langa @ambv
Thomas Wouters @thomas
___
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/P4JHHHAAO4L4KFZQ6PX5J3JRPAZUXJWJ/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python Language Summit at PyCon US 2023 in Salt Lake City

[Łukasz Langa]

We’re excited to announce that the signups for the Python Language Summit at 
PyCon US 2023 are now open.

Full details at: https://us.pycon.org/2023/events/language-summit/ 

Just like in 2022, we are doing the Summit as an in-person event. We will be 
following the health and safety guidelines 
 of the wider 
conference.


 
TL;DR

When: Wednesday, April 19, 2023 at 10:00am
Where: Salt Palace Convention Center, room TBD

Sign up to attend: https://forms.gle/YnWL1Hts6zDtdSgn7 
 (closes March 5th, 2023 AoE)


 
Who
 can attend

We welcome Python core developers and triage team members, active contributors 
to CPython and alternative Python implementations, and other community members 
with a topic to discuss with core developers.


 
Who
 can propose a discussion topic

If you have discussion items; seeking consensus; awaiting decision on a PEP; 
needing help with your core dev work; or have specific questions that need 
answers from core developers, please submit a proposal. According to feedback, 
our audience prefers more discussions and shorter talks.

In your proposal, please include the following:

why is this topic relevant to the core developers;
what is needed from core developers out of this topic.

 
How
 can I learn what’s happening at the event?

Like in 2022, this year’s event will be covered by @AlexWaygood 
. A detailed summary of the event 
will be published on the Python Software Foundation Blog 
.


 
Is
 this event recorded? Can I watch the live stream?

No, there will be no recording and no live stream available. If you’d like to 
participate in discussions, please sign up to attend. If you’d like to listen 
in, please wait for Alex’s blog posts after the Summit.


 
We
 hope you have a great event!

Your Language Summit cat herding team,
@ambv  & @Senthil 



signature.asc
Description: Message signed with OpenPGP
___
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/WLO2MCT2RMSE6XDI3LBUACUQR7YWQAZE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Joshua Herman]

The easiest and straightforward way to help python would be taking the mantle 
of implementing PEP 638 or restarting the development of a library for 
syntactic macros since you believe it will be a benefit to Python in general.

Sent from my iPhone

> On Feb 5, 2023, at 3:58 PM, cd...@cam.ac.uk wrote:
> 
> 
>> 
>> Python has consistently refused to be turned into a platform for DSLs for 
>> almost 3 decades. 
> 
> I think SymPy, PyMC, Pyomo, Pyro, and many more packages would all be very 
> surprised to hear they're no longer welcome in Python. Still, it seems like 
> it would be quite hard to kick them out, and would probably make the 
> scientific programming community pretty angry. If you don't like having DSLs 
> in Python, I think you're trying to close the barn door after the horse has 
> bolted; you'd have to go back in time to the creation of NumPy. 
> 
> Syntactic macros aren't necessary for DSLs; it just makes them better. 
> Without syntactic macros, DSLs are forced to use clunky, complicated, and 
> error-prone string manipulation, rather than cleaner syntactic 
> transformations.  For instance, here's NumPy's einsum, effectively behaving 
> like a string macro:
> ```
> X = np.einsum('ij,jk->ik', A, B, optimize='optimal')
> ```
> 
> And now here's the same thing in Julia:
> ```
> @einsum X[i, k] := A[i, j] * B[j, k]
> ```
> 
> Which is more readable? Which is more Pythonic? 
> 
> It's not that Python doesn't have DSLs (NumPy is effectively a DSL for linear 
> algebra). It's just that their syntax is sufficiently obscure that it's not 
> at all clear that's what they're doing.
> ___
> 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/RWSSY4KZLQYXHFF34AR544C44NZ6K7XE/
> 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/HT4NRQ7BYJLUGRQ33HOI45QBG4EC2PIO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[cdp49]

> Python has consistently refused to be turned into a platform for DSLs for 
> almost 3 decades. 

I think SymPy, PyMC, Pyomo, Pyro, and many more packages would all be very 
surprised to hear they're no longer welcome in Python. Still, it seems like it 
would be quite hard to kick them out, and would probably make the scientific 
programming community pretty angry. If you don't like having DSLs in Python, I 
think you're trying to close the barn door after the horse has bolted; you'd 
have to go back in time to the creation of NumPy. 

Syntactic macros aren't necessary for DSLs; it just makes them better. Without 
syntactic macros, DSLs are forced to use clunky, complicated, and error-prone 
string manipulation, rather than cleaner syntactic transformations.  For 
instance, here's NumPy's einsum, effectively behaving like a string macro:
```
X = np.einsum('ij,jk->ik', A, B, optimize='optimal')
```

And now here's the same thing in Julia:
```
@einsum X[i, k] := A[i, j] * B[j, k]
```

Which is more readable? Which is more Pythonic? 

It's not that Python doesn't have DSLs (NumPy is effectively a DSL for linear 
algebra). It's just that their syntax is sufficiently obscure that it's not at 
all clear that's what they're doing.
___
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/RWSSY4KZLQYXHFF34AR544C44NZ6K7XE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Jelle Zijlstra]

El vie, 3 feb 2023 a las 8:01, Stéfane Fermigier ()
escribió:

> "
>
>
> On Fri, Feb 3, 2023 at 12:28 PM Stephen J. Turnbull <
> stephenjturnb...@gmail.com> wrote:
>
>> Stéfane Fermigier writes:
>>
>>  > NB: on a very basic level, I remember trying, a few years ago, to use
>> the
>>  > Unicode "empty set" symbol as a synonym for set(), and it didn't end
>> well,
>>  > for several reasons, including the fact that Python didn't like it as a
>>  > variable name.
>>
>> I know about the issue that '∅' is not valid in identifiers, but I'm
>> curious about these other "several reasons".
>>
>
> IIRC (this was a few years back):  '∅' (aka EMPTY SET) was not accepted by
> Python, so I used instead ''Ø" (aka "LATIN CAPITAL LETTER O WITH STROKE").
>
> Python was OK with it, but some of the tools I use (one of flake8, isort,
> black... or maybe one of my IDE) barfed on it.
>

Black is fine with it; we've had the empty set symbol in our own source
code since the beginning (
https://github.com/psf/black/blob/b0d1fba7ac3be53c71fb0d3211d911e629f8aecb/src/black/linegen.py#L455
now). I believe we've had someone ask that we remove it because it was
breaking some tool that was processing the Black source code, but Łukasz
wasn't having it.


>
>   S.
>
> --
> Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier
> - http://linkedin.com/in/sfermigier
> Founder & CEO, Abilian - Enterprise Social Software -
> http://www.abilian.com/
> Co-Founder & Co-Chairman, National Council for Free & Open Source Software
> (CNLL) - http://cnll.fr/
> Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
> Libre (APELL) - https://www.apell.info/
> Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
> https://www.euclidia.eu/
>
> "I wish you were as accurate, & as much to be relied on, as I am myself"
> - Lady Ada Lovelace
> ___
> 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/H2UALG4YAA6IBMZQMWEL2QIOPDPK4RTG/
> 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/2VWIJNEP7WBKXJN5XC6LG375THKBUGUL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stéfane Fermigier]

"


On Fri, Feb 3, 2023 at 12:28 PM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> Stéfane Fermigier writes:
>
>  > NB: on a very basic level, I remember trying, a few years ago, to use
> the
>  > Unicode "empty set" symbol as a synonym for set(), and it didn't end
> well,
>  > for several reasons, including the fact that Python didn't like it as a
>  > variable name.
>
> I know about the issue that '∅' is not valid in identifiers, but I'm
> curious about these other "several reasons".
>

IIRC (this was a few years back):  '∅' (aka EMPTY SET) was not accepted by
Python, so I used instead ''Ø" (aka "LATIN CAPITAL LETTER O WITH STROKE").

Python was OK with it, but some of the tools I use (one of flake8, isort,
black... or maybe one of my IDE) barfed on it.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/

"I wish you were as accurate, & as much to be relied on, as I am myself" -
Lady Ada Lovelace
___
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/H2UALG4YAA6IBMZQMWEL2QIOPDPK4RTG/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

Stéfane Fermigier writes:

 > NB: on a very basic level, I remember trying, a few years ago, to use the
 > Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
 > for several reasons, including the fact that Python didn't like it as a
 > variable name.

I know about the issue that '∅' is not valid in identifiers, but I'm
curious about these other "several reasons".



___
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/7OHL242ZWVOYTBKTZOC72PQK5V4BKX2I/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[David Mertz, Ph.D.]

On Thu, Feb 2, 2023 at 12:46 PM Stéfane Fermigier  wrote:

> https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
> https://oeis.org/wiki/List_of_LaTeX_mathematical_symbols
> NB: on a very basic level, I remember trying, a few years ago, to use the
> Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
> for several reasons, including the fact that Python didn't like it as a
> variable name.
>

I use the `vim` conceal plugin to make some of these appear on screen while
I'm editing. So, for example, when I type `set()` I see `∅`.  When I type
`all(...)` I see `∀(...)`.

Much to the chagrin of Moshe Zadka, when I type `None` I see `ℵ` ...
because I argue that ℵ_0 really should be considered an inaccessible
cardinal :-).

However, it never causes me problems because the files on disk are just
plain old ASCII (for the most part), and the special symbols are just what
my screen shows, not overloads to underlying operators.

-- 
The dead increasingly dominate and strangle both the living and the
not-yet born.  Vampiric capital and undead corporate persons abuse
the lives and control the thoughts of homo faber. Ideas, once born,
become abortifacients against new conceptions.
___
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/3BFWMNHH5VMVROWNKH77ORZL2ECDPP7C/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stéfane Fermigier]

On Thu, Feb 2, 2023 at 8:34 AM Stephen J. Turnbull <
stephenjturnb...@gmail.com> wrote:

> cd...@cam.ac.uk writes:
>
>  > I don't want to be forced to learn lots of weird little functions
>  > like `np.matmul(x1, x2)` when there's already one obvious syntax
>  > I'm very familiar with: `x1 * x2`.
>
> I don't recall ever writing matrix multiplication that way in
> mathematics though.  That's universally written as juxtaposition in my
> experience.  And the obvious way to write it in Python (and np) has
> been "x1 @ x2" for some years now.  In np, "*" means element-wise
> multiplication, I believe.
>

My 2 cents as a former mathematician:

Mathematicians have come up with hundreds of symbols to express the variety
of structures they are dealing with.

Just to list a few:

https://en.wikipedia.org/wiki/Mathematical_operators_and_symbols_in_Unicode
https://oeis.org/wiki/List_of_LaTeX_mathematical_symbols

So +, *, -, /, @ and ** are a good start to express the most common
mathematical structures (groups, rings, vector spaces), and <, >, <=, >=,
==, != for ordered sets, but that's it.

It's great that Python supports overloading these operations. That's
something that drew me to Python when I was still working in computational
number theory, 25 years ago.

But that's probably not enough for some people. A way to add new symbols
(including non-ascii Unicode characters) and operations could have some
value, but also the drawback of tremendous additional complexity, specially
if done in the most generic way.

NB: on a very basic level, I remember trying, a few years ago, to use the
Unicode "empty set" symbol as a synonym for set(), and it didn't end well,
for several reasons, including the fact that Python didn't like it as a
variable name.

  S.

-- 
Stefane Fermigier - http://fermigier.com/ - http://twitter.com/sfermigier -
http://linkedin.com/in/sfermigier
Founder & CEO, Abilian - Enterprise Social Software -
http://www.abilian.com/
Co-Founder & Co-Chairman, National Council for Free & Open Source Software
(CNLL) - http://cnll.fr/
Co-Founder & Chairman, Association Professionnelle Européenne du Logiciel
Libre (APELL) - https://www.apell.info/
Co-Founder & Spokesperson, European Cloud Industrial Alliance (EUCLIDIA) -
https://www.euclidia.eu/

"I wish you were as accurate, & as much to be relied on, as I am myself" -
Lady Ada Lovelace
___
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/G2XSNXZSTPCDUDIUFHURGIBQ4HO7SG5B/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

cd...@cam.ac.uk writes:

 > I think that's exactly the problem with a lack of Python
 > macros. The full quote, of course, goes: "There should be one-- and
 > preferably only one --*obvious* way to do it."

You understand that the Zen is humorous?  Most of the Zen, if taken
universally and seriously, advocates the impossible.  And as a whole,
it's definitely impossible even in the limited scope it's intended to
apply to -- it's internally inconsistent.

 > Often, there's a mathematical notation for something, and *this* is
 > the only obvious way to write anything out.

But that's not the way Python looks at it, you see.  First, "a"
mathematical notation doesn't exclude multiple notations, and for most
mathematical concepts there are indeed multiple common notations (eg,
for multiplication, juxtaposition of the factors, *, ・, and × are all
in common use depending on the kind of multiplication).  I'm pretty
sure Tim Peters was well aware of such.  Frequently the most commonly
used expressions are really ugly (at least in my experience in
mathematical applications to game theory ;-).  Now, you can recover
your position from that issue by appealing to other more or less Zen
desiderata (readability counts, for example), but they're not quite as
strong arguments here.

The second objection is more serious: the Zen is intended to be
restricted to Python.  "There should be one-- and preferably only one
--obvious way to do it [*in Python*]."  Guido (and the other OG core
devs) wanted consistent and obvious ways to do it *in Python*.  The
consistent and obvious way to write "X ~ N(0,1)" (oops, not so obvious
after all!) in Python is "X = Normal(0,1)", where presumably the
Normal class provides facilities such as CDF and PDF as well as the
PRNG of random.normalvariate.

 > Not to mention, DSLs are forced to adopt all kinds of weird syntax

This is more or less intentional, though, as is the restriction to a
predefined set of operator symbols (you can't define ・ as an operator
symbol when you need two kinds of multiplication for example).  Python
has consistently refused to be turned into a platform for DSLs for
almost 3 decades.  Ruby and Lisps are better for that.

You don't have to like that (quite a few people don't, of course
that's why MacroPy was written), but it's really not un-Pythonic.
There is method to this madness: Python aims for readability and
flexibility for the community of Python programmers who might
encounter the code, rather than catering to authors and their domain
specialist community.  The fact that Python adoption is still growing
should tell you something about the preferences and needs of the
general Python community.

 > I don't want to be forced to learn lots of weird little functions
 > like `np.matmul(x1, x2)` when there's already one obvious syntax
 > I'm very familiar with: `x1 * x2`.

I don't recall ever writing matrix multiplication that way in
mathematics though.  That's universally written as juxtaposition in my
experience.  And the obvious way to write it in Python (and np) has
been "x1 @ x2" for some years now.  In np, "*" means element-wise
multiplication, I believe.

Perhaps some BDFL will arise to merge the benefits of Python with
those of Julia, but for the near term we're all going to have to
choose one or the other.

Steve

___
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/D2427HD63JN5MTBFQL2SZFBJU3UEXE3L/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[cdp49]

I think that's exactly the problem with a lack of Python macros. The full 
quote, of course, goes: "There should be one-- and preferably only one 
--*obvious* way to do it."

Often, there's a mathematical notation for something, and *this* is the only 
obvious way to write anything out. But this doesn't work if you force every 
package to adopt the same syntax. For example, if you'd like a package to work 
with probabilities, it's very reasonable to want to write `x ~ Normal(0, 1)` to 
say x follows a normal distribution. This is the only syntax I consider natural 
for this problem; but packages can't do that, since `~` already has a meaning 
outside of probability.

Not to mention, DSLs are forced to adopt all kinds of weird syntax when the 
behavior of base Python doesn't align with what the DSL needs to do. Obviously, 
the only way to write out a `for` loop should be to use the `for` keyword. This 
doesn't work in JAX. If you want to use a `for` loop in JAX, you have to use 
the `lax.fori_loop` function, or else `for` will end up being unrolled, because 
of various requirements of the JAX compiler. Having to use `lax.fori_loop` is, 
to put it mildly, *incredibly* unpythonic.

This really is the biggest reason I switched to Julia: Python math is 
unpythonic. I don't want to be forced to learn lots of weird little functions 
like `np.matmul(x1, x2)` when there's already one obvious syntax I'm very 
familiar with: `x1 *  x2`.
___
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/6QM4GMH5FDX2H5OZHCE33EOJHCV3TI2R/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[cdp49]

Unfortunately, it's no longer being maintained.
___
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/UEPTBUIK67NLNE4JBNN6JNJON3BRGSUK/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Stephen J. Turnbull]

Joshua Herman writes:

 > I think that this would be better as a library in my opinion. 

There's a third party package called MacroPy that provides macros,
although I haven't heard anything about it in a couple of years.

I seem to recall that it's a preprocessor that hooks into the import
system.

___
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/VRY55MMVRVZGHJRPPWWHKHLPPI2HLHZR/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[Joshua Herman]

I’ve used lisp and scheme and one reason why you wouldn’t want a syntactic 
macro is because there should be one and only one way to do a task.

Sure we have deviated that in the ecosystem but allowing syntactic macros can 
have the side effect of many programs or projects to have multiple ways to do 
something because they would have the feature .

I think that this would be better as a library in my opinion. 

Sent from my iPhone

> On Jan 29, 2023, at 2:20 PM, cd...@cam.ac.uk wrote:
> 
> It looks like this hasn't gone anywhere in the past few years, which is a 
> shame. Syntactic macros are one of the 2 or 3 "Killer features" that pushed 
> me out of Python and into Julia (along with JITting inferred types and 
> multiple dispatch). Math+data science code written in Julia is a lot more 
> readable because of this.
> ___
> 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/PPCXZJYPNNT6XZ6EQ35OQE4SG2QBAZRT/
> 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/TKMQKXLQYFQ5CWS76SW7UXFEDZOIXJ2E/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 638: Syntactic macros

[cdp49]

It looks like this hasn't gone anywhere in the past few years, which is a 
shame. Syntactic macros are one of the 2 or 3 "Killer features" that pushed me 
out of Python and into Julia (along with JITting inferred types and multiple 
dispatch). Math+data science code written in Julia is a lot more readable 
because of this.
___
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/PPCXZJYPNNT6XZ6EQ35OQE4SG2QBAZRT/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

[Steven D'Aprano]

On Thu, Jan 26, 2023 at 08:34:04PM +0100, Thomas Ratzke wrote:

> Hi all,
> 
> i would like to suggest the following Python feature. It naturally 
> happens that one want's to repeat the current iteration of a for loop 
> for example after an error happened.

Can you give an example of when you would do that?


> For this purpose, I usually set a 
> flag and put a while loop inside my for loop. A simple "repeat" 
> statement just like "continue" or "break" would make the code much more 
> readable.

Is the idea that it just restarts the current iteration, or that we 
rewind the program state (as in reversible debugging)?

The later would be very difficult.

I think this is an interesting concept, but I fear that it would be an 
attractive nuisance that ends up causing lots of infinite loops. If an 
error occurs during one iteration, or some other condition, and you 
re-run that iteration, surely the condition will continue to hold and 
you will re-run it again, leading to an infinite loop?

Unless the error is stochastic (e.g. depends on randomness, or 
environmental conditions which may change from one loop iteration to the 
next) repeating the loop won't change the conditions that cause the 
error. So I see that a `repeat` keyword would make it easy to turn a 
nice clear exception into an annoying infinite loop.

Your sketch of an example shows the problem:

> for _ in range(n):
>     ...
>     if not A:
>         repeat # repeat current iteration

Without changing the value of `A`, re-running the current iteration will 
just hit the `repeat` statement again and again and again, forever.


-- 
Steve
___
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/ZHXYRM4LN6UUFGGHIGGY5PTNWQSWJOY4/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

[Matthias Görgens]

I don't think 'repeat' should make it into the language.

But: it's an excellent test case to check how flexible the language already
is. Joao did a great job demonstrating what's possible!

On Thu, 26 Jan 2023, 21:15 Joao S. O. Bueno,  wrote:

> I don't think this will fly - if not for any other reason, it is a very
> rare pattern
> to take place alongside such important flow-control statements as
> continue and break
>
> But for your convenience, here is a small wrapper that, along with the
> walrus operator, could be used when you need that functionality:
>
> ```
> class Repeatable:
> def __init__(self, it):
> self.it = it
> self.repeat_last = False
> self.last_item = None
> def repeat(self):
> self.repeat_last = True
> def __iter__(self):
> for item in self.it:
> while self.repeat_last:
> self.repeat_last = False
> yield self.last_item
> self.last_item = item
> yield item
>
>
> test = 1
> for x in (rx:=Repeatable(range(3))):
> print(x)
> if x == test:
> test = -1
> rx.repeat()
> ```
>
> On Thu, Jan 26, 2023 at 4:41 PM Thomas Ratzke 
> wrote:
>
>> Hi all,
>>
>> i would like to suggest the following Python feature. It naturally
>> happens that one want's to repeat the current iteration of a for loop
>> for example after an error happened. For this purpose, I usually set a
>> flag and put a while loop inside my for loop. A simple "repeat"
>> statement just like "continue" or "break" would make the code much more
>> readable.
>>
>>
>> This is my solution at the moment with A being checked:
>>
>> for _ in range(n):
>>  flag = True
>>  while flag:
>>  ...
>>  if A:
>>  flag = False # go to next iteration
>>
>>
>> I would suggest the repeat statement in the following sense
>>
>> for _ in range(n):
>>  ...
>>  if not A:
>>  repeat # repeat current iteration
>>
>> Notice the "not" in the if clause. I am really looking forwars to hear
>> your opinions.
>>
>> Best regards
>> Thomas
>>
>> ___
>> 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/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/
>> 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/WWEJQD7IIPNC4FUSPHLXEH7SVN6EVK6H/
> 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/AJLFDS7RACGYZTGW4U4EAGP5DYMSOJDW/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

[Jen Kris via Python-Dev]

Why would "if not A" also be true when you repeat the current iteration?  What 
keeps this from becoming an endless loop?


Jan 26, 2023, 11:45 by thomasratzk...@outlook.de:

> Hi all,
>
> i would like to suggest the following Python feature. It naturally happens 
> that one want's to repeat the current iteration of a for loop for example 
> after an error happened. For this purpose, I usually set a flag and put a 
> while loop inside my for loop. A simple "repeat" statement just like 
> "continue" or "break" would make the code much more readable.
>
>
> This is my solution at the moment with A being checked:
>
> for _ in range(n):
>     flag = True
>     while flag:
>         ...
>         if A:
>             flag = False # go to next iteration
>
>
> I would suggest the repeat statement in the following sense
>
> for _ in range(n):
>     ...
>     if not A:
>         repeat # repeat current iteration
>
> Notice the "not" in the if clause. I am really looking forwars to hear your 
> opinions.
>
> Best regards
> Thomas
>
> ___
> 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/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/
> 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/S74XCQ6RWBZRO3F5GNAPT4DKKMFVAV2M/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

[Chris Angelico]

On Fri, 27 Jan 2023 at 06:42, Thomas Ratzke  wrote:
>
> Hi all,
>
> i would like to suggest the following Python feature. It naturally
> happens that one want's to repeat the current iteration of a for loop
> for example after an error happened. For this purpose, I usually set a
> flag and put a while loop inside my for loop. A simple "repeat"
> statement just like "continue" or "break" would make the code much more
> readable.
>
>
> This is my solution at the moment with A being checked:
>
> for _ in range(n):
>  flag = True
>  while flag:
>  ...
>  if A:
>  flag = False # go to next iteration
>

Why not use break?

ChrisA
___
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/BG3DUXYTZLMZAO3UK545C5YXNY3AA3VA/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Suggestion: "repeat" statement in loops

[Joao S. O. Bueno]

I don't think this will fly - if not for any other reason, it is a very
rare pattern
to take place alongside such important flow-control statements as
continue and break

But for your convenience, here is a small wrapper that, along with the
walrus operator, could be used when you need that functionality:

```
class Repeatable:
def __init__(self, it):
self.it = it
self.repeat_last = False
self.last_item = None
def repeat(self):
self.repeat_last = True
def __iter__(self):
for item in self.it:
while self.repeat_last:
self.repeat_last = False
yield self.last_item
self.last_item = item
yield item


test = 1
for x in (rx:=Repeatable(range(3))):
print(x)
if x == test:
test = -1
rx.repeat()
```

On Thu, Jan 26, 2023 at 4:41 PM Thomas Ratzke 
wrote:

> Hi all,
>
> i would like to suggest the following Python feature. It naturally
> happens that one want's to repeat the current iteration of a for loop
> for example after an error happened. For this purpose, I usually set a
> flag and put a while loop inside my for loop. A simple "repeat"
> statement just like "continue" or "break" would make the code much more
> readable.
>
>
> This is my solution at the moment with A being checked:
>
> for _ in range(n):
>  flag = True
>  while flag:
>  ...
>  if A:
>  flag = False # go to next iteration
>
>
> I would suggest the repeat statement in the following sense
>
> for _ in range(n):
>  ...
>  if not A:
>  repeat # repeat current iteration
>
> Notice the "not" in the if clause. I am really looking forwars to hear
> your opinions.
>
> Best regards
> Thomas
>
> ___
> 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/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/
> 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/WWEJQD7IIPNC4FUSPHLXEH7SVN6EVK6H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Feature Suggestion: "repeat" statement in loops

[Thomas Ratzke]

Hi all,

i would like to suggest the following Python feature. It naturally 
happens that one want's to repeat the current iteration of a for loop 
for example after an error happened. For this purpose, I usually set a 
flag and put a while loop inside my for loop. A simple "repeat" 
statement just like "continue" or "break" would make the code much more 
readable.



This is my solution at the moment with A being checked:

for _ in range(n):
    flag = True
    while flag:
        ...
        if A:
            flag = False # go to next iteration


I would suggest the repeat statement in the following sense

for _ in range(n):
    ...
    if not A:
        repeat # repeat current iteration

Notice the "not" in the if clause. I am really looking forwars to hear 
your opinions.


Best regards
Thomas

___
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/LNER4MH6IT6HBFKFVTUOJ225PTCZSRRC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Switching to Discourse

[Alex Krupp via Python-Dev]

> This does not solve the problem of engaging actively in a discussion, of
course

I just submitted a proposal to create a Discourse plugin to improve the
accuracy of their inbound email parsing, which is something that several
people have complained about in this thread. This would enable two things:

   - Folks who prefer to live in their inbox could continue to do so and
   contribute by just replying to emails. Discourse currently has
   reply-by-email, but it often mangles formatting and/or entirely deletes
   text. Once these issues are fixed, folks who like the current experience
   would be able to just pretend the forum doesn't exist and continue having
   the same experience as they currently have with GNU Mailman.
   - Right now importing the archives from GNU Mailman into Discourse isn't
   realistic for the same reasons; some messages will import correctly, but
   others will be mangled or missing text. This means you would still need to
   maintain the Malman archive as the canonical source of truth. Once fixed,
   not only would the [Python-Dev] archives be searchable within Discourse,
   but they should also rank better in search than they do in their current
   archive.

If this is something you care about (positively or negatively), here is the
exploratory proposal:

https://meta.discourse.org/t/proposed-plugin-to-improve-reply-by-email-accuracy/252944

Any feedback and/or testing would be much appreciated! Right now Discourse
recognizes that this is a problem and is interested in solving it, but
getting it prioritized will require folks to A) speak up saying they want
it done B) test the underlying API to verify that it actually solves the
problem.

Alex

On Sun, Dec 11, 2022 at 1:54 PM Tiziano Zito  wrote:

>
> On Sat 10 Dec, 17:47 +0100, Baptiste Carvello <
> devel2...@baptiste-carvello.net> wrote:
> >There is a small catch though: unless I'm mistaken, Discourse won't let
> >you subscribe to just a set of categories, so any filtering has to
> >happen on the Mailman side.
>
> Well, it is actually possible to achieve what you want.
>
> I have set up Discourse in mailing-list mode [1].
>
> By default muted categories are not included in the emails you get in
> mailing list mode.
>
> So, you just need to mute all categories you don't care about. It is a bit
> of work, but it needs to be done only once. To have an almost complete
> equivalent of the topics that were once discussed on python-dev, you can
> just mute every thing except the "Core Development" category. This is the
> setting I am using since a while and I am quite happy with it. You may want
> to unmute the "PEPs" category as well.
>
> Threading info is kept quite nicely, so I read the discourse mail
> notifications as if it were a mailing list and I almost do not see any
> difference. Text is sometimes a bit messy if people heavily use the
> discourse formatting capabilities, but this kind of posts are quite rare in
> my experience.
>
> This does not solve the problem of engaging actively in a discussion, of
> course, but at least for me it is OK to login to discourse if I have to
> post, given that 99.99% of the time I just want to read posts in my mail
> client.
>
> Ciao!
> Tiziano
>
> [1] You can do this while editing your profile preferences, under the
> "Emails" menu
> ___
> 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/7ZJWPADSL7BGBZ5Y6BRHP2LDTHQFZ7UV/
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 

Alex Krupp
Cell: (607) 351 2671

Read my Email: www.fwdeveryone.com/u/alex3917
Subscribe to my blog: https://alexkrupp.typepad.com/
My homepage: www.alexkrupp.com
___
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/Y3BO5TBIM2YQXWCQ4D4RPOBBIDVHNXAL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] [Suspected Spam]Requesting a review on a PR

[Stephen J. Turnbull]

Wheeler Law writes:

 > I opened an issue[1] related to respecting the
 > `http.client.HTTPConnection.debuglevel` value; I opened a
 > subsequent PR[2] that fixes the issue back in November and I was
 > wondering if I could get some feedback on it.

I can't help you with that, but this list is now pretty much
deprecated in favor of developer channels on discuss.python.org.
Sorry I can't be more help in directing you to which channel, I
haven't been following dev closely for quite a while (still hoping to
get back into it though!)


___
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/E4WE3B6VQKWV7WAWSBRIFD3NO6MSVH4H/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Requesting a review on a PR

[Wheeler Law]

Greetings folks, 

I opened an issue[1] related to respecting the 
`http.client.HTTPConnection.debuglevel` value; I opened a subsequent PR[2] that 
fixes the issue back in November and I was wondering if I could get some 
feedback on it. 

Kind regards,
Wheeler

[1]: https://github.com/python/cpython/issues/99352
[2]: https://github.com/python/cpython/pull/99353
___
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/VIWBQX6KU3PXS6OJR3BN3I3LULWMB255/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Exception compatibility with aliens

[Antoine Pitrou]

On Wed, 18 Jan 2023 12:04:41 +0200
Ville Voutilainen via Std-Proposals 
wrote:
> On Wed, 18 Jan 2023 at 11:45, Frederick Virchanza Gotham via
> Std-Proposals  wrote:
> >
> > I have sent this email to two mailing lists for programming language
> > proposals, the one for C++ and the one for Python. If you reply to
> > this email, please make sure you reply to both. You can see the
> > mailing list archives for this month for each list here:
> >
> > C++  :  https://lists.isocpp.org/std-proposals/2023/01/date.php
> > Python  :  
> > https://mail.python.org/archives/list/python-dev@python.org/2023/1/
> >
> > Both C++ and Python have exception handling, however a C++ program
> > which links with a Python library is unable to handle an exception
> > thrown from Python.  
> 
> Perhaps you should just use
> https://www.boost.org/doc/libs/1_81_0/libs/python/doc/html/index.html

I would suggest taking a look at pybind11 for a potentially more modern
design (also, free of boost dependencies).
https://pybind11.readthedocs.io/en/latest/advanced/exceptions.html

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/WGSJJBQA4DK2NK2LQCNLTQZIKML5XVX7/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [std-proposals] Exception compatibility with aliens

[Josh Engroff]

Table this, perhaps? 


> On Jan 18, 2023, at 5:04 PM, Barry Scott  wrote:
> 
> 
> 
>> On 18 Jan 2023, at 15:35, Frederick Virchanza Gotham 
>>  wrote:
>> 
>>> On Wed, Jan 18, 2023 at 3:07 PM Jason McKesson wrote:
>>> 
>>> Also, this proposal seems to be missing the biggest issue with
>>> cross-language exception handling: the fact that you can't throw
>>> exceptions across languages. The only thing you *can* do is catch
>>> exceptions on the source language end, convert them into some data
>>> packet, and throw a different exception on the destination language
>>> side.
>> 
>> 
>> Yes this is what I had in mind. Behind the scenes, the C++ compiler
>> would catch the Python exception and then throw something that C++ can
>> deal with "such as std::aliens::python::exception".
> 
> In PyCXX I allows exceptions to go into and out of python and C++.
> https://cxx.sourceforge.net/
> 
> You can raise in C++ go into python and back into C++ and the exception 
> arrives as expected.
> You can riase in Python fo into C++ and back to Python and again the 
> exception arrives as expected.
>  That is as long as its a python exception.
> 
> Barry
> 
>> ___
>> 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/5OARJXOXYFXHTO2OBHUGFVFSQHOVPVPO/
>> 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/NFUSVJB2N6FZVU23L2IVSCG3SN6DMINO/
> 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/7JQHGK6F2FI526XG7J77NPGOUC3LUWZ3/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [std-proposals] Exception compatibility with aliens

[Barry Scott]

> On 18 Jan 2023, at 15:35, Frederick Virchanza Gotham 
>  wrote:
> 
> On Wed, Jan 18, 2023 at 3:07 PM Jason McKesson wrote:
>> 
>> Also, this proposal seems to be missing the biggest issue with
>> cross-language exception handling: the fact that you can't throw
>> exceptions across languages. The only thing you *can* do is catch
>> exceptions on the source language end, convert them into some data
>> packet, and throw a different exception on the destination language
>> side.
> 
> 
> Yes this is what I had in mind. Behind the scenes, the C++ compiler
> would catch the Python exception and then throw something that C++ can
> deal with "such as std::aliens::python::exception".

In PyCXX I allows exceptions to go into and out of python and C++.
https://cxx.sourceforge.net/

You can raise in C++ go into python and back into C++ and the exception arrives 
as expected.
You can riase in Python fo into C++ and back to Python and again the exception 
arrives as expected.
 That is as long as its a python exception.

Barry

> ___
> 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/5OARJXOXYFXHTO2OBHUGFVFSQHOVPVPO/
> 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/NFUSVJB2N6FZVU23L2IVSCG3SN6DMINO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [std-proposals] Exception compatibility with aliens

[Frederick Virchanza Gotham]

On Wed, Jan 18, 2023 at 3:07 PM Jason McKesson wrote:
>
> Also, this proposal seems to be missing the biggest issue with
> cross-language exception handling: the fact that you can't throw
> exceptions across languages. The only thing you *can* do is catch
> exceptions on the source language end, convert them into some data
> packet, and throw a different exception on the destination language
> side.


Yes this is what I had in mind. Behind the scenes, the C++ compiler
would catch the Python exception and then throw something that C++ can
deal with "such as std::aliens::python::exception".
___
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/5OARJXOXYFXHTO2OBHUGFVFSQHOVPVPO/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: [std-proposals] Exception compatibility with aliens

[Ville Voutilainen]

On Wed, 18 Jan 2023 at 11:45, Frederick Virchanza Gotham via
Std-Proposals  wrote:
>
> I have sent this email to two mailing lists for programming language
> proposals, the one for C++ and the one for Python. If you reply to
> this email, please make sure you reply to both. You can see the
> mailing list archives for this month for each list here:
>
> C++  :  https://lists.isocpp.org/std-proposals/2023/01/date.php
> Python  :  https://mail.python.org/archives/list/python-dev@python.org/2023/1/
>
> Both C++ and Python have exception handling, however a C++ program
> which links with a Python library is unable to handle an exception
> thrown from Python.

Perhaps you should just use
https://www.boost.org/doc/libs/1_81_0/libs/python/doc/html/index.html

See also https://realpython.com/python-bindings-overview/

In both C++ and Python, exceptions can contain anything as their
payload. The problem becomes a problem of
mapping one language to the other, not just mapping exceptions. That
makes it a general cross-language binding generation problem,
so the forthcoming reflection/injection in C++ can certainly help, but
just having a 'list' of exceptions isn't going to
cut it either way.
___
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/XWENS3AO6PYAHGQL6S64NDXUT45PMEYP/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Exception compatibility with aliens

[Frederick Virchanza Gotham]

I have sent this email to two mailing lists for programming language
proposals, the one for C++ and the one for Python. If you reply to
this email, please make sure you reply to both. You can see the
mailing list archives for this month for each list here:

C++  :  https://lists.isocpp.org/std-proposals/2023/01/date.php
Python  :  https://mail.python.org/archives/list/python-dev@python.org/2023/1/

Both C++ and Python have exception handling, however a C++ program
which links with a Python library is unable to handle an exception
thrown from Python.

Is it conceivable in the future that the C++ Standards Committee and
the Python Steering Council could cooperate and furnish each other
with an exhaustive list of exceptions thrown from their respective
standard libraries, so that both languages can implement compatibility
with each other's exceptions?

If such a list were to accompany each C++ standard and each Python
Language Reference, then for example the C++ standard library could
provide classes for handling Python exceptions:

namespace std {

struct alien_exception /* does not inherit from std::exception */ {
enum class language : unsigned int { java=1u, csharp, python };
virtual language lang(void) const noexcept = 0;
virtual char const *what(void) const noexcept = 0;
};

namespace aliens {

  namespace java {
struct exception : alien_exception {
char const *getLocalizedMessage(void) const noexcept;
char const *getMessage(void) const noexcept;
std::stacktrace getStackTrace(void) const noexcept;
char const *what(void) const noexcept override { return
this->getMessage(); }
language lang(void) const noexcept override { return language::java; }
};
  }

  namespace python {
struct exception : alien_exception {
char const *const *notes(void) const noexcept; /* null terminated */
std::stacktrace traceback() const noexcept;
char const *what(void) const noexcept override { return
this->notes()[0u]; }
language lang(void) const noexcept override { return language::python; }
};
  }

  namespace python {
 struct BaseException : exception {};
   struct BaseExceptionGroup : BaseException {};
   struct GeneratorExit : BaseException {};
   struct KeyboardInterrupt : BaseException {};
   struct SystemExit : BaseException {};
   struct Exception : BaseException {};
struct ArithmeticError : Exception {};
  struct FloatingPointError : ArithmeticError {};
  struct OverflowError : ArithmeticError {};
  struct ZeroDivisionError : ArithmeticError {};
struct AssertionError : Exception {};
struct AttributeError : Exception {};
struct BufferError : Exception {};
struct EOFError : Exception {};
struct ExceptionGroupBaseExceptionGroup : Exception {};
struct ImportError : Exception {};
  struct ModuleNotFoundError : ImportError {};
struct LookupError : Exception {};
  struct IndexError : LookupError {};
  struct KeyError : LookupError {};
struct MemoryError : Exception {};
struct NameError : Exception {};
  struct UnboundLocalError : NameError {};
struct OSError : Exception {};
  struct BlockingIOError : OSError {};
  struct ChildProcessError : OSError {};
  struct ConnectionError : OSError {};
struct BrokenPipeError : ConnectionError {};
struct ConnectionAbortedError : ConnectionError {};
struct ConnectionRefusedError : ConnectionError {};
struct ConnectionResetError : ConnectionError {};
  struct FileExistsError : OSError {};
  struct FileNotFoundError : OSError {};
  struct InterruptedError : OSError {};
  struct IsADirectoryError : OSError {};
  struct NotADirectoryError : OSError {};
  struct PermissionError : OSError {};
  struct ProcessLookupError : OSError {};
  struct TimeoutError : OSError {};
struct ReferenceError : Exception {};
struct RuntimeError : Exception {};
  struct NotImplementedError : RuntimeError {};
  struct RecursionError : RuntimeError {};
struct StopAsyncIteration : Exception {};
struct StopIteration : Exception {};
struct SyntaxError : Exception {};
  struct IndentationError : SyntaxError {};
 struct TabError : IndentationError {};
struct SystemError : Exception {};
struct TypeError : Exception {};
struct ValueError : Exception {};
  struct UnicodeError : ValueError {};
 struct UnicodeDecodeError : UnicodeError {};
 struct UnicodeEncodeError : UnicodeError {};
 struct UnicodeTranslateError : UnicodeError {};
struct Warning : Exception {};
   struct BytesWarning : Warning {};
   struct DeprecationWarning : Warning {};
   struct 

[Python-Dev] Re: C- Python on Windows

[Steve Dower]

On 15Jan2023 0922, Guenther Sohler wrote:

Now when i want to get my project compiled in windows, whats the easiest
development chain ?
Is there something like a python.dll which i can link to my project and
having an embedded python interpreter ?

Maybe the question is too simple, but i could not yet find the right place
to read docs.
Thank you for your hints!


There's an overview of our embeddable package and some discussion of how 
to use it at https://docs.python.org/3/using/windows.html#windows-embeddable


You'll likely also need a full install to get all the developer kit 
pieces (such as the headers and libs files), but the embeddable package 
is one you can include straight into your project and redistribute. The 
binaries are the same, it's just laid out differently.


And yes, discuss.python.org is the best place to ask these days.

Cheers,
Steve
___
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/DHEON2LAXFWRH5NUYAOJSYVTDRH4EL4N/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] C- Python on Windows

[Stephen J. Turnbull]

Guenther Sohler writes:

Hi, Guenther!

 > I have successfully used C-Python (3) in a software project in unix and its
 > great stuff!
 > The environment was cmake using g++ in Linux

Congratulations!

 > Now when i want to get my project compiled in windows, whats the easiest
 > development chain ?

That depends.  One option is one of the environments (MSYS or Cygwin)
based on the GNU compiler chain.  There is a python DLL supplied in
the Windows environment.  Mingwin (+ MSYS?) should work with that, I'm
not sure if Cygwin does.  Cygwin is more Unix-like, Mingwin is just a
GNU compiler chain for Windows.  The other is the standard (and I
believe free) Visual C compiler from Microsoft.

Try https://docs.python.org/3/ for the docs you want: "Extending and
Embedding" and "Python/C API".

By the way, this isn't the appropriate place for this question.  This
list is for development discussion of Python itself, and in fact is
very close to being phased out in favor of forums on discuss.python.org.

For further discussion, you probably want the "python-l...@python.org"
mailing list, or the "python help" "discuss" channel for "development
*with* Python" questions.

___
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/WWLI6KODY6PSVANNXI3V4JK7DUQ5U7GD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] C- Python on Windows

[Guenther Sohler]

Hi Group,

I have successfully used C-Python (3) in a software project in unix and its
great stuff!
The environment was cmake using g++ in Linux

Now when i want to get my project compiled in windows, whats the easiest
development chain ?
Is there something like a python.dll which i can link to my project and
having an embedded python interpreter ?

Maybe the question is too simple, but i could not yet find the right place
to read docs.
Thank you for your hints!
___
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/MBF2OU5JTKK6PO63OKZ353EJX5VDGNTL/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Python 3.12.0 alpha 4 released

[Thomas Wouters]

I'm pleased to announce the release of Python 3.12 alpha 4.

https://www.python.org/downloads/release/python-3120a4/

*This is an early developer preview of Python 3.12*.

Major new features of the 3.12 series, compared to 3.11

Python 3.12 is still in development. This release, 3.12.0a4 is the fourth
of seven planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2023-05-08) and, if necessary, may be modified or deleted up
until the release candidate phase (2023-07-31). Please keep in mind that
this is a preview release and its use is *not *recommended for production
environments.

Many new features for Python 3.12 are still being planned and written.
Among the new major new features and changes so far:

   - Even more improved error messages. More exceptions potentially caused
   by typos now make suggestions to the user.
   - Support for the Linux perf profiler to report Python function names in
   traces.
   - The deprecated wstr and wstr_length members of the C implementation of
   unicode objects were removed, per PEP 623
   .
   - In the unittest module, a number of long deprecated methods and
   classes were removed. (They had been deprecated since Python 3.1 or 3.2).
   - The deprecated smtpd and distutils modules have been removed (see PEP
   594  and PEP 632
   ). The setuptools package (installed
   by default in virtualenvs and many other places) continues to provide the
   distutils module.
   - A number of other old, broken and deprecated functions, classes and
   methods have been removed.
   - (Hey,* fellow core developer*, if a feature you find important is
   missing from this list, let Thomas know .)


For more details on the changes to Python 3.12, see What's new in Python
3.12 . The next pre-release
of Python 3.12 will be 3.12.0a5, currently scheduled for 2023-02-06.

More resources

Online Documentation .
PEP 693 , the Python 3.12
Release Schedule.
Report bugs via GitHub Issues .
Help fund Python and its community .

And now for something completely different

Two haikus apt, as Python's development springs ever forward.

I write, erase, rewrite
> Erase again, and then
> A poppy blooms.


Haiku by Katsushika Hokusai.

O snail
> Climb Mount Fuji,
> But slowly, slowly!


Haiku by Kobayashi Issa.

Enjoy the new releases

Thanks to all of the many volunteers who help make Python Development and
these releases possible! Please consider supporting our efforts by
volunteering yourself or through organization contributions to the Python
Software Foundation.

Regards from chilly Amsterdam,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower
-- 
Thomas Wouters 
___
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/XSZGHTDDU3R2NW2HUU64HHPHWI3ISHMD/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Fwd: Python 3.11 performance with frame pointers

[Gregory P. Smith]

I suggest re-posting this on discuss.python.org as more engaged active core
devs will pay attention to it there.

On Wed, Jan 4, 2023 at 11:12 AM Daan De Meyer 
wrote:

> Hi,
>
> As part of the proposal to enable frame pointers by default in Fedora
> (https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer), we
> did some benchmarking to figure out the expected performance impact.
> The performance impact was generally minimal, except for the
> pyperformance benchmark suite where we noticed a more substantial
> difference between a system built with frame pointers and a system
> built without frame pointers. The results can be found here:
> https://github.com/DaanDeMeyer/fpbench (look at the mean difference
> column for the pyperformance results where the percentage is the
> slowdown compared to a system built without frame pointers). One of
> the biggest slowdowns was on the scimark_sparse_mat_mult benchmark
> which slowed down 9.5% when the system (including python) was built
> with frame pointers. Note that these benchmarks were run against
> Python 3.11 on a Fedora 37 x86_64 system (one built with frame
> pointers, another built without frame pointers). The system used to
> run the benchmarks was an Amazon EC2 machine.
>
> We did look a bit into the reasons behind this slowdown. I'll quote
> the investigation by Andrii on the Fesco issue thread here
> (https://pagure.io/fesco/issue/2817):
>
> > So I did look a bit at Python with and without frame pointers trying to
> > understand pyperformance > regressions.
>
> > First, perf data suggests that big chunk of CPU is spent in
> _PyEval_EvalFrameDefault,
> > so I looked specifically  into it (also we had to use DWARF mode for
> perf for apples-to-apples
> > comparison, and a bunch of stack traces weren't symbolized properly,
> which just again
> > reminds why having frame pointers is important).
>
> > perf annotation of _PyEval_EvalFrameDefault didn't show any obvious hot
> spots, the work
> > seemed to be distributed pretty similarly with or without frame
> pointers. Also scrolling through
> > _PyEval_EvalFrameDefault disassembly also showed that instruction
> patterns between fp
> > and no-fp versions are very similar.
>
> > But just a few interesting observations.
>
> > The size of _PyEval_EvalFrameDefault function specifically (and all the
> other functions didn't
> > change much in that regard) increased very significantly from 46104 to
> 53592 bytes, which is a
> > considerable 15% increase. Looking deeper, I believe it's all due to
> more stack spills and
> > reloads due to one less register available to keep local variables in
> registers instead of on the stack.
>
> > Looking at _PyEval_EvalFrameDefault C code, it is a humongous one
> function with gigantic switch
> > statement that implements Python instruction handling logic. So the
> function itself is big and it has
> > a lot of local state in different branches, which to me explained why
> there is so much stack spill/load.
>
> > Grepping for instruction of the form mov -0xf0(%rbp),%rcx or mov
> 0x50(%rsp),%r10 (and their reverse
> > variants), I see that there is a substantial amount of stack spill/load
> in _PyEval_EvalFrameDefault
> > disassembly already in default no frame pointer variant (1870 out of
> 11181 total instructions in that
> > function, 16.7%), and it just increases further in frame pointer version
> (2341 out of 11733 instructions, 20%).
>
> > One more interesting observation. With no frame pointers, GCC generates
> stack accesses using %rsp
> > with small positive offsets, which results in pretty compact binary
> instruction representation, e.g.:
>
> > 0x001cce40 <+44160>: 4c 8b 54 24 50  mov
> 0x50(%rsp),%r10
>
> > This uses 5 bytes. But if frame pointers are enabled, GCC switches to
> using %rbp-relative offsets,
> > which are all negative. And that seems to result in much bigger
> instructions, taking now 7 bytes instead of 5:
>
> > 0x001d3969 <+53065>: 48 8b 8d 10 ff ff ffmov
> -0xf0(%rbp),%rcx
>
> > I found it pretty interesting. I'd imagine GCC should be capable to keep
> using %rsp addressing just fine
> > regardless of %rbp and save on instruction sizes, but apparently it
> doesn't. Not sure why. But this instruction
> > increase, coupled with increase of number of spills/reloads, actually
> explains huge increase in byte size of
> > _PyEval_EvalFrameDefault: (2341 - 1870) * 7 + 1870 * 2 = 7037 (2 extra
> bytes for existing 1870 instructions
> > that were switched from %rsp+positive offset to %rbp + negative offset,
> plus 7 bytes for each of new 471 instructions).
> > I'm no compiler expert, but it would be nice for someone from GCC
> community to check this as well (please CC
> > relevant folks, if you know them).
>
> > In summary, to put it bluntly, there is just more work to do for CPU
> saving/restoring state to/from stack. But I don't
> > think _PyEval_EvalFrameDefault example is typical of how application
> code is written, 

[Python-Dev] Fwd: Python 3.11 performance with frame pointers

[Daan De Meyer]

Hi,

As part of the proposal to enable frame pointers by default in Fedora
(https://fedoraproject.org/wiki/Changes/fno-omit-frame-pointer), we
did some benchmarking to figure out the expected performance impact.
The performance impact was generally minimal, except for the
pyperformance benchmark suite where we noticed a more substantial
difference between a system built with frame pointers and a system
built without frame pointers. The results can be found here:
https://github.com/DaanDeMeyer/fpbench (look at the mean difference
column for the pyperformance results where the percentage is the
slowdown compared to a system built without frame pointers). One of
the biggest slowdowns was on the scimark_sparse_mat_mult benchmark
which slowed down 9.5% when the system (including python) was built
with frame pointers. Note that these benchmarks were run against
Python 3.11 on a Fedora 37 x86_64 system (one built with frame
pointers, another built without frame pointers). The system used to
run the benchmarks was an Amazon EC2 machine.

We did look a bit into the reasons behind this slowdown. I'll quote
the investigation by Andrii on the Fesco issue thread here
(https://pagure.io/fesco/issue/2817):

> So I did look a bit at Python with and without frame pointers trying to
> understand pyperformance > regressions.

> First, perf data suggests that big chunk of CPU is spent in 
> _PyEval_EvalFrameDefault,
> so I looked specifically  into it (also we had to use DWARF mode for perf for 
> apples-to-apples
> comparison, and a bunch of stack traces weren't symbolized properly, which 
> just again
> reminds why having frame pointers is important).

> perf annotation of _PyEval_EvalFrameDefault didn't show any obvious hot 
> spots, the work
> seemed to be distributed pretty similarly with or without frame pointers. 
> Also scrolling through
> _PyEval_EvalFrameDefault disassembly also showed that instruction patterns 
> between fp
> and no-fp versions are very similar.

> But just a few interesting observations.

> The size of _PyEval_EvalFrameDefault function specifically (and all the other 
> functions didn't
> change much in that regard) increased very significantly from 46104 to 53592 
> bytes, which is a
> considerable 15% increase. Looking deeper, I believe it's all due to more 
> stack spills and
> reloads due to one less register available to keep local variables in 
> registers instead of on the stack.

> Looking at _PyEval_EvalFrameDefault C code, it is a humongous one function 
> with gigantic switch
> statement that implements Python instruction handling logic. So the function 
> itself is big and it has
> a lot of local state in different branches, which to me explained why there 
> is so much stack spill/load.

> Grepping for instruction of the form mov -0xf0(%rbp),%rcx or mov 
> 0x50(%rsp),%r10 (and their reverse
> variants), I see that there is a substantial amount of stack spill/load in 
> _PyEval_EvalFrameDefault
> disassembly already in default no frame pointer variant (1870 out of 11181 
> total instructions in that
> function, 16.7%), and it just increases further in frame pointer version 
> (2341 out of 11733 instructions, 20%).

> One more interesting observation. With no frame pointers, GCC generates stack 
> accesses using %rsp
> with small positive offsets, which results in pretty compact binary 
> instruction representation, e.g.:

> 0x001cce40 <+44160>: 4c 8b 54 24 50  mov0x50(%rsp),%r10

> This uses 5 bytes. But if frame pointers are enabled, GCC switches to using 
> %rbp-relative offsets,
> which are all negative. And that seems to result in much bigger instructions, 
> taking now 7 bytes instead of 5:

> 0x001d3969 <+53065>: 48 8b 8d 10 ff ff ffmov-0xf0(%rbp),%rcx

> I found it pretty interesting. I'd imagine GCC should be capable to keep 
> using %rsp addressing just fine
> regardless of %rbp and save on instruction sizes, but apparently it doesn't. 
> Not sure why. But this instruction
> increase, coupled with increase of number of spills/reloads, actually 
> explains huge increase in byte size of
> _PyEval_EvalFrameDefault: (2341 - 1870) * 7 + 1870 * 2 = 7037 (2 extra bytes 
> for existing 1870 instructions
> that were switched from %rsp+positive offset to %rbp + negative offset, plus 
> 7 bytes for each of new 471 instructions).
> I'm no compiler expert, but it would be nice for someone from GCC community 
> to check this as well (please CC
> relevant folks, if you know them).

> In summary, to put it bluntly, there is just more work to do for CPU 
> saving/restoring state to/from stack. But I don't
> think _PyEval_EvalFrameDefault example is typical of how application code is 
> written, nor is it, generally speaking,
> a good idea to do so much within single gigantic function. So I believe it's 
> more of an outlier than a typical case.

We have a few questions:
- Is this slowdown when Python is built with frame pointers to be
expected? Has the 

[Python-Dev] Re: PEP 701 – Syntactic formalization of f-strings

[Rob Cliffe via Python-Dev]

Great stuff! 
Rob Cliffe

On 19/12/2022 17:59, Pablo Galindo Salgado wrote:


Hi everyone,

I am very excited to share with you a PEP thatBatuhan Taskaya, 
Lysandros Nikolaou and myself have been working on recently:PEP 701 - 
PEP 701 – Syntactic formalization of f-strings 
.


We believe this will be a great improvement in both the 
maintainability of CPython and the usability of f-strings.


We look forward to hearing what you think about this and to get your 
feedback!


*Here is a TLDR for your convenience:*

  * The PEP proposes a formalized grammar for f-strings in Python by
adding f-strings directly into the Grammar instead of using a
two-pass hand-written parser.
  * This would lift some existing restrictions for f-strings that (we
believe) will improve the user experience with f-strings.
  * Other benefits include:
  o Reduced maintenance costs for f-string parsing code as well as
improved usability for users and library developers.
  o Better error messages involving f-strings by leveraging the
PEG parser machinery.
  o The proposed changes would improve the overall consistency of
the language and provide a way for alternative implementations
to accurately implement f-strings.

*** IMPORTANT: direct all discussions to the discussion thread on 
discourse: 
https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046 
***


Thanks a lot, everyone for your time!

Regards from rainy London,
Pablo Galindo Salgado

___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived 
athttps://mail.python.org/archives/list/python-dev@python.org/message/IU4O3GFGWJ4FWXXC2TVB4CNPZI3KFBQM/
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/S2S2OQNDDSYCC23LBINQZZUCNVYOAEAC/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: Feature Request: Adding Way to Annotate Class Variables Distinct from Instance Variables

[Chihiro Sakai]

OK, I missed out on typing-...@python.org, and now I know this thread is 
off-topic on python-dev@python.org.

A bit more clear example of what I want to do is:

```
class Field:
  def __init__(self, desc: str) -> None:
self.desc = desc


class FooMetaType:
  variable_both_class_and_instance: Field

  def __call__(self, value: int) -> 'Foo':
...


class Foo:
  variable_both_class_and_instance: int

  def __init__(self, value: int) -> None:
self.variable_both_class_and_instance = value

Foo: FooMetaType
Foo.variable_both_class_and_instance = Field(desc="descriptive string")

instance = Foo(5)

print(instance.variable_both_class_and_instance)
```

Static typing on this example doesn't work correctly as expected because it 
does not allow overwriting another type over a class declaration.

My point on the example is the tangible value should be assigned to the 
instance variables. Still, on the other hand, I want to give a value denoting 
the variable's metadata to the class variable. From my understanding, these 
variables, like this `variable_both_class_and_instance` in the example, cannot 
be correctly typed.

Thank you for your kindness, I'll repost it to typing-...@python.org.
___
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/IDV7E26G4SDUNEGCMFAAMXLO52YQNOPE/
Code of Conduct: http://python.org/psf/codeofconduct/

[Python-Dev] Re: PEP 701 – Syntactic formalization of f-strings

[Pablo Galindo Salgado]

Hi everyone,

For those that are not following the discussion in the discourse thread, I
am holding a poll to get an idea of the community opinions on how quotes
should work in nested f-strings for PEP 701:

https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046/24

For us is very important to have everyone represented and every opinion
heard and taken into consideration so feel free to vote in the poll leaving
your opinion. But please, **read first the PEP and the previous
discussion**. This is very important to get the context and previous
arguments in favour and against the different options.

Thanks a lot for your help!

Regards from cloudy London,
Pablo Galindo Salgado

On Mon, 19 Dec 2022 at 17:59, Pablo Galindo Salgado 
wrote:

> Hi everyone,
>
> I am very excited to share with you a PEP that Batuhan Taskaya, Lysandros
> Nikolaou and myself have been working on recently: PEP 701 - PEP 701 –
> Syntactic formalization of f-strings .
>
> We believe this will be a great improvement in both the maintainability of
> CPython and the usability of f-strings.
>
> We look forward to hearing what you think about this and to get your
> feedback!
>
> *Here is a TLDR for your convenience:*
>
>- The PEP proposes a formalized grammar for f-strings in Python by
>adding f-strings directly into the Grammar instead of using a two-pass
>hand-written parser.
>- This would lift some existing restrictions for f-strings that (we
>believe) will improve the user experience with f-strings.
>- Other benefits include:
>   - Reduced maintenance costs for f-string parsing code as well as
>   improved usability for users and library developers.
>   - Better error messages involving f-strings by leveraging the PEG
>   parser machinery.
>   - The proposed changes would improve the overall consistency of the
>   language and provide a way for alternative implementations to accurately
>   implement f-strings.
>
> *** IMPORTANT: direct all discussions to the discussion thread on
> discourse: 
> https://discuss.python.org/t/pep-701-syntactic-formalization-of-f-strings/22046
> 
> ***
>
> Thanks a lot, everyone for your time!
> 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/Q22YQBHTVRUFKRMAETL3CDR7JN3YRJAG/
Code of Conduct: http://python.org/psf/codeofconduct/