Hi Fabio
Does the actual function object get re-created as well during the
recompilation process that you have described? Perhaps it might help
to note that the __code__ attribute of a function object f can be
mutated and that f is hashable?
Cheers,
Gabriele
On Thu, 17 Feb 2022 at 19:33, Fabio
Em qui., 17 de fev. de 2022 às 16:05, Mark Shannon
escreveu:
> Hi Fabio,
>
> This happened as part of implementing PEP 626.
> The previous behavior isn't very robust w.r.t doc strings and
> compiler optimizations.
>
> OOI, why would you want to revert to the old behavior?
>
>
Hi Mark,
The issue
Hi Fabio,
This happened as part of implementing PEP 626.
The previous behavior isn't very robust w.r.t doc strings and
compiler optimizations.
OOI, why would you want to revert to the old behavior?
Cheers,
Mark.
On 17/02/2022 5:52 pm, Fabio Zadrozny wrote:
Hi all,
I'm stumbling with an
Hi all,
I'm stumbling with an issue where the co_firstlineno behavior changed from
Python 3.9 to Python 3.10 and I was wondering if this was intentional or
not.
i.e.: Whenever a code is compiled in Python 3.10, the `code.co_firstlineno`
is now always 1, whereas previously it was equal to the
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 17. 02. 22 2:13, Eric Snow wrote:
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
