[Python-Dev] Re: Adding a "call_once" decorator to functools

On 30/04/20 3:29 pm, Raymond Hettinger wrote: Do you think it is safe to hold a non-reentrant lock across an arbitrary user function? I think what's wanted here is to block if it's locked by a different thread, but raise an exception if it's locked by the same thread. -- Greg _

[Python-Dev] Re: PEP 554 comments

On Wed, Apr 29, 2020, 22:05 Greg Ewing wrote: > > Furthermore, IMHO "release" is better at communicating the > > per-interpreter nature than "close". > > Channels are a similar enough concept to pipes that I think > it would be confusing to have "close" mean "close for all > interpreters". Everyo

[Python-Dev] Re: PEP 554 comments

On 29/04/20 2:12 pm, Eric Snow wrote: One of the main inspirations for the proposed channels is CSP (and somewhat relatedly, my in-depth experience with Go). Channels are more than just a thread-safe data transport between interpreters. It's a while since I paid attention to the fine details o

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 29, 2020, at 4:20 PM, Antoine Pitrou wrote: > > On Wed, 29 Apr 2020 12:01:24 -0700 > Raymond Hettinger wrote: >> >> The call_once() decorator would need different logic: >> >> 1) if the function has already been called and result is known, return the >> prior result :-) >> 2) if

[Python-Dev] Re: Adding a "call_once" decorator to functools

On Wed, 29 Apr 2020 12:01:24 -0700 Raymond Hettinger wrote: > > The call_once() decorator would need different logic: > > 1) if the function has already been called and result is known, return the > prior result :-) > 2) if function has already been called, but the result is not yet known, >

[Python-Dev] [RELEASE] Python 3.8.3rc1 is now ready for testing

Python 3.8.3rc1 is the release candidate of the third maintenance release of Python 3.8. Go get it here: https://www.python.org/downloads/release/python-383rc1/ Assuming no critical problems are found prior to 2020-05-11, the scheduled

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

Thanks for the thoughtful post! I'm going to address some of your comments here and some in a separate discussion in the next few days. On Wed, Apr 29, 2020 at 10:36 AM Sebastian Berg wrote: > While I still think it is probably not part of PEP 554 as such, I guess > it needs a full blown PEP on

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

Thanks for the great insights into PyObjC! On Wed, Apr 29, 2020 at 9:02 AM Ronald Oussoren wrote: > I don’t know how much the move of global state to per-interpreter state > affects extensions, other than references to singletons and static types. That's the million dollar question. :) FYI, on

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On Wed, Apr 29, 2020 at 6:27 AM Julien Salort wrote: > If your proposal leads to an intelligible actual error, and a clear > warning in the documentation, instead of a silent crash, this sounds > like progress, even for those packages which won't work on > subinterpreters anytime soon... That's h

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On Wed, Apr 29, 2020 at 1:52 AM Paul Moore wrote: > One thing that isn't at all clear to me here is that when you say > "Subinterpreters run all Python code", do you *just* mean the core > language? Or the core language plus all builtins? Or the core > language, builtins and the standard library?

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

Thanks, Mark. Responses are in-line below. -eric On Wed, Apr 29, 2020 at 6:08 AM Mark Shannon wrote: > You can already do CSP with multiprocessing, plus you get true parallelism. > The question the PEP needs to answer is "what do sub-interpreters offer > that other forms of concurrency don't of

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On Wed, Apr 29, 2020 at 5:40 AM Julien Salort wrote: > Le 29/04/2020 à 03:18, Eric Snow a écrit : > > > My (honest) question is, how many folks using subinterpreters are > > going to want to use numpy (or module X) enough to get mad about it > > before the extension supports subinterpreters? Wha

[Python-Dev] Re: Adding a "call_once" decorator to functools

> On Apr 29, 2020, at 12:55 AM, Tom Forbes wrote: > > Hey Raymond, > Thanks for your input here! A new method wouldn’t be worth adding purely for > performance reasons then, but there is still an issue around semantics and > locking. Right. > it doesn’t actually ensure the function is calle

[Python-Dev] Re: Moving tzdata into the python organization

No objections here. -Barry > On Apr 29, 2020, at 06:05, Paul Ganssle wrote: > > Signed PGP part > Hi all, > > PEP 615 specifies that we will add a first party tzdata package. I created > this package at pganssle/tzdata, but I believe the final home for it should > be python/tzdata. Are there

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On Tue, 2020-04-28 at 19:20 -0600, Eric Snow wrote: > On Tue, Apr 21, 2020 at 11:17 AM Sebastian Berg > wrote: > > Maybe one of the frustrating points about this criticism is that it > > does not belong in this PEP. And that is actually true! I > > wholeheartedly agree that it doesn't really belon

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

> On 29 Apr 2020, at 03:50, Eric Snow wrote: > > On Wed, Apr 22, 2020 at 2:43 AM Ronald Oussoren > wrote: >> My mail left out some important information, sorry about that. > > No worries. :) > >> PyObjC is a two-way bridge between Python and Objective-C. One half of this >> is that is brid

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

On 2020-04-29 16:34, ro...@reportlab.com wrote: While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using the standard configure make dance. Is this a real change? Hi, This is a known issue, currently discussed in https://bugs.python.org/issue40

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

This is a know issue and there is already a discussion on bpo-40246 ( https://bugs.python.org/issue40246) on how to resolve it. On Wed, Apr 29, 2020 at 5:54 PM Eric V. Smith wrote: > Hi, ro...@reportlab.com. > > That looks like a real error. Thanks for the detailed report. Can you > open a ticke

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

Sorry for noise, but obviously most of my pasted text went wrong; not sure how to use this modern mailman. I see a syntax error in 3.9a6 with the code norm=lambda m: m+(m and(m[-1]!='\n'and'\n'or'')or'\n') ___ Python-Dev mailing list -- python-dev@pytho

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

Hi, ro...@reportlab.com. That looks like a real error. Thanks for the detailed report. Can you open a ticket on bugs.python.org? Eric On 4/29/2020 10:34 AM, ro...@reportlab.com wrote: While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using th

[Python-Dev] Re: [RELEASE] Python 3.9.0a6 is now available for testing

While testing 3.9a6 in the reportlab package I see this difference from 3.8.2; I built from source using the standard configure make dance. Is this a real change? robin@minikat:~/devel/reportlab/REPOS/reportlab/tests $ python Python 3.8.2 (default, Apr 8 2020, 14:31:25) [GCC 9.3.0] on linux T

[Python-Dev] Moving tzdata into the python organization

Hi all, PEP 615 specifies that we will add a first party tzdata package . I created this package at pganssle/tzdata , but I believe the final home for it should be python/tzdata. Are there any

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

Le 29/04/2020 à 03:18, Eric Snow a écrit : My (honest) question is, how many folks using subinterpreters are going to want to use numpy (or module X) enough to get mad about it before the extension supports subinterpreters? What will user expectations be when it comes to subinterpreters? We wi

[Python-Dev] Re: Comments on PEP 554 (Multiple Interpreters in the Stdlib)

Hi, On 29/04/2020 4:02 am, Eric Snow wrote: On Tue, Apr 21, 2020 at 10:42 AM Mark Shannon wrote: I'm generally in favour of PEP 554, but I don't think it is ready to be accepted in its current form. Yay(ish)! :) My main objection is that without per-subinterpeter GILs (SILs?) PEP 554 provi

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 4/29/2020 3:55 AM, Tom Forbes wrote: Hey Raymond, Thanks for your input here! A new method wouldn’t be worth adding purely for performance reasons then, but there is still an issue around semantics and locking. One thing I don't understand about the proposed @call_once (or whatever it's c

[Python-Dev] Re: Adding a "call_once" decorator to functools

Hey Raymond, Thanks for your input here! A new method wouldn’t be worth adding purely for performance reasons then, but there is still an issue around semantics and locking. Should we encourage/document `lru_cache` as the way to do `call_once`? If so, then I guess that’s suitable, but people ha

[Python-Dev] Re: PEP 554 for 3.9 or 3.10?

On Wed, 29 Apr 2020 at 02:26, Eric Snow wrote: > Subinterpreters run all Python code right now. I'm guessing by > "general python code" you are talking about the code folks are writing > plus their dependencies. In that case, it's only with extension > modules that we run into a problem, and we