[Python-Dev] [RELEASE] Python 3.7.8rc1 and 3.6.11rc1 are now available for testing

Details here: https://discuss.python.org/t/python-3-7-8rc1-and-3-6-11rc1-are-now-available-for-testing/4467 https://www.python.org/downloads/release/python-378rc1/ https://www.python.org/downloads/release/python-3611rc1/ -- Ned Deily n...@python.org -- []

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

On 6/17/2020 6:03 PM, Jeff Allen wrote: On 17/06/2020 19:28, Eric V. Smith wrote: On 6/17/2020 12:07 PM, Jeff Allen wrote: If (1) interpreters manage the life-cycle of objects, and (2) a race condition arises when the life-cycle or state of an object is accessed by the interpreter that did

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

On 17/06/2020 19:28, Eric V. Smith wrote: On 6/17/2020 12:07 PM, Jeff Allen wrote: If (1) interpreters manage the life-cycle of objects, and (2) a race condition arises when the life-cycle or state of an object is accessed by the interpreter that did not create it, and (3) an object will

[Python-Dev] Re: Improving inspect capabilities for classes

On 17/06/2020 17:25, Guido van Rossum wrote: I presume Jupyter also lets you import code from a file, which you edit outside, Jupyter? Is,that not an option for you? It's not the file that is the problem, but the lack of it. If I didn't want to cover classes within the __main__ module, I

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On Wed, Jun 17, 2020 at 11:42 AM Emily Bowman wrote: > So most likely there wouldn't be any way to share something like a bytearray > or another > buffer interface-compatible type for some time. That's too bad, I was hoping > to have > shared arrays that I could put a memoryview on in each

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

On 6/17/2020 12:07 PM, Jeff Allen wrote: On 12/06/2020 12:55, Eric V. Smith wrote: On 6/11/2020 6:59 AM, Mark Shannon wrote: Different interpreters need to operate in their own isolated address space, or there will be horrible race conditions. Regardless of whether that separation is done in

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On Wed, Jun 17, 2020 at 5:56 AM Nick Coghlan wrote: > > Doing full blown zero-copy ownership transfer of actual Python objects > would be more difficult, since the current plan is to have separate memory > allocation pools per interpreter to avoid excessive locking overhead, so I > don't

[Python-Dev] Re: Design and Architecture of python

Thanks Steve. That would definitely help. > On Jun 17, 2020, at 9:23 AM, Steve Dower wrote: > > If you're not willing to slog through the source code and many PEPs and past > discussions, Anthony Shaw has done it for you and written a book: >

[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 12:55, Eric V. Smith wrote: On 6/11/2020 6:59 AM, Mark Shannon wrote: Different interpreters need to operate in their own isolated address space, or there will be horrible race conditions. Regardless of whether that separation is done in software or hardware, it has to be done.

[Python-Dev] Re: Design and Architecture of python

If you're not willing to slog through the source code and many PEPs and past discussions, Anthony Shaw has done it for you and written a book: https://realpython.com/products/cpython-internals-book/ All the other write-ups I'm aware of are very dated, so I don't have any free suggestions I'm

[Python-Dev] Re: Improving inspect capabilities for classes

I presume Jupyter also lets you import code from a file, which you edit outside, Jupyter? Is,that not an option for you? On Wed, Jun 17, 2020 at 04:09 Thomas Viehmann wrote: > On 16/06/2020 20:02, Guido van Rossum wrote: > > Very few stars. This suggests not many people care about this problem,

[Python-Dev] Design and Architecture of python

I am well versed in Python and now trying to understand and learn the Design philosophy of Python as a Programming Language. Is there any document related to Design/Archoitecture of Python language itself where I can learn about implementation of garbage collection, top level of python objects

[Python-Dev] Re: Improving inspect capabilities for classes

On 16/06/2020 20:02, Guido van Rossum wrote: Very few stars. This suggests not many people care about this problem, and that in turn might explain the lukewarm response you find everywhere. This seems to be the core, and combined with the cost of measuring performance impacts of adding a new

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On Wed., 17 Jun. 2020, 4:28 am Mark Shannon, wrote: > > On 16/06/2020 1:24 pm, Nick Coghlan wrote: > > Multiprocessing serialisation overheads are abysmal. With enough OS > > support you can attempt to mitigate that via shared memory mechanisms > > (which Davin added to the standard library),

[Python-Dev] Re: Cython and incompatible C API changes

On Wed, 17 Jun 2020 at 12:27, Victor Stinner wrote: > > If PEP 387 (Backwards Compatibility Policy) is accepted, all the > > incompatible changes changes will require a two-year deprecation period. > > Right? > [...] > > So far, it doesn't seem to be a giant disaster :-) Only a few C >

[Python-Dev] Re: Cython and incompatible C API changes

Le mer. 17 juin 2020 à 12:38, Petr Viktorin a écrit : > > Py_TYPE(), Py_REFCNT() and Py_SIZE() can no longer be used as l-value. > > These changes also broke numpy. I helped to fix Cython and numpy (and > > they are already fixed). > > Those are not all the projects that were broken by the change

[Python-Dev] Re: Cython and incompatible C API changes

On 2020-06-17 12:03, Victor Stinner wrote: re: [Python-Dev] When can we remove wchar_t* cache from string? Le mar. 16 juin 2020 à 21:19, Steve Dower a écrit : On 16Jun2020 1641, Inada Naoki wrote: * This change doesn't affect to pure Python packages. * Most of the rest uses Cython. Since

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

On Mon, Jun 15, 2020 at 4:25 PM Serhiy Storchaka wrote: > > I have a plan for more graduate removing of this feature. I created a PR > which adds several compile options, so Python can be built in one of > three modes: > > 1. Support wchar_t* cache and use it. It is the current mode. > > 2.

[Python-Dev] Cython and incompatible C API changes

re: [Python-Dev] When can we remove wchar_t* cache from string? Le mar. 16 juin 2020 à 21:19, Steve Dower a écrit : > On 16Jun2020 1641, Inada Naoki wrote: > > * This change doesn't affect to pure Python packages. > > * Most of the rest uses Cython. Since I already report an issue to Cython, >

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 2020-06-16 20:28, Mark Shannon wrote: On 16/06/2020 1:24 pm, Nick Coghlan wrote: Multiprocessing serialisation overheads are abysmal. With enough OS support you can attempt to mitigate that via shared memory mechanisms (which Davin added to the standard library), but it's impossible to

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

Thank you Guido :-) Regards Antoine. On Tue, 16 Jun 2020 16:07:43 -0700 Guido van Rossum wrote: > After taking a break to recapitulate from the vigorous debate, Brandt > Bucher has revised PEP 618 and > submitted it for review

[Python-Dev] Re: Accepting PEP 618: zip(strict=True)

Well done Brandt! Even if only a few people had issues with zip(), I think that it was a long awaited feature. It's great to have it in Python 3.10! It wasn't trivial or convenient to emulate the feature (check manually the length) on Python 3.9 and older. zip(strict=True) should help to write

[Python-Dev] Re: Should we be making so many changes in pursuit of PEP 554?

On 2020-06-16 19:20, Guido van Rossum wrote: Has anybody brought up the problem yet that if one subinterpreter encounters a hard crash (say, it segfaults due to a bug in a C extension module), all subinterpreters active at that moment in the same process are likely to lose all their

[Python-Dev] Re: Improving inspect capabilities for classes

On 2020-06-17 09:02, Serhiy Storchaka wrote: 16.06.20 21:02, Guido van Rossum пише: It would certainly be much easier to get through the review process. Adding a `__filename__` (why not `__file__`?) attribute to classes is a major surgery, presumably requiring a PEP, and debating the pros and

[Python-Dev] Re: Improving inspect capabilities for classes

16.06.20 21:02, Guido van Rossum пише: It would certainly be much easier to get through the review process. Adding a `__filename__` (why not `__file__`?) attribute to classes is a major surgery, presumably requiring a PEP, and debating the pros and cons and performance implications and fixing