On Thu, 2022-02-24 at 00:21 +0100, Antonio Cuni wrote:
> On Mon, Feb 21, 2022 at 5:18 PM Petr Viktorin
> wrote:
>
> Should we care about hacks/optimizations that rely on having the only
> > reference (or all references), e.g. mutating a tuple if it has
> > refcount
> > 1? Immortal objects shouldn
On Mon, Feb 21, 2022 at 5:18 PM Petr Viktorin wrote:
Should we care about hacks/optimizations that rely on having the only
> reference (or all references), e.g. mutating a tuple if it has refcount
> 1? Immortal objects shouldn't break them (the special case simply won't
> apply), but this wording
> And it seems like we still care about support Visual Studio 2017, even
> if Visual Studio 2019 and 2022 are available.
Can we make this more concrete? Do we know of affected parties? Numbers
of affected users? Or are we just conservatively guesstimating the thickness
of the long tail of support?
On Wed, Feb 23, 2022 at 8:19 AM Petr Viktorin wrote:
> On 23. 02. 22 2:46, Eric Snow wrote:
>
>
[SNIP]
>
> > So it seems like the bar should be pretty low for this one (assuming
> > we get the performance penalty low enough). If it were some massive
> > or broadly impactful (or even clearly pu
On Wed, Feb 23, 2022 at 7:11 PM Petr Viktorin wrote:
> I did realize there's one more issue when converting macros or static
> inline functions to regular functions.
> Regular functions' bodies aren't guarded by limited API #ifdefs, so if
> they are part of the limited API it's easy to forget to t
On Wed, Feb 23, 2022 at 7:11 PM Petr Viktorin wrote:
> In the PEP, the "Performance and inlining" section seems unnecessary. It
> talks about attributes that aren't used in the implementation. Or are
> they? How does the section relate to the rest of the PEP?
> The "Benchmark comparing macros and
On 22. 02. 22 13:41, Victor Stinner wrote:
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:
Hi,
I updated my PEP 7 PR to use C99 in the public C API and "a subset of"
C11 in Python internals:
"Python 3.11 and newer versions use C99 in the public C API and use a
subset of C11 in Python internals. The public C API should be
compatible with C++. The C11 subset are features supported by GCC
On 22. 02. 22 15:10, Victor Stinner wrote:
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
On 23. 02. 22 2:46, Eric Snow wrote:
Thanks for the responses. I've replied inline below.
Same here :)
Immortal Global Objects
---
All objects that we expect to be shared globally (between interpreters)
will be made immortal. That includes the following:
* singletons
10 matches
Mail list logo
