And I tried removing co_firstfileno in optimize branch.
https://github.com/larryhastings/co_annotations/pull/9
Microbenchmarks.
(https://gist.github.com/methane/abb509e5f781cc4a103cc450e1e7925d)
```
# co_annotations branch (63b415c3)
$ ./python ~/ann_test.py 3
code size: 229679 bytes
memory:
On Tue, Apr 20, 2021 at 4:24 PM Inada Naoki wrote:
>
> Just an idea: do not save co_name and co_firstlineno in code object
> for function annotations.
> When creating a function object from a code object, they can be copied
> from annotated function.
>
I created a pull request. It use
Just an idea: do not save co_name and co_firstlineno in code object
for function annotations.
When creating a function object from a code object, they can be copied
from annotated function.
I think co_name and co_firstlineno are preventing code object is
shared in compile time.
We can share only
El lun, 19 abr 2021 a las 14:17, Larry Hastings ()
escribió:
> On 4/19/21 1:37 PM, Ethan Furman wrote:
>
> On 4/19/21 10:51 AM, Larry Hastings wrote:
>
> Something analogous /could/ happen in the PEP 649 branch but currently
> doesn't. When running Inada Noki's benchmark, there are a total of
On 19/04/2021 22:01, Antoine Pitrou wrote:
Almost nobody uses -O. Optimizations that are enabled only in -O are
useless.
Data point: I use -O.¹ Not frequently, not usually, but I have a few
large² programs that I add features to from time to time and will
doubtless continue to do so. I
On 4/19/21 1:37 PM, Ethan Furman wrote:
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but
currently doesn't. When running Inada Noki's benchmark, there are a
total of nine possible annotations code objects. Except, each
function
On Mon, 19 Apr 2021 13:37:56 -0700
Ethan Furman wrote:
> On 4/19/21 10:51 AM, Larry Hastings wrote:
>
> > Something analogous /could/ happen in the PEP 649 branch but currently
> > doesn't. When running Inada Noki's benchmark,
> > there are a total of nine possible annotations code objects.
On 4/19/21 10:51 AM, Larry Hastings wrote:
Something analogous /could/ happen in the PEP 649 branch but currently doesn't. When running Inada Noki's benchmark,
there are a total of nine possible annotations code objects. Except, each function generated by the benchmark has a
unique name, and
Oops: where I said nine, I should have said, twenty-seven. 3-cubed.
Should have had my coffee /before/ posting. Carry on!
//arry/
On 4/19/21 10:51 AM, Larry Hastings wrote:
I noticed something this morning: there's another way in which Inada
Naoki's benchmark here
I noticed something this morning: there's another way in which Inada
Naoki's benchmark here is--possibly?--unrealistic.
As mentioned, his benchmark generates a thousand functions, each of
which takes exactly three parameters, and each of those parameters
randomly chooses one of three
Obviously that's a bug. Can you send me this test case? Anything
works--Github, private email, whatever is most convenient for you.
Thank you!
//arry/
On 4/16/21 11:22 PM, Inada Naoki wrote:
## memory error on co_annotations
I modifled py_compile to add `from __future__ import
On Sat, Apr 17, 2021 at 1:38 PM Guido van Rossum wrote:
>
> I'm not going to report results, but we could use mypy itself as an example
> real-world code base. Mypy is almost 100% annotated. It does not include
> `from __future__ import annotations` lines but those could easily be added
>
On 4/16/21 5:00 PM, Guido van Rossum wrote:
(3) Ditto run with Larry's branch (PEP 649, assuming it's on by
default there -- otherwise, modify the source by inserting the needed
future import at the top)
The co_annotations stuff in my branch is gated with "from __future__
import
On Fri, Apr 16, 2021 at 12:32 PM Larry Hastings wrote:
>
>
> Please don't confuse Inada Naoki's benchmark results with the effect PEP
> 649 would have on a real-world codebase. His artifical benchmark
> constructs a thousand empty functions that take three parameters with
> randomly-chosen
Please don't confuse Inada Naoki's benchmark results with the effect PEP
649 would have on a real-world codebase. His artifical benchmark
constructs a thousand empty functions that take three parameters with
randomly-chosen annotations--the results provides some insights but are
not
On Fri, Apr 16, 2021 at 5:28 PM Łukasz Langa wrote:
> [snip] I say "compromise" because as Inada Naoki measured, there's still a
> non-zero performance cost of PEP 649 versus PEP 563:
>
> - code size: +63%
> - memory: +62%
> - import time: +60%
>
>
> Will this hurt some current users of typing?
Thanks so much for this, I think it makes a lot of sense. You've saved me
by explaining why PEP 563 semantics are problematic for pydantic far more
articulately than I could have done.
I can entirely see why PEP 563 made sense at the time, myself (and others
in the "runtime use of annotations"
17 matches
Mail list logo
