On 2/21/2022 11:11 AM, Petr Viktorin wrote:
On 19. 02. 22 8:46, Eric Snow wrote:
As part of this proposal, we must make sure that users can clearly
understand on which parts of the refcount behavior they can rely and
which are considered implementation details. Specifically, they should
use
On Tue, 22 Feb 2022 at 03:00, Larry Hastings wrote:
>
>
> On 2/21/22 22:06, Chris Angelico wrote:
>
> On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote:
>
> While I don't think it's fine to play devil's advocate, given the choice
> between "this will help a common production use-case"
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 would make them illegal.
>
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.
Further feedback is appreciated.
Thank you! This version is much clearer. I like the PEP more and more!
I've sent a PR with a
On 2/21/22 22:06, Chris Angelico wrote:
On Mon, 21 Feb 2022 at 16:47, Larry Hastings wrote:
While I don't think it's fine to play devil's advocate, given the choice between "this will
help a common production use-case" (pre-fork servers) and "this could hurt a hypothetical
production use
On 2/21/22 21:44, Larry Hastings wrote:
While I don't think it's fine to play devil's advocate,"
Oh! Please ignore the word "don't" in the above sentence. I /do/ think
it's fine to play devil's advocate.
Sheesh,
//arry/
___
Python-Dev
Well, maybe it's a bad example. I just wanted to say that converting
macros to static inline functions provide more accurate profiler data
and debuggers can more easily show static inline functions names when
they are inlined and put breakpoints of them. But you're right, it's
not a silver bullet
Results of the poll (which was open for 10 days):
* Move pythoncapi_compat: 19 votes (90%)
* Don't move pythoncapi_compat: 2 votes (10%)
Victor
On Fri, Feb 11, 2022 at 12:16 AM Victor Stinner wrote:
>
> I created a poll on Discourse:
>
Hi folks, as illustrated in faster-cpython#150 [1], we have implemented a
mechanism that supports data persistence of a subset of python date types with
mmap, therefore can reduce package import time by caching code object. This
could be seen as a more eager pyc format, as they are for the
