[Python-Dev] Python 3.10 release party

Hi, As it seems that I didn't have enough work dealing with the multiple release blockers that have been raised these weeks I am also preparing a Python 3.10 release party. We will be doing an stream, co-hosted by the good people of Python discord channel. The URL for the stream is this one:

[Python-Dev] PEP: Taking the Python C API to the Next Level

Hi, I would like to change the Python C API. I failed to write a single document listing all constraints and proposing all changes that I would to do. For example, my previous PEP 620 contains too many changes and is too long. Here is my attempt to focus on the bare minimum and (what I consider

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 2021-09-28 at 10:22 +0200, Marc-Andre Lemburg wrote: > On 27.09.2021 18:51, Eric Snow wrote: > > We've frozen most of the stdlib modules imported during "python -c > > pass" [1][2], to make startup a bit faster.  Import of those modules > > is controlled by "-X frozen_modules=[on|off]". 

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sept 2021 at 15:33, Eric Snow wrote: > > It means that the site module module can no longer be "customized" by > > modifying directly the site.py file (inject a path in PYTHONPATH env > > var where the customized site.py lives). But there is already a > > supported way to customize

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 6:55 AM Eric V. Smith wrote: > As a compromise, how about go with #1, but print a warning if python > detects that it's not built with optimizations or is run from a source > tree (the conditions in #2 and #3)? The warning could suggest running > with "-X

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 6:47 AM Pablo Galindo Salgado wrote: > One interesting consequence of what Eric mentioned (They have a different > loader and repr. Also, frozen modules do not > have __file__ set (and __path__ is always []).) is that frozen modules don't > have a `__file__` attribute

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 6:36 AM Victor Stinner wrote: > Honestly, for me, #1: always on, is the most reasonable choice. > > I dislike when Python behaves differently depending on subtle things > like "was it built with optimizations" or "is Python started from its > source tree"? > > When I built

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 2:22 AM Marc-Andre Lemburg wrote: > #3 sounds like a good solution, but how would you detect "running > from the source tree" ? This sounds like you need another stat call > somewhere, which is what the frozen modules try to avoid. We already look for the stdlib dir in

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 6:02 AM Ronald Oussoren via Python-Dev wrote: > Of course. I mentioned it because the proposal is to add a new option that’s > enabled after installation, and basically not when the testsuite is run. > That’s not a problem, we could just enable the option in most CI

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, Sep 28, 2021 at 2:54 AM Ronald Oussoren via Python-Dev wrote: > I agree, but… Most CPython tests are run while running from the source tree, > that means that there will have to be testrunner configurations that run with > “-X frozen_modules=on”. If the build option that determines the

[Python-Dev] Re: The Default for python -X frozen_modules.

The Python Debug Build document lists changes compared to a release build: https://docs.python.org/dev/using/configure.html#python-debug-build Sometimes, I'm confused that "./python" (Python built locally in debug mode) displays warnings, whereas "python" (Fedora package) doesn't. See also the

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/28/2021 9:17 AM, Antoine Pitrou wrote: On Tue, 28 Sep 2021 09:14:38 -0400 "Eric V. Smith" wrote: On 9/28/2021 9:10 AM, Antoine Pitrou wrote: On Tue, 28 Sep 2021 08:55:05 -0400 "Eric V. Smith" wrote: So I prefer to teach everybody how to use "-X frozen_modules=off" if they want to hack

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sep 2021 09:14:38 -0400 "Eric V. Smith" wrote: > On 9/28/2021 9:10 AM, Antoine Pitrou wrote: > > On Tue, 28 Sep 2021 08:55:05 -0400 > > "Eric V. Smith" wrote: > >>> So I prefer to teach everybody how to use "-X frozen_modules=off" if > >>> they want to hack the stdlib for their

[Python-Dev] Re: The Default for python -X frozen_modules.

On 28.09.2021 14:26, Filipe Laíns wrote: > On Tue, 2021-09-28 at 10:22 +0200, Marc-Andre Lemburg wrote: >> On 27.09.2021 18:51, Eric Snow wrote: >>> We've frozen most of the stdlib modules imported during "python -c >>> pass" [1][2], to make startup a bit faster.  Import of those modules >>> is

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/28/2021 9:10 AM, Antoine Pitrou wrote: On Tue, 28 Sep 2021 08:55:05 -0400 "Eric V. Smith" wrote: So I prefer to teach everybody how to use "-X frozen_modules=off" if they want to hack the stdlib for their greatest pleasure. I prefer that such special use case requires an opt-in option,

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sep 2021 08:55:05 -0400 "Eric V. Smith" wrote: > > > > So I prefer to teach everybody how to use "-X frozen_modules=off" if > > they want to hack the stdlib for their greatest pleasure. I prefer > > that such special use case requires an opt-in option, the special use > > case is not

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/28/2021 8:36 AM, Victor Stinner wrote: On Mon, Sep 27, 2021 at 6:58 PM Eric Snow wrote: We've frozen most of the stdlib modules imported during "python -c pass" [1][2], to make startup a bit faster. Import of those modules is controlled by "-X frozen_modules=[on|off]". Currently it

[Python-Dev] Re: The Default for python -X frozen_modules.

Would it be possible to add a __file__ attribute? Victor On Tue, Sep 28, 2021 at 2:47 PM Pablo Galindo Salgado wrote: > > > What is the annoyance? What is different between frozen and not frozen? > > One interesting consequence of what Eric mentioned (They have a different > loader and repr.

[Python-Dev] Re: The Default for python -X frozen_modules.

> What is the annoyance? What is different between frozen and not frozen? One interesting consequence of what Eric mentioned (They have a different loader and repr. Also, frozen modules do not have __file__ set (and __path__ is always []).) is that frozen modules don't have a `__file__`

[Python-Dev] Re: The Default for python -X frozen_modules.

On Mon, Sep 27, 2021 at 6:58 PM Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default

[Python-Dev] Re: The Default for python -X frozen_modules.

> On 28 Sep 2021, at 10:54, Antoine Pitrou wrote: > > On Tue, 28 Sep 2021 10:51:53 +0200 > Ronald Oussoren via Python-Dev wrote: >>> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote: >>> >>> On Mon, 27 Sep 2021 10:51:43 -0600 >>> Eric Snow >> > wrote:

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On 27/09/2021 21:53, Brett Cannon wrote: On Sun, Sep 26, 2021 at 3:51 AM Phil Thompson via Python-Dev < python-dev@python.org> wrote: On 26/09/2021 05:21, Steven D'Aprano wrote: [snip] > These are not rhetorical questions, I genuinely do not know. I *think* > that there was an attempt to

[Python-Dev] Re: The Default for python -X frozen_modules.

> On 28 Sep 2021, at 10:05, Antoine Pitrou wrote: > > On Mon, 27 Sep 2021 10:51:43 -0600 > Eric Snow mailto:ericsnowcurren...@gmail.com>> > wrote: >> We've frozen most of the stdlib modules imported during "python -c >> pass" [1][2], to make startup a bit faster. Import of those modules >>

[Python-Dev] Re: The Default for python -X frozen_modules.

On Tue, 28 Sep 2021 10:51:53 +0200 Ronald Oussoren via Python-Dev wrote: > > On 28 Sep 2021, at 10:05, Antoine Pitrou wrote: > > > > On Mon, 27 Sep 2021 10:51:43 -0600 > > Eric Snow > > wrote: > >> We've frozen most of the stdlib modules imported during

[Python-Dev] Re: The Default for python -X frozen_modules.

On 27.09.2021 18:51, Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default to "on".

[Python-Dev] Re: The Default for python -X frozen_modules.

On 28.09.2021 10:22, Marc-Andre Lemburg wrote: > On 27.09.2021 18:51, Eric Snow wrote: >> We've frozen most of the stdlib modules imported during "python -c >> pass" [1][2], to make startup a bit faster. Import of those modules >> is controlled by "-X frozen_modules=[on|off]". Currently it

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On Tue, Sep 28, 2021 at 12:40 AM Guido van Rossum wrote: > > What I have heard repeatedly, from people who are paid to know, is that most > users don’t care about the latest features, and would rather stick to a > release until it becomes unsupported. (Extreme example: Python 2.) > > Numpy

[Python-Dev] Re: The Default for python -X frozen_modules.

On Mon, 27 Sep 2021 10:51:43 -0600 Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

What I have heard repeatedly, from people who are paid to know, is that most users don’t care about the latest features, and would rather stick to a release until it becomes unsupported. (Extreme example: Python 2.) Numpy isn’t random, it’s at the bottom of the food chain for a large ecosystem or

[Python-Dev] Re: Worried about Python release schedule and lack of stable C-API

On Sun, Sep 26, 2021 at 3:38 AM wrote: > Open3D is an example. Will finally move to Python 3.9 some time the coming > month. Its dependency graph contains about 70 other packages. > > In this specific case, the underlying problem was that TensorFlow was stuck > at 3.8. The TensorFlow codebase