On Mon, Nov 28, 2022 at 6:45 PM Steven D'Aprano wrote:
> On Tue, Nov 29, 2022 at 01:34:54PM +1300, Greg Ewing wrote:
> > I got the impression that there were some internal language reasons
> > to want stable dicts, e.g. so that the class dict passed to __prepare__
> > preserves the order in which
On Thu, Jul 21, 2022 at 12:19 AM Stefan Behnel wrote:
> I'm actually reading python-dev, c.l.py etc. through Gmane, and have done
> that ever since I joined. Simply because it's a mailing list of which I
> don't need a local (content) copy, and wouldn't want one. Gmane seems to
> have a complete
On Mon, Jul 18, 2022 at 11:48 AM wrote:
> LLVM did the same recently (though they imported all previous messages from
> the mailinglist, thus making them searchable in discourse) [2 - announcement;
> 3 - retro], and by and large, I think it was a success.
>
> One of the comments in the retro
On Fri, Jul 15, 2022 at 5:21 AM Petr Viktorin wrote:
> The Steering Council would like to switch from python-dev to
> discuss.python.org.
This seems like a net win for the community so +1 from me. (For me
personally it amounts to disruption with little advantage, so I'd
probably be -0).
On Fri, Jul 15, 2022 at 12:15 PM Barry Warsaw wrote:
> I agree that the experiment has proven successful enough that there’s more
> value at this point in consolidating discussions.
We've only been running this experiment since 2017(?) so maybe it's
too soon to say it's a success?
-eric
responses inline
-eric
On Wed, Mar 9, 2022 at 8:23 AM Petr Viktorin wrote:
> "periodically reset the refcount for immortal objects (only enable this
> if a stable ABI extension is imported?)" -- that sounds quite expensive,
> both at runtime and maintenance-wise.
Are you talking just about
On Wed, Mar 9, 2022 at 7:37 PM Carl Meyer wrote:
> > Note that Instagram isn't exactly using Cinder.
>
> This sounds like a misunderstanding somewhere. Instagram server is
> "exactly using Cinder" :)
:)
Thanks for clarifying, Carl.
> > I'll have to check if Cinder uses the pre-fork model.
>
Thanks for the feedback, Petr! Responses inline below.
-eric
On Wed, Mar 9, 2022 at 10:58 AM Petr Viktorin wrote:
> This PEP definitely makes per-interpreter GIL sound possible :)
Oh good. :)
> > PEP: 684
> > Title: A Per-Interpreter GIL
> > Author: Eric Snow
> >
On Mon, Feb 28, 2022 at 6:01 PM Eric Snow wrote:
> The updated PEP text is included below. The largest changes involve
> either the focus of the PEP (internal mechanism to mark objects
> immortal) or the possible ways that things can break on older 32-bit
> stable ABI extensions
of cutting corners. Hence, we'll see how it goes.
The PEP text is included inline below. Thanks!
-eric
===
PEP: 684
Title: A Per-Interpreter GIL
Author: Eric Snow
Discussions-To: python-dev@python.org
Status: Draft
Type: Standards Track
Content-Type
extensions. All other changes are smaller.
Given the last round of discussion, I'm hoping this will be the last
round before we go to the steering council.
-eric
PEP: 683
Title: Immortal Objects, Using a Fixed Refcount
Author: Eric Snow , Eddie Elizondo
Discussions-To:
https
On Wed, Feb 23, 2022 at 4:21 PM Antonio Cuni wrote:
> When refcheck=True (the default), numpy raises an error if you try to resize
> an array inplace whose refcnt > 2 (although I don't understand why > 2 and
> not > 1, and the docs aren't very clear about this).
>
> That said, relying on the
On Wed, Feb 23, 2022 at 9:16 AM Petr Viktorin wrote:
>>> But tp_dict is also public C-API. How will that be handled?
>>> Perhaps naively, I thought static types' dicts could be treated as
>>> (deeply) immutable, and shared?
>>
>> They are immutable from Python code but not from C (due to
Responses inline below.
-eric
On Tue, Feb 22, 2022 at 7:22 PM Inada Naoki wrote:
> > For a recent example, see
> > https://mail.python.org/archives/list/python-dev@python.org/message/B77BQQFDSTPY4KA4HMHYXJEV3MOU7W3X/.
>
> It is not proven example, but just a hope at the moment. So option is
>
On Tue, Feb 22, 2022, 20:26 Larry Hastings wrote:
> Are these optimizations specifically for the PR, or are these
> optimizations we could apply without taking the immortal objects? Kind of
> like how Sam tried to offset the nogil slowdown by adding optimizations
> that we went ahead and added
On Sat, Feb 19, 2022 at 12:46 AM Eric Snow wrote:
> Performance
> ---
>
> A naive implementation shows `a 4% slowdown`_.
> Several promising mitigation strategies will be pursued in the effort
> to bring it closer to performance-neutral. See the `mitigation`_
> secti
On Mon, Feb 21, 2022 at 4:56 PM Terry Reedy wrote:
> We could say that the only refcounts with any meaning are 0, 1, and > 1.
Yeah, that should work.
-eric
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to
On Mon, Feb 21, 2022 at 10:56 AM wrote:
> For what it's worth Cython does this for string concatenation to concatenate
> in place if possible (this optimization was copied from CPython). It could be
> disabled relatively easily if it became a problem (it's already CPython only
> and version
Thanks for the responses. I've replied inline below.
-eric
On Mon, Feb 21, 2022 at 9:11 AM Petr Viktorin wrote:
>
> On 19. 02. 22 8:46, Eric Snow wrote:
> > Thanks to all those that provided feedback. I've worked to
> > substantially update the PEP in response. The text
g we can reduce the performance penalty
to acceptable levels. For a recent example, see
https://mail.python.org/archives/list/python-dev@python.org/message/B77BQQFDSTPY4KA4HMHYXJEV3MOU7W3X/.
> On Sat, Feb 19, 2022 at 4:52 PM Eric Snow wrote:
> >
> > Reducing CPU Cache Invalidation
> >
Thanks to all those that provided feedback. I've worked to
substantially update the PEP in response. The text is included below.
Further feedback is appreciated.
-eric
PEP: 683
Title: Immortal Objects, Using a Fixed Refcount
Author: Eric Snow , Eddie Elizondo
On Wed, Feb 16, 2022 at 11:06 AM Larry Hastings wrote:
> I experimented with this at the EuroPython sprints in Berlin years ago. I
> was sitting next to MvL, who had an interesting observation about it.
Classic MvL! :)
> He suggested(*) all the constants unmarshalled as part of loading a
On Wed, Feb 16, 2022 at 8:45 PM Inada Naoki wrote:
> Is there any common tool that utilize CoW by mmap?
> If you know, please its link to the PEP.
> If there is no common tool, most Python users can get benefit from this.
Sorry, I'm not aware of any, but I also haven't researched the topic
much.
Again, thanks for the reply. It's helpful. My further responses are
inline below.
-eric
On Thu, Feb 17, 2022 at 3:42 AM Petr Viktorin wrote:
> > Agreed. However, what behavior do users expect and what guarantees do
> > we make? Do we indicate how to interpret the refcount value they
> >
On Wed, Feb 16, 2022 at 10:43 PM Jim J. Jewett wrote:
> I suggest being a little more explicit (even blatant) that the particular
> details of:
> [snip]
> are not only Cpython-specific, but are also private implementation details
> that are expected to change in subsequent versions.
Excellent
On Wed, Feb 16, 2022 at 2:41 PM Terry Reedy wrote:
> > * the naive implementation shows a 4% slowdown
>
> Without understanding all the benefits, this seems a bit too much for
> me. 2% would be much better.
Yeah, we consider 4% to be too much. 2% would be great.
Performance-neutral would be
On Wed, Feb 16, 2022 at 12:14 PM Kevin Modzelewski wrote:
> fwiw Pyston has immortal objects, though with a slightly different goal and
> thus design [1]. I'm not necessarily advocating for our design (it makes most
> sense if there is a JIT involved), but just writing to report our experience
Thanks for the feedback. My responses are inline below.
-eric
On Wed, Feb 16, 2022 at 6:36 AM Petr Viktorin wrote:
> Thank you very much for writing this down! It's very helpful to see a
> concrete proposal, and the current state of this idea.
> I like the change,
That's good to hear. :)
>
On Wed, Feb 16, 2022 at 12:37 AM Inada Naoki wrote:
> +1 for overall idea.
Great!
> > Also note that "fork" isn't the only operating system mechanism
> > that uses copy-on-write semantics.
>
> Could you elaborate? mmap, maybe?
> [snip[
> So if you know how to get benefit from CoW without fork,
al Objects, Using a Fixed Refcount
Author: Eric Snow , Eddie Elizondo
Discussions-To: python-dev@python.org
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Created: 10-Feb-2022
Python-Version: 3.11
Post-History:
Resolution:
Abstract
Under this proposal, any object may be marked a
On Wed, Dec 15, 2021 at 10:15 AM Eric Snow wrote:
> Yes, I plan on benchmarking the change as soon as we can run
> pyperformance on main.
I just ran the benchmarks and the PR makes CPython 4% slower. See
https://github.com/python/cpython/pull/19474#issuecomment-1032944709.
On Fri, Feb 4, 2022 at 8:25 PM Eric Snow wrote:
> On Fri, Feb 4, 2022, 16:03 Guido van Rossum wrote:
>> I wonder if a better solution than that PR wouldn't be to somehow change the
>> implementation of _Py_IDENTIFIER() to do that,
>
> Yeah, I had the same realization tod
On Fri, Feb 4, 2022, 16:03 Guido van Rossum wrote:
> I wonder if a better solution than that PR wouldn't be to somehow change
> the implementation of _Py_IDENTIFIER() to do that,
>
Yeah, I had the same realization today. I'm going to try it out.
-eric
>
On Thu, Feb 3, 2022 at 3:49 PM Eric Snow wrote:
> I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
> 3rd party modules.
Between Guido, Victor, Stefan, and Sebastian, I'm getting the sense
that a public replacement for _Py_IDENTIFER() would be worth pursuing.
Consi
On Fri, Feb 4, 2022 at 8:21 AM Stefan Behnel wrote:
> Correct. We (intentionally) have our own way to intern strings and do not
> depend on CPython's identifier framework.
You're talking about __Pyx_StringTabEntry (and __Pyx_InitString())?
-eric
___
On Thu, Feb 3, 2022 at 4:01 PM Guido van Rossum wrote:
> Why not read through some of that code and see what they are doing with it?
Yep, I'm planning on it.
> I imagine one advantage is that _Py_IDENTIFIER() can be used entirely local
> to a function.
Yeah, they'd have to put something like
On Thu, Feb 3, 2022 at 7:26 AM Victor Stinner wrote:
> In bpo-39465, I made the _PyUnicode_FromId() compatible with running
> sub-interpreters in parallel (one GIL per interpreter).
>
> A "static" PyUnicodeObject would have to share the reference count
> between sub-interpreters, whereas
On Thu, Feb 3, 2022 at 7:17 AM Victor Stinner wrote:
> In the top 5000 PyPI projects, I found 11 projects using them:
> [snip[
> They use the these 17 functions:
Thanks! That is super helpful.
> If the _Py_IDENTIFIER() API is removed, it would be *nice* to provide
> a migrate path (tool?) to
On Thu, Feb 3, 2022 at 6:46 AM Ronald Oussoren wrote:
> Although my gut feeling is that adding a the CI check you mention is good
> enough and adding the tooling for generating code isn’t worth the additional
> complexity.
Yeah, I came to the same conclusion. :)
-eric
On Wed, Feb 2, 2022 at 11:50 PM Inada Naoki wrote:
> It would be nice to provide something similar to _PY_IDENTIFIER, but
> designed (and documented) for 3rd party modules like this.
I suppose I'd like to know what the value of _Py_IDENTIFIER() is for
3rd party modules. They can already use
I'm planning on moving us to a simpler, more efficient alternative to
_Py_IDENTIFIER(), but want to see if there are any objections first
before moving ahead. Also see https://bugs.python.org/issue46541.
_Py_IDENTIFIER() was added in 2011 to replace several internal string
object caches and to
On Wed, Feb 2, 2022 at 3:41 PM Eric Snow wrote:
> I'd also like to actually get rid of _Py_IDENTIFIER(), along with
> other related API including ~14 (private) C-API functions.
FTR, here is the (private/internal) C-API affected by getting rid of
_Py_IDENTIFIER():
* 21 C-API fun
On Thu, Jan 27, 2022 at 8:40 AM Victor Stinner wrote:
> tl; dr Python no longer leaks memory at exit on the "python -c pass" command
> ;-)
Thanks to all for the effort on this!
Would it be worth adding a test to make sure we don't start leaking
memory again?
-eric
On Wed, Jan 5, 2022, 15:02 Trent Nelson wrote:
> I thought that was pretty interesting. Potentially many, many upper
> bits for the taking. The code also had some logic that would int 3
> as soon as a 32-bit refcnt overflowed, and that never hit either
> (obviously, based on the numbers
On Thu, Dec 16, 2021 at 10:54 AM Guido van Rossum wrote:
>
> Eric has been looking into this. It's probably the only solution if we can't
> get immutable objects.
Yep. I've investigated the following approach (for the objects
exposed in the public and limited C-API):
* add a pointer field to
On Thu, Dec 16, 2021 at 4:34 AM Antoine Pitrou wrote:
> As a data point, in PyArrow, we have a bunch of C++ code that interacts
> with Python but doesn't belong in a particular Python module. That C++
> code can of course have global state, including perhaps Python objects.
Thanks for that
On Thu, Dec 16, 2021 at 2:48 AM Petr Viktorin wrote:
> But does the sign bit need to stay intact, and do we actually need to
> rely on the immortal bit to always be set for immortal objects?
> If the refcount rolls over to zero, an immortal object's dealloc could
> bump it back and give itself
On Tue, Dec 14, 2021 at 10:12 AM Eric Snow wrote:
> * it is fully backward compatible and the C-API is essentially unaffected
Hmm, this is a little misleading. It will definitely be backward
incompatible for extension modules that don't work under multiple
subinterpreters (or rely on the
On Wed, Dec 15, 2021 at 12:18 PM Chris Angelico wrote:
> Sorry if this is a dumb question, but would it be possible to solve
> that last point with an immortal arena [1] from which immortal objects
> could be allocated? None/True/False could be allocated there, but so
> could anything that is
On Tue, Dec 14, 2021 at 11:19 AM Eric Snow wrote:
> There is one solution that would help both of the above in a nice way:
> "immortal" objects.
FYI, here are some observations that came up during some discussions
with the "faster-cpython" team today:
* immortal ob
On Wed, Dec 15, 2021 at 6:16 AM Antoine Pitrou wrote:
> Did you try to take into account the envisioned project for adding a
> "complete" GC and removing the GIL?
Yeah. I was going to start a separate thread about per-interpreter
GIL vs. no-gil, but figured I was already pushing my luck with 3
On Wed, Dec 15, 2021 at 8:16 AM Skip Montanaro wrote:
> It might be worth (re)reviewing Sam Gross's nogil effort to see how he
> approached this:
Yeah, there is good info in there.
-eric
___
Python-Dev mailing list -- python-dev@python.org
To
On Wed, Dec 15, 2021 at 4:03 AM Victor Stinner wrote:
> The last time I saw a benchmark on immortal object, it was clearly 10%
> slower overall on the pyperformance benchmark suite. That's a major
> slowdown.
Yes, I plan on benchmarking the change as soon as we can run
pyperformance on main.
>
On Tue, Dec 14, 2021 at 11:19 AM Eric Snow wrote:
> The idea of objects that never get deallocated isn't new and has been
> explored here several times. Not that long ago I tried it out by
> setting the refcount really high. That worked. Around the same time
> Eddie Elizondo at
On Wed, Dec 15, 2021 at 2:42 AM Christian Heimes wrote:
> Would it be possible to write the Py_INCREF() and Py_DECREF() macros in
> a way that does not depend on branching? For example we could use the
> highest bit of the ref count as an immutable indicator and do something like
As Antoine
On Wed, Dec 15, 2021 at 2:50 AM Pablo Galindo Salgado
wrote:
> One thing to consider: ideally, inmortal objects should not participate in
> the GC. There is nothing inheritly wrong if they do but we would need to
> update the GC (and therefore add more branching in possible hot paths) to
>
On Tue, Dec 14, 2021 at 4:09 PM Brett Cannon wrote:
> There's also the concern of memory usage if these immortal objects are never
> collected.
>
> But which objects are immortal? You only listed None, True, and False.
> Otherwise assume/remember I'm management and provide a list and/or link
Yeah, no (mutable) global state at the C level. It would also be good
to implement multi-phase init (PEP 489), but I don't expect that to
require much work itself.
-eric
On Tue, Dec 14, 2021 at 4:04 PM Brett Cannon wrote:
>
>
>
> On Tue, Dec 14, 2021 at 9:41 AM Eric Snow wrot
Most of the work toward interpreter isolation and a per-interpreter
GIL involves moving static global variables to _PyRuntimeState or
PyInterpreterState (or module state). Through the effort of quite a
few people, we've made good progress. However, many globals still
remain, with the majority
One of the open questions relative to subinterpreters is: how to
reduce the amount of work required for extension modules to support
them? Thanks to Petr Viktorin for a lot of work he's done in this
area (e.g. PEP 489)! Extensions also have the option to opt out of
subinterpreter support.
Hi all,
I'm still hoping to land a per-interpreter GIL for 3.11. There is
still a decent amount of work to be done but little of it will require
solving any big problems:
* pull remaining static globals into _PyRuntimeState and PyInterpreterState
* minor updates to PEP 554
* finish up the last
On Thu, Dec 9, 2021, 11:26 Petr Viktorin wrote:
> I'll not get back to CPython until Tuesday, but I'll add a quick note
> for now. It's a bit blunt for lack of time; please don't be offended.
>
Not at all. :) The tooling is a secondary concern to my point. Mostly, I
wish the declarations in
(replying to
https://mail.python.org/archives/list/python-dev@python.org/message/OJ65FPCJ2NVUFNZDXVNK5DU3R3JGLL3J/)
On Wed, Dec 8, 2021 at 10:06 AM Eric Snow wrote:
> What about the various symbols listed in Misc/stable_abi.txt that were
> accidentally added to the limited API? Can w
On Thu, Dec 9, 2021 at 1:56 AM Petr Viktorin wrote:
> It's possible to remove them just like _PyObject_GC_Malloc was removed,
> but check that it was unusable (e.g. not called from public macros) in
> all versions of Python from 3.2 up to now.
That's what I expected. Thanks.
> Could you check
On Wed, Dec 8, 2021 at 2:23 AM Petr Viktorin wrote:
> That really depends on what function we'd want to remove. There are
> usually alternatives to deleting things, but the options depend on the
> function. If we run out of other options we can make the function always
> fail or make it leak
On Tue, Sep 28, 2021 at 6:55 AM Eric V. Smith wrote:
> As a compromise, how about go with #1, but print a warning if python
> detects that it's not built with optimizations or is run from a source
> tree (the conditions in #2 and #3)? The warning could suggest running
> with "-X
On Tue, Sep 28, 2021 at 6:47 AM Pablo Galindo Salgado
wrote:
> One interesting consequence of what Eric mentioned (They have a different
> loader and repr. Also, frozen modules do not
> have __file__ set (and __path__ is always []).) is that frozen modules don't
> have a `__file__` attribute
On Tue, Sep 28, 2021 at 6:36 AM Victor Stinner wrote:
> Honestly, for me, #1: always on, is the most reasonable choice.
>
> I dislike when Python behaves differently depending on subtle things
> like "was it built with optimizations" or "is Python started from its
> source tree"?
>
> When I built
On Tue, Sep 28, 2021 at 2:22 AM Marc-Andre Lemburg wrote:
> #3 sounds like a good solution, but how would you detect "running
> from the source tree" ? This sounds like you need another stat call
> somewhere, which is what the frozen modules try to avoid.
We already look for the stdlib dir in
On Tue, Sep 28, 2021 at 6:02 AM Ronald Oussoren via Python-Dev
wrote:
> Of course. I mentioned it because the proposal is to add a new option that’s
> enabled after installation, and basically not when the testsuite is run.
> That’s not a problem, we could just enable the option in most CI
On Tue, Sep 28, 2021 at 2:54 AM Ronald Oussoren via Python-Dev
wrote:
> I agree, but… Most CPython tests are run while running from the source tree,
> that means that there will have to be testrunner configurations that run with
> “-X frozen_modules=on”.
If the build option that determines the
On Mon, Sep 27, 2021 at 3:31 PM Victor Stinner wrote:
> Which stdlib modules are currently frozen? If I really want to hack
> site.py or os.py for whatever reason, I just have to use "python3 -X
> frozen_modules=off"?
The single-source-of-truth is Tools/scripts/freeze_modules.py. After
running
On Mon, Sep 27, 2021 at 3:04 PM Barry Warsaw wrote:
> If you’re planning a runtime -X option, then does that mean that the modules
> will be frozen at build time but Python will decide at runtime whether to use
> the frozen modules or the unfrozen ones?
Correct. FYI, this was already done.
>
On Mon, Sep 27, 2021 at 2:59 PM Brett Cannon wrote:
> What about opting out when `--with-pydebug` is used? I'm not sure how many
> people actively develop in a non-debug build other than testing something,
> but at that point I would be having to run `make` probably anyway for
> whatever I'm
On Mon, Sep 27, 2021 at 12:40 PM Steve Dower wrote:
> Having it be implied by an "--enable-optimizations" option is totally
> fine (and we'd add one to build.bat for this), but I still think it
> needs to be discoverable later whether the frozen modules build option
> was used or not, independent
On Mon, Sep 27, 2021 at 10:51 AM Eric Snow wrote:
> Possible solutions:
>
> 1. always default to "on" (the annoyance for contributors isn't big enough?)
> 2. default to "on" if it's a PGO build (and "off" otherwise)
> 3. default to "on"
On Mon, Sep 27, 2021 at 11:09 AM Chris Angelico wrote:
> When exactly does the freezing happen?
When you build the executable (e.g. "make -j8",
".\PCbuild\build.bat"). So your changes to those .py files wouldn't
show up until then.
-eric
___
We've frozen most of the stdlib modules imported during "python -c
pass" [1][2], to make startup a bit faster. Import of those modules
is controlled by "-X frozen_modules=[on|off]". Currently it defaults
to "off" but we'd like to default to "on". The blocker is the impact
on contributors. I
On Fri, Sep 3, 2021 at 5:32 AM Paul Moore wrote:
> On Fri, 3 Sept 2021 at 10:29, Simon Cross
> wrote:
> > I think adding a meta path importer that reads from a standard
> > optimized format could be a great addition.
>
> I think the biggest open question would be "what benefits does this
> have
On Thu, Sep 2, 2021 at 10:46 PM Gregory Szorc wrote:
> Over in https://bugs.python.org/issue45020 there is some exciting work around
> expanding the use of the frozen importer to speed up Python interpreter
> startup. I wholeheartedly support the effort and don't want to discourage
> progress
On Mon, Aug 23, 2021 at 4:16 PM Ammar Askar wrote:
> As part of PEP 588, migrating bugs.python.org issues to Github,
Thanks for working on this!
> 1. Weekly summary emails with bug counts and issues from the week,
> 2. Emails sent to the new-bugs-announce and python-bugs-list for new
I rely on
On Fri, Aug 13, 2021 at 11:29 AM Guido van Rossum wrote:
> If these weren't part of the stable ABI, I'd choose (E).
They aren't in the stable ABI (or limited API). Instead, they are
part of the broader public API (declared in Include/cpython/code.h,
along with "struct PyCodeObject" and others).
On Thu, Jan 28, 2021 at 9:28 AM Mark Shannon wrote:
> Is there a good reason not to start using C11 now?
Would C17 be a better choice? It sounds like it exists to fix
problems with C11 (and doesn't actually add any new features).
-eric
___
Python-Dev
On Fri, Jul 3, 2020, 12:40 Eric Snow wrote:
> Also, keep in mind that PEPs are a tool for the decision maker (i.e.
> BDFL delegate). Effectively, everything else is convention. The process
> usually involves community feedback, but has never been community-driven.
> All this has
On Fri, Jul 3, 2020, 09:18 Antoine Pitrou wrote:
> I think what you describe as "the usual procedure" isn't as usual as
> you think.
>
+1
Also, keep in mind that PEPs are a tool for the decision maker (i.e. BDFL
delegate). Effectively, everything else is convention. The process
usually
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
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
On Wed, Jun 3, 2020 at 7:12 AM Mark Shannon wrote:
> The size of the C API, as measured by `git grep PyAPI_FUNC | wc -l` has
> been steadily increasing over the last few releases.
>
> 3.5 1237
> 3.6 1304
> 3.7 1408
> 3.8 1478
> 3.9 1518
>
>
> For reference the 2.7 branch has
On Fri, May 29, 2020 at 12:16 PM Python tracker wrote:
> ACTIVITY SUMMARY (2020-05-22 - 2020-05-29)
> 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:
> open
On Thu, May 7, 2020 at 2:50 AM Emily Bowman wrote:
> While large object copies are fairly fast -- I wouldn't say trivial, a
> gigabyte copy will introduce noticeable lag when processing enough of them --
> the flip side of having large objects is that you want to avoid having so
> many copies
On Wed, May 6, 2020 at 2:25 PM Jeff Allen wrote:
> Many thanks for working on this so carefully for so long. I'm happy to see
> the per-interpreter GIL will now be studied fully before final commitment to
> subinterpreters in the stdlib. I would have chipped in in those terms to the
> review,
On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
FYI, after consulting with the steering council I've decided to change
the target release to 3.10, when we
On Mon, May 4, 2020 at 1:22 PM Paul Moore wrote:
> One thing I would like to see is a comment confirming that as part of
> the implementation, all stdlib modules will be made
> subinterpreter-safe.
Yeah, I'd meant to put a note. I'll add one. Thanks!
-eric
On Mon, May 4, 2020 at 11:30 AM Eric Snow wrote:
> Further feedback is welcome, though I feel like the PR is ready (or
> very close to ready) for pronouncement. Thanks again to all.
oops
s/the PR is ready/the PEP is ready/
-eric
___
Pyth
ready (or
very close to ready) for pronouncement. Thanks again to all.
-eric
------
PEP: 554
Title: Multiple Interpreters in the Stdlib
Author: Eric Snow
BDFL-Delegate: Antoine Pitrou
Status: Draft
Type: Standards Track
Content-Type: text/x-rst
Cre
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".
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
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 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
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?
1 - 100 of 566 matches
Mail list logo
