Yury Selivanov added the comment:
Closing this one now--there's no point in speeding up types.coroutine anymore.
--
resolution: -> rejected
stage: patch review -> resolved
status: open -> closed
___
Python tracker
Mark Shannon added the comment:
If type.coroutine is not the first and only decorator, then things may be even
worse.
Code objects are currently immutable.
This change would mean that a call to types.coroutine in one place in the code
would change the semantics of another piece of code in a
Stefan Behnel added the comment:
the undecorated form will never be visible to any code other than the
decorator
Assuming that 1) it's the first and/or only decorator, 2) it's used to
decorate a generator function that returns its own generator and 3) it's
really used as a decorator and not
Mark Shannon added the comment:
Does this have a measurable performance impact?
I'd be surprised if it did.
W.r.t. to profiling, the undecorated form will never be visible to any code
other than the decorator, so won't show up in the profiler.
--
nosy: +Mark.Shannon
Stefan Behnel added the comment:
This is not purely about speeding up the code. It's also about avoiding to
replace the code object of a function, which is essentially a big and clumsy
hack only to achieve setting a flag. Some tools, namely line_profiler, use the
current code object as a dict
Larry Hastings added the comment:
Oh, wait, I was confusing myself. This is that new module you guys created for
type hints, and this is a new object with no installed base. (Right?)
Yeah, you can check it in for 3.5.
--
___
Python tracker
Yury Selivanov added the comment:
Oh, wait, I was confusing myself. This is that new module you guys created
for type hints, and this is a new object with no installed base. (Right?)
No, you were right in your previous comment...
Help me to understand here. You want to check in a patch
Larry Hastings added the comment:
Help me to understand here. You want to check in a patch adding 300 new lines
of C code to the types module during beta, for a speed optimization, after
we've already hit beta?
While I like speedups as much as the next guy, I would be happier if this
waited
Roundup Robot added the comment:
New changeset eb6fb8e2f995 by Yury Selivanov in branch '3.5':
Issue #24325, #24400: Add more unittests for types.coroutine; tweak wrapper
implementation.
https://hg.python.org/cpython/rev/eb6fb8e2f995
New changeset 7a2a79362bbe by Yury Selivanov in branch
Roundup Robot added the comment:
New changeset 9aee273bf8b7 by Yury Selivanov in branch '3.5':
Issue #24400, #24325: More tests for types._GeneratorWrapper
https://hg.python.org/cpython/rev/9aee273bf8b7
New changeset fa097a336079 by Yury Selivanov in branch 'default':
Merge 3.5 (issue #24325
Yury Selivanov added the comment:
I've committed new unittests from this patch (as they are applicable to pure
Python implementation of the wrapper too)
The patch now contains only the C implementation of the wrapper and should be
ready to be committed. Larry?
--
Added file:
Changes by Yury Selivanov yseliva...@gmail.com:
--
nosy: +asvetlov, haypo, vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24325
___
___
Nick Coghlan added the comment:
+1 from me for merging this for 3.5.0 and deferring issue 24468 (which now
proposes making _opcode a builtin module to allow compiler constants to be
easily shared between C code and Python code) to 3.6 instead.
The design changes to address issue 24400 cleaned
Yury Selivanov added the comment:
Larry, Nick,
Looking at how issue24400 progresses, I think it would be really great if we
can merge this one in 3.5.0. It also makes it unnecessary to merge issue24468
in 3.5.
--
dependencies: +Awaitable ABC incompatible with
Changes by Arfrever Frehtes Taifersar Arahesis arfrever@gmail.com:
--
nosy: +Arfrever
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24325
___
Yury Selivanov added the comment:
Larry, can you accept the first version of the patch (only function that
patches code object's co_flags) after beta2?
I'm OK if you think it should only be committed in 3.6, but I also agree with
Stefan, that using C is better in this particular case.
Larry Hastings added the comment:
This looks big and complicated. I'd prefer this skipped 3.5 and just went into
3.6.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24325
___
Guido van Rossum added the comment:
Since it's a speedup it could also go into 3.5.1.
On May 30, 2015 1:22 PM, Yury Selivanov rep...@bugs.python.org wrote:
Yury Selivanov added the comment:
Larry, can you accept the first version of the patch (only function that
patches code object's
Stefan Behnel added the comment:
I would still like to see a patch in Py3.5 that only flips the bit in C when
_types is available and otherwise falls back to the existing Python code that
creates a new code object. This part is much cleaner and faster to do in C than
in the current Python
New submission from Yury Selivanov:
Attached patch provides an implementation (part of it) of types.coroutine in C.
The problem with the current pure Python implementation is that it copies the
code object of the generator function, which is a small overhead during import.
I'm not sure if
Changes by Serhiy Storchaka storch...@gmail.com:
--
nosy: +larry
type: - enhancement
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24325
___
___
Yury Selivanov added the comment:
Attached is the second iteration of the patch. Now, besides just speeding up
types.coroutine() for pure python generator functions, it also provides a
better wrapper around generator-like objects.
--
nosy: +scoder
Added file:
22 matches
Mail list logo