[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

On 13.06.2020 3:49, Łukasz Langa wrote: On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev mailto:python-dev@python.org>> wrote: I would doubt the quality of tags maintenance at Github, too. E.g.https://github.com/python/cpython/pull/12131is labeled 3.7 and 3.8 at BPO but has no backport

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

> On 12 Jun 2020, at 19:51, Ivan Pozdeev via Python-Dev > wrote: > > I would doubt the quality of tags maintenance at Github, too. E.g. > https://github.com/python/cpython/pull/12131 > is labeled 3.7 and 3.8 at BPO > but has no backport tags

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/12/2020 2:17 PM, Chris Angelico wrote: > On Sat, Jun 13, 2020 at 3:50 AM Edwin Zimmerman > wrote: >> My previous timings were slightly inaccurate, as they compared spawning >> processes on Windows to forking on Linux. Also, I changed my timing code to >> run all process synchronously, to

[Python-Dev] PEP 387: backwards compatibility policy

Started at a discussion at https://discuss.python.org/t/pep-387-backwards-compatibilty-policy/4421 to try to finally resolve this PEP and our backwards compatibility policy. ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an

[Python-Dev] Re: Are extension types allowed to implement both nb_add and sq_concat?

On Fri, Jun 12, 2020 at 12:56 PM Eric Wieser wrote: > > But how would you invoke them, other than using operator.add and > operator.concat? > > The case I was thinking of was just a direct call to `operator.concat`. > The motivation here is simply to make `operator.concat` do > something

[Python-Dev] Re: Are extension types allowed to implement both nb_add and sq_concat?

> But how would you invoke them, other than using operator.add and operator.concat? The case I was thinking of was just a direct call to `operator.concat`. The motivation here is simply to make `operator.concat` do something non-surprising on numpy arrays (be that `np.concatenate(a, b)`, or

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On Sat, Jun 13, 2020 at 3:50 AM Edwin Zimmerman wrote: > > My previous timings were slightly inaccurate, as they compared spawning > processes on Windows to forking on Linux. Also, I changed my timing code to > run all process synchronously, to avoid hitting resource limits. > > Updated

[Python-Dev] Summary of Python tracker Issues

ACTIVITY SUMMARY (2020-06-05 - 2020-06-12) Python tracker at https://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open7447 ( +3) closed 45258 (+78) total 52705 (+81) Open issues

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

On 12.06.2020 16:08, Ned Deily wrote: On Jun 12, 2020, at 08:25, Ivan Pozdeev via Python-Dev wrote: Why not take a look at the list of open issues for 3.7 with PRs then? There are 702 as of now.

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

My previous timings were slightly inaccurate, as they compared spawning processes on Windows to forking on Linux. Also, I changed my timing code to run all process synchronously, to avoid hitting resource limits. Updated Windows (Windows 7 this time, on a four core processor): >>>

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On Fri, Jun 12, 2020 at 7:19 AM Mark Shannon wrote: > Hi Edwin, > > Thanks for providing some concrete numbers. > Is it expected that creating 100 processes takes 6.3ms per process, but > that creating 1000 process takes 40ms per process? That's over 6 times > as long in the latter case. > >

[Python-Dev] Re: Are extension types allowed to implement both nb_add and sq_concat?

On Jun 12, 2020, at 04:21, Eric Wieser wrote: > It seems to me there are at least three stances that could be taken here: > > * Specifying both is considered invalid: python should consider emitting a > warning in `Type_READY` if both are filled. > * Specifying both is considered an

[Python-Dev] Re: When can we remove wchar_t* cache from string?

On 2020-06-12 09:32, Inada Naoki wrote: Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are

[Python-Dev] Re: Are extension types allowed to implement both nb_add and sq_concat?

But how would you invoke them, other than using operator.add and operator.concat? A better UI would be to define new methods with more discoverable names. On Fri, Jun 12, 2020 at 7:29 AM Eric Wieser wrote: > Hi all, > > In the `operator` module, both `operator.concat` and `operator.add` are >

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Eric, On 12/06/2020 4:17 pm, Eric Snow wrote: On Fri, Jun 12, 2020 at 2:49 AM Mark Shannon wrote: The overhead largely comes from what you do with the process. The additional cost of starting a new interpreter is the same regardless of whether it is in the same process or not. FWIW,

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On Fri, Jun 12, 2020 at 2:49 AM Mark Shannon wrote: > The overhead largely comes from what you do with the process. The > additional cost of starting a new interpreter is the same regardless of > whether it is in the same process or not. FWIW, there's more to it than that: * there is some

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Steve, On 12/06/2020 12:43 pm, Steve Dower wrote: On 12Jun2020 1008, Paul Moore wrote: On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: Starting a new process is cheap. On my machine, starting a new Python process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix?

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 12/06/2020 10:45, Mark Shannon wrote: On 11/06/2020 2:50 pm, Riccardo Ghetta wrote: On 11/06/2020 12:59, Mark Shannon wrote: If the additional resource consumption is irrelevant, what's the objection to spinning up a new processes? The additional resource consumption of a new python

[Python-Dev] Are extension types allowed to implement both nb_add and sq_concat?

Hi all, In the `operator` module, both `operator.concat` and `operator.add` are described as performing `a + b`. When defining a type in pure python, it is not possible to give these different meanings. However, when defining a C extension type, it is possible to fill both

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

Hi Edwin, Thanks for providing some concrete numbers. Is it expected that creating 100 processes takes 6.3ms per process, but that creating 1000 process takes 40ms per process? That's over 6 times as long in the latter case. Cheers, Mark. On 12/06/2020 11:29 am, Edwin Zimmerman wrote: On

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

On Jun 12, 2020, at 08:25, Ivan Pozdeev via Python-Dev wrote: > Why not take a look at the list of open issues for 3.7 with PRs then? There > are 702 as of now. > >

[Python-Dev] Re: Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

Why not take a look at the list of open issues for 3.7 with PRs then? There are 702 as of now. https://bugs.python.org/issue?%40sort0=creation&%40sort1=&%40group0=&%40group1=&%40columns=title%2Cid%2Cactivity%2Cstatus&%40filter=status%2Cversions%2Cstage=1=21=4&%40pagesize=50&%40startwith=0 On

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/11/2020 6:59 AM, Mark Shannon wrote: Hi Riccardo, On 10/06/2020 5:51 pm, Riccardo Ghetta wrote: Hi, as an user, the "lua use case" is right what I need at work. I realize that for python this is a niche case, and most users don't need any of this, but I hope it will useful to understand

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 12Jun2020 1008, Paul Moore wrote: On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: Starting a new process is cheap. On my machine, starting a new Python process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix? Traditionally, process creation has been costly on Windows,

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/12/2020 6:18 AM, Edwin Zimmerman wrote: > On 6/12/2020 5:08 AM, Paul Moore wrote: >> On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: >>> Starting a new process is cheap. On my machine, starting a new Python >>> process takes under 1ms and uses a few Mbytes. >> Is that on Windows or Unix?

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 6/12/2020 5:08 AM, Paul Moore wrote: > On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: >> Starting a new process is cheap. On my machine, starting a new Python >> process takes under 1ms and uses a few Mbytes. > Is that on Windows or Unix? Traditionally, process creation has been > costly on

[Python-Dev] Re: When can we remove wchar_t* cache from string?

Hi, A big +1 to exposing fewer internals of the PyUnicodeObject to C code. Ultimately, making PyUnicodeObject immutable to C code would be a real bonus. It would make the code cleaner, safer and faster. A triple win! I don't think removing Py_UNICODE API be sufficient for that, have you

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: > Starting a new process is cheap. On my machine, starting a new Python > process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix? Traditionally, process creation has been costly on Windows, which is why threads, and in-process

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 11/06/2020 2:50 pm, Riccardo Ghetta wrote: Hello Mark, and thanks for your suggestions. However, I'm afraid I haven't explained our use of python well enough. On 11/06/2020 12:59, Mark Shannon wrote: If you need to share objects across threads, then there will be contention, regardless

[Python-Dev] When can we remove wchar_t* cache from string?

Hi, all. Py_UNICODE has been deprecated since PEP 393 (Flexible string representation). wchar_t* cache in the string object is used only in deprecated APIs. It waste 1 word (8 bytes on 64bit machine) per string instance. The deprecated APIs are documented as "Deprecated since version 3.3, will

[Python-Dev] Final reminder: 3.7.8 / 3.6.11 cutoff Monday, last non-security bugfixes for 3.7.x

We will be accecpting commits to the 3.7 branch until this coming Monday 06-15 23:59 AOE. At that time, 3.7 will effectively enter security-fix mode. That will also be the deadline for any additional security-fixes for release in 3.6.11. Release candidates will follow shortly thereafter.