[Python-Dev] Re: REPL output bug

> On 16 Jun 2020, at 08:51, Greg Ewing wrote: > > On 16/06/20 12:20 pm, Steven D'Aprano wrote: >> The whole point of the REPL is to evaluate an >> expression and have the result printed. (That's the P in REPL :-) > > Still, it's a bit surprising that it prints results of > expressions within a

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

On Tue, Jun 16, 2020 at 12:35 AM Victor Stinner wrote: > > Hi INADA-san, > > IMO Python 3.11 is too early because we don't emit a > DeprecationWarning on every single deprecation function. > > 1) Emit a DeprecationWarning at runtime (ex: Python 3.10) > 2) Wait two Python releases: see > https://di

[Python-Dev] Re: REPL output bug

On 16.06.2020 1:40, Joseph Jenne via Python-Dev wrote: On 2020-06-15 15:26, Ivan Pozdeev via Python-Dev wrote: On 12.06.2020 11:01, Rob Cliffe via Python-Dev wrote: If I run the following program (using Python 3.8.3 on a Windows 10 laptop): import sys, time for i in range(1,11):     sys.stdo

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

On Mon, 15 Jun 2020 11:22:09 +0100 Mark Shannon wrote: > > I don't like this approach. > Adding compile time options means we need to test more versions, but is > no help to end users as they will end up with the release version anyway. I agree with Mark. This sounds less pointless complicatio

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

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 get the overhead of doing that as low as actually using the address space of one OS process.

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

Le mar. 16 juin 2020 à 10:42, Inada Naoki a écrit : > Hmm, Is there any chance to add DeprecationWarning in Python 3.9? In my experience, more and more projects are running their test suite with -Werror, which is a good thing. Introducing a new warning is likely to "break" many of these projects

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

On Sat., 13 Jun. 2020, 2:51 am Barry Warsaw, wrote: > 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 bo

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

Hello, thank you for your feedback! I could think of a trick that inspect.getsource() might use if the class contains at least one method: it could look at a method and try its `__code__.co_filename` attribute (maybe only if the `__file__` attribute for the module found via the class's `__module

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

On Tue, Jun 16, 2020 at 9:30 PM Victor Stinner wrote: > > Le mar. 16 juin 2020 à 10:42, Inada Naoki a écrit : > > Hmm, Is there any chance to add DeprecationWarning in Python 3.9? > > In my experience, more and more projects are running their test suite > with -Werror, which is a good thing. Int

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

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 outstanding work, without a chance of recovery? (Of course

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

That's so, but threads have this problem too.  I don't think this discussion is about finding a "perfect" solution or an "ultimate" way of doing things, rather it is about the varying opinions on certain design tradeoffs.  If I'm satisfied that subinterpreters are the correct solution to my pa

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

On Tue, Jun 16, 2020 at 2:00 AM Thomas Viehmann wrote: > Hello, > > thank you for your feedback! > > I could think of a trick that inspect.getsource() might use if the class > > contains at least one method: it could look at a method and try its > > `__code__.co_filename` attribute (maybe only if

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

On Tue, Jun 16, 2020 at 10:52 AM Edwin wrote: > > That's so, but threads have this problem too. I don't think this > discussion is about finding a "perfect" solution or an "ultimate" way of > doing things, rather it is about the varying opinions on certain design > tradeoffs. If I'm satisfied t

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

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 get the overhead of doing that as low as actu

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

Inada Naoki wrote: > On Tue, Jun 16, 2020 at 9:30 PM Victor Stinner vstin...@python.org wrote: > > > > Le mar. 16 juin 2020 à 10:42, Inada Naoki songofaca...@gmail.com a écrit : > > Hmm, Is there any chance to add > > DeprecationWarning in Python 3.9? > > In my experience, more and more projects a

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

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, regenerating with new Cython release fixes them. The precedent set in our last release with tp_print was that regenerating

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

I wanted to let people know that the four of us on the SC not driving this work -- i.e. everyone but Victor -- talked about this at our last meeting and we support the work to isolate interpreter state from being global. There are benefits for the situation where you have to integrate CPython wi

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

On Wed, Jun 17, 2020 at 4:16 AM Steve Dower wrote: > > 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, > >regenerating with new Cython release fixes them. > > The pre

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

After taking a break to recapitulate from the vigorous debate, Brandt Bucher has revised PEP 618 and submitted it for review . I volunteered to be PEP-Delegate (the new term for the outdated BDFL-Delegate) and the

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

Woo! Many thanks to Ram for the idea, Antoine for sponsoring, Guido for PEP-Delegating, and everyone on -Ideas and -Dev for the spirited discussion and review. Brandt ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to

[Python-Dev] Re: type() does not call __prepare__?

It's not a bug, it's just bypassing steps in the Py3 dynamic class definition process. https://docs.python.org/3/library/types.html#types.new_class is the API to use to invoke the full metaclass machinery, including namespace preparation. https://docs.python.org/3/reference/datamodel.html#metacla