Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Stefan,
Because of
https://mail.python.org/pipermail/python-committers/2015-May/003410.html I've
decided to commit 24315 and 24316 today. Please try to check that everything
works before new b
Yury Selivanov added the comment:
I think it should be changed to `pop(i=-1)`.
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24323>
___
___
Yury Selivanov added the comment:
Can we merge this patch before new beta2?
https://mail.python.org/pipermail/python-committers/2015-May/003410.html
--
___
Python tracker
<http://bugs.python.org/issue16
Yury Selivanov added the comment:
> Tried it, works for me. Thanks!
This is really good news! Thanks!
--
___
Python tracker
<http://bugs.python.org/issu
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 su
Yury Selivanov added the comment:
> I just noticed that I hadn't used the real "types.coroutine" in my Py3.5
> tests when reporting back in issue 24017.
Please test thoroughly the attached patch.
--
Added file: http://bugs.python.org/file39548/
Yury Selivanov added the comment:
Please test the attached patch.
> BTW, it's not only for compiled generators but also for normal Python
> functions that construct Python generators internally and return them
You're right, that's why I used "prima
Changes by Yury Selivanov :
--
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/issue24316>
___
___
Python-bugs-list
Yury Selivanov added the comment:
Updated patch. Wrapper now proxies gi_code, gi_running and gi_frame
--
Added file: http://bugs.python.org/file39555/types_coroutine.patch
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
> I'm attaching a patch that works for me.
Looks like we were working in parallel ;) I've incorporated your changes.
Please look at the new patch (hopefully this one is final)
--
Added file: http://bugs.python.org/file39557/types_co
New submission from Yury Selivanov:
The following code doesn't work. Would be great if we can fix it in 3.5
class Foo:
__slots__ = ('__qualname__',)
--
components: Interpreter Core
messages: 244410
nosy: pitrou, yselivanov
priority: normal
severity: normal
sta
Yury Selivanov added the comment:
Committed. Thanks, Stefan!
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/i
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: http://bugs.python.org
Yury Selivanov added the comment:
Stefan, please take a look at this issue #24325 too.
--
___
Python tracker
<http://bugs.python.org/issue24316>
___
___
Python-bug
Yury Selivanov added the comment:
> * Would this make it easy/faster to also have a DefaultOrderedDict (which
can/could also be accomplished with .get(attr, []) and .setdefault ?
Not in 3.5.
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
@Eric: I think you also want to commit it to 3.5
--
___
Python tracker
<http://bugs.python.org/issue16991>
___
___
Python-bug
Yury Selivanov added the comment:
What inspect.isgeneratorfunction(func) returns for Cython generators?
--
___
Python tracker
<http://bugs.python.org/issue24
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: fixed ->
status: closed -> pending
___
Python tracker
<http://bugs.python.org/issue24004>
___
___
Python-bugs-
Yury Selivanov added the comment:
Stefan,
> Then I guess we're back to the point where duck-typing and calling
> __await__() is a good idea.
Please test the attached patch. I agree this is a good idea.
--
keywords: +patch
Added file: http://bugs.python.org/file39569/coro
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 parti
Yury Selivanov added the comment:
> Why is the AwaitableABC type check needed, in addition to looking up the
> relevant method? IIUC, the type check will just do a lookup of the same
> method if the type hasn't been registered as Awaitable explicitly.
Because __await__ should
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: test needed -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24004>
___
___
Python-bugs-list
Yury Selivanov added the comment:
This was fixed in issue #23934
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
superseder: -> sphinx - building muppy docs fails on Linux
___
Python tracker
<http://
Yury Selivanov added the comment:
Serhiy, could you please commit it in 2.7?
--
___
Python tracker
<http://bugs.python.org/issue21853>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Thanks, Martin!
--
___
Python tracker
<http://bugs.python.org/issue24004>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24340>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov:
Consider following piece of code:
async def foo():
return 'spam'
def wrapper(coro):
async def wrap(coro):
print('before')
try:
return await coro
finally:
Changes by Yury Selivanov :
--
stage: -> patch review
title: coroutine wrapper recursion -> coroutine wrapper reentrancy
type: -> behavior
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
nosy: +jnoller
___
Python tracker
<http://bugs.python.org/issue24303>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> why wouldn't it be good enough in this case?
Because it's highly non-obvious, it took me a while to understand what's
*actually* going on.
--
___
Python tracker
<http://bugs.
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24349>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24348>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24347>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Thanks, Nick! I'll commit the patch with your error message (it's much better!)
--
___
Python tracker
<http://bugs.python.o
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24362>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +ncoghlan
stage: -> patch review
___
Python tracker
<http://bugs.python.org/issue24365>
___
___
Python-bugs-list mai
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue24366>
___
___
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Can this issue be closed now?
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24270>
___
___
Python-bug
New submission from Yury Selivanov:
Code to raise RuntimeError introduced in issue24342 has some refleaks. Please
review the attached patch.
--
assignee: yselivanov
components: Interpreter Core
files: set_coro.patch
keywords: patch
messages: 244749
nosy: ncoghlan, yselivanov
priority
Changes by Yury Selivanov :
--
nosy: +gvanrossum, haypo
___
Python tracker
<http://bugs.python.org/issue24374>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Yury Selivanov:
Attached (t.py) is a random script that I stumbled upon pretty randomly on the
internet -- someone used it to test different languages VMs performance.
The interesting thing is that 2.7 runs it 20-30% faster than 3.4 & 3.5
consistently. The script does
Yury Selivanov added the comment:
This is strange. On one of my gentoo boxes I'm having about the same
performance of 2.7.9 and 3.4.3.
On macos x, 2.7.10 is faster than 3.5.x (make distclean & ./configure & make).
I don't know if I shoul
Yury Selivanov added the comment:
Alright. I'm closing it, as it seems it's not obvious what's really going on
here. I'll try to profile it on my own later.
> (also, computing the Mandelbrot set using the CPython interpreter isn't a
> very good use case)
A
Yury Selivanov added the comment:
> Was __await__() deliberately left out of concurrent.futures.Future or was
> that an oversight? Or am I misunderstanding something?
I don't think concurrent.Future is supposed to be used with asyncio (in 'yield
from' o
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39611/set_coro.patch
___
Python tracker
<http://bugs.python.org/issue24374>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> Hmm, but IMHO a) the new syntax isn't just for asyncio and b) awaiting a
> Future seems like a *very* reasonable thing to do. I think opening a new
> ticket for this is a good idea.
Stefan, I honestly have bo idea what concurrent.Future.__aw
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Changes by Yury Selivanov :
--
assignee: yselivanov
components: Library (Lib), asyncio
nosy: gvanrossum, haypo, scoder, yselivanov
priority: normal
severity: normal
status: open
title: consider implementing __await__ on concurrent.futures.Future
type: enhancement
versions: Python 3.5
Yury Selivanov added the comment:
Guido, Stefen, please see issue24383.
--
___
Python tracker
<http://bugs.python.org/issue24017>
___
___
Python-bugs-list mailin
New submission from Yury Selivanov:
> Maybe it's possible to give an interpretation to awaiting on a threaded
> Future? __await__ could return a new asyncio Future, and add a completion
> callback to the original Future that makes the asyncio Future ready and
> transfers the
Changes by Yury Selivanov :
--
Removed message: http://bugs.python.org/msg244834
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> Yuri, is that possible?
Please see my previous comment and the attached patch :)
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
Added a unittest for cancellation
--
Added file: http://bugs.python.org/file39621/concurrent.patch
___
Python tracker
<http://bugs.python.org/issue24
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39622/concurrent.patch
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Alternative patch with monkeypatching instead of Future subclassing.
--
Added file: http://bugs.python.org/file39623/concurrent_alt.patch
___
Python tracker
<http://bugs.python.org/issue24
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39624/concurrent.patch
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
versions: -Python 3.5
___
Python tracker
<http://bugs.python.org/issue24383>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Nathan, consider the following signature:
def foo(a=0:''): pass
now, sig.parameters['a'].annotation will be '' and .default will be 0, and they
will fail 'if param.annotation or param.default' check.
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue13248>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
I think that the only proper way to solve this is to make coroutines a separate
type. I've actually prototyped that before:
https://github.com/1st1/cpython/commit/a3f1059590f496bf77b33edb023c8cdbc1d30798
--
assignee: -> yselivanov
co
Yury Selivanov added the comment:
I'll have a patch soon.
--
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list mailing list
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24411>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Please see the attached patch.
Couple of notes:
1. It adds a new type: 'coroutine' (PyCoro_Type). The implementation is still
heavily based on generators, there are no changes there.
2. Unfortunately, a new opcode needs to be added - GET_YIELD
Yury Selivanov added the comment:
Cleaned up the patch a little bit.
--
Added file: http://bugs.python.org/file39665/corotype.patch
___
Python tracker
<http://bugs.python.org/issue24
Changes by Yury Selivanov :
--
hgrepos: +312
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
One more patch fixing minor bug in types.coroutine + a unittest for that. The
patch should be ready for reviews.
--
Added file: http://bugs.python.org/file39666/corotype.patch
___
Python tracker
<h
Yury Selivanov added the comment:
Please find attached a new patch.
Stefan, while working on the patch, I (re-)discovered that __await__ for
coroutines should return an iterator that also implements '.send', '.throw',
and '.close', to comply with PEP 380 yie
Yury Selivanov added the comment:
Nick, Guido, I think we should commit this. While working on this I'm getting
more and more confident that it's the right thing to do. I like that
coroutines implement __await__ in the latest patch -- PEP 492 just now "clicks
Yury Selivanov added the comment:
> Nick Coghlan added the comment:
>
> A quick scan of which files have been modified suggests the new opcode
> still needs docs (although I think the PEP 492 docs in general are still
> pending, in which case, this could just be rolled into that
Yury Selivanov added the comment:
> (although I think the PEP 492 docs in general are still pending, in which
> case, this could just be rolled into that)
Actually most of pep 492 docs are merged already (including new opcodes) via
issue24180. They can be definitely improved though (I&
Yury Selivanov added the comment:
> All this checking for coroutine-ness feels very strange to me. It's
> anti-duck-typing: [..]
Why is it "anti-duck-typing"? Awaitable is an object that implements
__await__. With this patch coroutines are a separate type with __awai
Yury Selivanov added the comment:
On June 9, 2015 at 11:11:11 PM, Ben Darnell (rep...@bugs.python.org) wrote:
[..]
> The type of the callable matters for the types.coroutine decorator. In
> order to get a coroutine object instead of a generator object, I must apply
> types.corouti
Yury Selivanov added the comment:
> GeneratorWrapper helps, but it fails when applied to non-generator functions
> that return a value (while both tornado.gen.coroutine and asyncio.coroutine
> take pains to support such usage). The "raise TypeError" should be removed;
>
Yury Selivanov added the comment:
> With the two changes I described things appear to be working, although I've
> only done light testing so far.
Glad to hear that! I've attached a new patch fixing types.coroutine per your
request.
> More generally, the inconsistency
Yury Selivanov added the comment:
Nick, Stefan, Martin,
Please find an updated patch attached. All issues that you guys found (thanks
a lot for the reviews btw!) should be resolved.
--
Added file: http://bugs.python.org/file39720/corotype.patch
Yury Selivanov added the comment:
I think we need some feedback from PyPy & Jython guys on this. I'm not sure
that they can expose 'yieldfrom' slot without some performance penalties.
--
nosy: +yselivanov
___
Python tracker
<
Yury Selivanov added the comment:
Martin, thanks a lot for the feedback and patch! I'll review the patch when
issue24400 lands.
--
assignee: docs@python -> yselivanov
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org
Changes by Yury Selivanov :
--
nosy: +yselivanov
resolution: fixed ->
stage: resolved -> patch review
___
Python tracker
<http://bugs.python.org/i
Changes by Yury Selivanov :
--
assignee: -> yselivanov
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscrib
Changes by Yury Selivanov :
--
nosy: +arigo
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +fwierzbicki
___
Python tracker
<http://bugs.python.org/issue24450>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39722/corotype.patch
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39723/corotype.patch
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Another iteration of the patch is attached. Nick, I think it's ready for your
review.
--
stage: needs patch -> patch review
type: -> enhancement
Added file: http://bugs.python.org/file39729/cor
Yury Selivanov added the comment:
+1.
This, unfortunately, can't go in 3.5 (too late), but I can commit this in 3.6.
--
assignee: -> yselivanov
nosy: +yselivanov
versions: +Python 3.6 -Python 3.5
___
Python tracker
<http://bugs
Yury Selivanov added the comment:
Larry, is there any chance this can be committed in 3.5 (the change is fully
backwards compatible)?
--
nosy: +larry
___
Python tracker
<http://bugs.python.org/issue19
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39730/corotype.patch
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list m
Changes by Yury Selivanov :
--
assignee: -> yselivanov
components: +Library (Lib)
nosy: +yselivanov
versions: +Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
New patch is attached.
Updates:
1. Coroutine type now has 'cr_*' slots *both* in Python *and* in C.
2. set_coroutine_wrapper now works *only* on coroutines created by 'async def'
functions (generators wrapped with types.coroutine won&#
Yury Selivanov added the comment:
Nick, Larry, please take a look at the attached patch.
--
keywords: +patch
Added file: http://bugs.python.org/file39741/code.patch
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Hi Walter,
Thanks for reporting this. A patch is attached.
--
keywords: +needs review, patch
nosy: +larry, ncoghlan
stage: -> patch review
Added file: http://bugs.python.org/file39743/sig.patch
___
Python trac
Yury Selivanov added the comment:
Actually, I'm not sure that we should use 'cr_*' prefix instead of 'gi_*' for
coroutines.
Coroutines reusing generators machinery is a two-fold thing: on the one hand it
makes the implementation simpler; on the other -- __await__
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39745/corotype.patch
___
Python tracker
<http://bugs.python.org/issue24400>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> This isn't a bug, as "raise exc from None" only hides *display* of the
> context, it doesn't lose the record of the context entirely.
Agree. My patch, though, is still valid. I think removing try..except blocks
actually simpli
Yury Selivanov added the comment:
OK, let's go with cr_* prefix for coroutine type's slots.
Nick, there is one more thing I'd be glad to receive your input on. Currently,
inspect.iscoroutine(o) uses isinstance(o, abc.Coroutine) to do the check. Ben
and Stefan reasonably
2201 - 2300 of 3098 matches
Mail list logo
