[Python-Dev] Re: PEP 554 comments

Even then, disconnect seems like the primary use case, with a channel.kill_for_all being a specialized subclass. One argument for leaving it to a subclass is that it isn't clear what other interpreters should do when that happens. Shut down? Start getting exceptions if they happen to use it

[Python-Dev] Re: killing static types (for sub-interpreters?)

Ronald Oussoren wrote: > > On 28 Apr 2020, at 20:38, Jim J. Jewett jimjjew...@gmail.com wrote: > > Why do sub-interpreters require (separate and) heap-allocated types? > > It seems types that are statically allocated are a pretty good use for > > immortal > > objects, where you never change the

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

On Wed, Apr 22, 2020 at 7:40 PM Kyle Stanley wrote: > If there's not an implementation detail that makes this impractical, > I'd like to give my +1 on the `Interpreter.run()` method returning > values. From a usability perspective, it seems incredibly convenient > to have the ability to call a

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

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 > provides no value over threading or

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

On Mon, Apr 20, 2020 at 6:21 PM Eric Snow wrote: > > Nathaniel, > > Your tone and approach to this conversation concern me. I appreciate > that you have strong feelings here and readily recognize I have my own > biases, but it's becoming increasingly hard to draw any constructive > insight from

[Python-Dev] Re: PEP 554 comments

On Tue, Apr 21, 2020 at 11:21 PM Greg Ewing wrote: > What I'm suggesting is that close() should do what the > PEP defines release() as doing, and release() shouldn't > exist. > > I don't see why an interpreter needs the ability to close > a channel for any *other* interpreter. There is no such >

[Python-Dev] Re: PEP 554 comments

On Wed, Apr 22, 2020 at 2:13 AM Kyle Stanley wrote: > If you'd like an example format for marking a section of the docs as > provisional w/ reST, something like this at the top should suffice > (with perhaps something more specific to the subinterpreters module): > > > .. note:: > This

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

On Sun, Apr 26, 2020 at 2:21 PM Carl Shapiro wrote: > While this PEP may not create a maintenance burden for CPython, it > does have the effect of raising the complexity bar for an alternative > Python implementation. FWIW, I did reach out to the various major Python implementation about this

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

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 bridging Objective-C classes (and instances) to Python. This is >

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

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 belong in this PEP itself. > > *But* the existence of a document

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

On Tue, Apr 21, 2020 at 10:24 AM Sebastian Berg wrote: > On Tue, 2020-04-21 at 16:21 +0200, Victor Stinner wrote: > > I fail to follow your logic. When the asyncio PEP was approved, I > > don't recall that suddenly the whole Python community started to > > rewrite all projects to use coroutines

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

On Tue, Apr 21, 2020 at 11:31 PM Greg Ewing wrote: > To put it another way, the moment you start using subinterpreters, > the set of extension modules you are able to use will shrink > *enormously*. Very true but we have to start somewhere. > And if I understand correctly, you won't get any

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

Oh, I didn't know this Python 3.8 new feature (@functools.cached_property). It does exactly what I needed, cool! Victor Le mar. 28 avr. 2020 à 21:18, Brett Cannon a écrit : > > Victor Stinner wrote: > > Hi, > > A pattern that I used multiple times is to compute an object attribute > > only once

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

> t...@tomforb.es wrote: > > I would like to suggest adding a simple “once” method to functools. As the > name suggests, this would be a decorator that would call the decorated > function, cache the result and return it with subsequent calls. It seems like you would get just about everything

[Python-Dev] Re: killing static types (for sub-interpreters?)

On 28Apr2020 2006, Steve Dower wrote: (For those who aren't following it, there's a discussion with a patch and benchmarks going on at https://bugs.python.org/issue40255 about making objects individually immortal. It's more focused around copy-on-write, rather than subinterpreters, but the

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

Victor Stinner wrote: > Hi, > A pattern that I used multiple times is to compute an object attribute > only once and cache the result into the object. Dummy example: How is that different from https://docs.python.org/3/library/functools.html?highlight=cached_property#functools.cached_property?

[Python-Dev] Re: killing static types (for sub-interpreters?)

If the object is going to live until the "end of time" (process/runtime/whatever) then there'll never be a need to deallocate it, and so there's no point counting how many references exist (and ditto for anything that it references). Currently, statically allocated types include references to

[Python-Dev] Re: killing static types (for sub-interpreters?)

> On 28 Apr 2020, at 20:38, Jim J. Jewett wrote: > > Why do sub-interpreters require (separate and) heap-allocated types? > > It seems types that are statically allocated are a pretty good use for > immortal objects, where you never change the refcount ... and then I don't > see why you

[Python-Dev] Re: killing static types (for sub-interpreters?)

I don't know the answer to this, but what are some examples of objects where you never change the refcount? Are these Python objects? If so, wouldn't doing something like adding the object to a list necessarily change its refcount, since the list implementation only knows, "I have a reference to

[Python-Dev] Re: Announcement: pip 20.1b1 beta release

Thanks for the testing, all. Pip 20.1 is now out and https://pip.pypa.io/en/latest/news/ has the changes since the beta. -- Sumana Harihareswara Changeset Consulting https://changeset.nyc ___ Python-Dev mailing list -- python-dev@python.org To

[Python-Dev] killing static types (for sub-interpreters?)

Why do sub-interpreters require (separate and) heap-allocated types? It seems types that are statically allocated are a pretty good use for immortal objects, where you never change the refcount ... and then I don't see why you need more than one copy.

[Python-Dev] Re: Improvement to SimpleNamespace

On 2020-04-16 04:33, Rob Cliffe via Python-Dev wrote: Here's another revolutionary thought:  add a new operator and associated dunder method (to object?) whose meaning is *undefined*.  Its default implementation would do *nothing* useful (raise an error? return None?). E.g. suppose the

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

On behalf of the entire Python development community, and the currently serving Python release team in particular, I’m pleased to announce the release of Python 3.9.0a6. Get it here: https://www.python.org/downloads/release/python-390a6/

[Python-Dev] Re: Request For Review: Add support for CAN_J1939 sockets (bpo-40291)

This seems to be a reasonable feature. On Tue, Apr 28, 2020 at 07:29 Karl Ding wrote: > Hi all, > > Could someone take a look at the following PR to add support for CAN_J1939 > to the socket module? I'd like to try landing this for 3.9. This > enhancement would be useful for anyone working in

[Python-Dev] Request For Review: Add support for CAN_J1939 sockets (bpo-40291)

Hi all, Could someone take a look at the following PR to add support for CAN_J1939 to the socket module? I'd like to try landing this for 3.9. This enhancement would be useful for anyone working in automotive and/or dealing with the SAE J1939 CAN protocol. This feature is available on Linux 5.4+

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

Hi, A pattern that I used multiple times is to compute an object attribute only once and cache the result into the object. Dummy example: --- class X: def __init__(self, name): self.name = name self._cached_upper = None def _get(self): if self._cached_upper is

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

On 28Apr2020 1243, Petr Viktorin wrote: On 2020-04-28 00:26, Steve Dower wrote: On 27Apr2020 2311, Tom Forbes wrote: Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object. It’s not that it’s impossible, but I didn’t

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

On 2020-04-28 00:26, Steve Dower wrote: On 27Apr2020 2311, Tom Forbes wrote: Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object. It’s not that it’s impossible, but I didn’t think the current implementation doesn’t