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 2/22/22 6:00 PM, Eric Snow wrote:
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`_
On Wed, Feb 23, 2022 at 1:46 AM Eddie Elizondo via Python-Dev
wrote:
>
>
> That article is five years old so it doesn't reflect the current state of the
> system! We have continuous profiling and monitoring of Copy on Writes and
> after introducing the techniques described in this PEP, we have
On Wed, Feb 23, 2022 at 10:12 AM Eric Snow wrote:
>
> Thanks for the feedback. I've responded inline below.
>
> -eric
>
> On Sat, Feb 19, 2022 at 8:50 PM Inada Naoki wrote:
> > I hope per-interpreter GIL success at some point, and I know this is
> > needed for per-interpreter GIL.
> >
> > But I
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`_
> section below.
FYI, Eddie
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 is included below.
>
Thanks for the feedback. I've responded inline below.
-eric
On Sat, Feb 19, 2022 at 8:50 PM Inada Naoki wrote:
> I hope per-interpreter GIL success at some point, and I know this is
> needed for per-interpreter GIL.
>
> But I am worrying about per-interpreter GIL may be too complex to
>
Hey Inada, thanks for the feedback
> Generally speaking, fork is a legacy API. It is too difficult to know which
> library is fork-safe, even for stdlibs.
Yes, this is something that Instagram has to go into great lengths to make sure
that we get the entire execution into a state where it's
Hi,
I am working with the PyCon Estonia team, helping them organise a
conference this year. The last three PyCon events were a great success and
after a year of break due to corona, we want to come back to keep on
bringing the Python community together in Tallinn.
As we are preparing for PyCon
On Tue, Feb 22, 2022 at 1:54 PM Petr Viktorin wrote:
> First, add notices to any documentation that using the macro as a
> l-value is a deprecated, CPython-specific detail. It should be clear
> that the only reason this usage is allowed is for backwards
> compatibility, and that alternate
Hi,
Thanks for looking into my PEP 674!
I don't understand well why Py_SIZE() cannot be changed until
Py_SET_SIZE() is available on all supported Python versions (so
affected projects don't have to add a compatibility code), whereas
it's ok to require a compatibility code to keep support for
Hello,
Thank you for submitting PEP 674 -- Disallow using macros as l-values!
For Py_TYPE, we respect the previous steering council's decision:
https://github.com/python/steering-council/issues/79
The Py_TYPE macro can be changed as proposed in 3.11. However, the old
SC explicitly noted that
Hello,
The Steering Council discussed PEP 680 -- tomllib: Support for Parsing
TOML in the Standard Library, and unanimously decided to accept it.
Congratulations!
I'll change the PEP status to Accepted. Please open a PR for Python 3.11
at your convenience.
- Petr (on behalf of the Python
Hi,
Since Erlend and me posted PEP 670 on python-dev last October, we took
all feedback (python-dev and Steering Council) in account to clarify
the intent of the PEP and to reduce its scope (remove *any* risk of
backward compatibility).
PEP 670: https://python.github.io/peps/pep-0670/
Changes
16 matches
Mail list logo
