Changes by Yury Selivanov :
--
nosy: +brian.curtin
___
Python tracker
<http://bugs.python.org/issue20894>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +serhiy.storchaka
___
Python tracker
<http://bugs.python.org/issue28782>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Wow, Martin, this is a very interesting one. Thanks so much for tracking this
down and reducing the test case.
So far this doesn't seem to be related to async/await: the interpreter stack
seems to enter some strange state under some conditions, and
Yury Selivanov added the comment:
> f_lasti being -2 has always been my preference, lasti.patch lgtm
How about we commit pygen_yf.patch to 3.6 and whatever else in 3.7?
lasti.patch is too invasive for 3.6 at this point, -1 for it in
Yury Selivanov added the comment:
LGTM
--
___
Python tracker
<http://bugs.python.org/issue28782>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Nick, your patch LGTM. I'd only add to the getargspec section that
getfullargspec is usually a drop-in replacement (I've yet to see code where
it's not the case).
--
___
Python tracker
<http
Yury Selivanov added the comment:
While I don't think that merging more than 256 dicts is a common task, the code
does become much simpler. LGTM.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
-1; we have too many opcodes already. Let's not complicate the code if there's
no performance improvement.
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.o
New submission from Yury Selivanov:
Right now, Python 3.6b4 happily accepts the following:
>>> f'{10:02\N{LATIN CAPITAL LETTER X}}'
'0A'
>>> f'{10:02X}'
'0A'
I think that the first line should not be accepted (as we n
Yury Selivanov added the comment:
Also this inconsistency: we already don't accept escaped letters after `!`:
>>> f'{min!\N{LATIN SMALL LETTER R}}'
File "", line 1
SyntaxError: f-string: invalid conversion c
Yury Selivanov added the comment:
Would be nice to have in 3.6.
--
___
Python tracker
<http://bugs.python.org/issue26273>
___
___
Python-bugs-list mailin
New submission from Yury Selivanov:
When a coroutine wrapped in a C asyncio.Task raises an Exception, the Task
fails to correctly save the __traceback__.
--
assignee: yselivanov
components: asyncio
files: task_tb.patch
keywords: patch
messages: 282092
nosy: gvanrossum, inada.naoki
Yury Selivanov added the comment:
Thanks for reviewing the patch, Inada-san. Closing the issue.
--
priority: release blocker -> normal
resolution: -> fixed
stage: -> resolved
status: open -> closed
type: -> behavior
___
Python
Yury Selivanov added the comment:
Hi Eric, please feel free to go ahead and submit a patch, I'll review it!
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
I'll take a look at s1 later tonight
--
___
Python tracker
<http://bugs.python.org/issue28885>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
Eric, are you working on a patch? If not, I'll be focusing on this myself in
the next couple of days.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Friday is good, take your time!
--
___
Python tracker
<http://bugs.python.org/issue28091>
___
___
Python-bugs-list mailin
New submission from Yury Selivanov:
Originally reported in http://bugs.python.org/issue28885#msg282538
Ned, please take a look at the attached patch. While I think that the change
is quite small & safe to merge, I think it's OK if we push this only in 3.6.1.
It's a
Yury Selivanov added the comment:
I created an issue to track S1: http://bugs.python.org/issue28893
--
___
Python tracker
<http://bugs.python.org/issue28
Yury Selivanov added the comment:
Please don't merge this without my review.
--
___
Python tracker
<http://bugs.python.org/issue26110>
___
___
Python-bugs-l
Yury Selivanov added the comment:
Ned, sounds good.
Serhiy, we don't have _PyErr_FormatFromCause in 3.5, so I'll probably commit
the patch as is in 3.5. For 3.6 is definitely makes sense to use
_PyErr_FormatFromCause.
--
___
Python trac
Yury Selivanov added the comment:
> I'm not sure if this is a bug, or this is intentional and the finalizer
> mechanism should be optional. If it is the latter should PEP525 get updated?
This is intentional, PEP 525 is slightly outdated. I'll update it right now.
Thanks fo
Yury Selivanov added the comment:
fix:
https://github.com/python/peps/commit/3e23210fe3aebefb269436e16246f63e1f006291
--
___
Python tracker
<http://bugs.python.org/issue28
Yury Selivanov added the comment:
> 1. In PEP525 the documentation for aclose() is a bit terse and unclear to me.
> It appeared to suggest that you could catch GeneratorExit and yield, but I
> found this to result in a RuntimeError like a normal generator. I tried to
> documen
Yury Selivanov added the comment:
Eric, I've left you some review comments.
Guido, Nick, I have a question I hope you have an opinion on: for synchronous
generators we define the following (sometimes confusing) terminology:
- "generator" = generator function
- "generator i
Yury Selivanov added the comment:
> It sounds particularly confusing that an "[XXX] generator" is the function
in one case and the object in the other case.
Right, this is the biggest argument against having slightly different
terminology between async generators and sync generato
Yury Selivanov added the comment:
> I was going to say "no", but given that "yield" works, I think it is
reasonable to allow "await" as well. (And what about "yield from"?)
Agree.
I suspect the reason is that async/await aren't proper keywords in
Yury Selivanov added the comment:
Guido, Nick,
OK, let's keep using the current terminology.
Eric,
Will you have time to make a new version of the patch (addressing the review
comments)?
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Yury, look good to you?
Yes; committed the patch with a small addition. Thanks, Mariatta!
--
resolution: -> fixed
stage: commit review -> resolved
status: open -> closed
___
Python tr
Yury Selivanov added the comment:
Oh, this is a release blocker. I'll take a look later today.
--
___
Python tracker
<http://bugs.python.org/issue28963>
___
___
Yury Selivanov added the comment:
I think the bug is only in _asyncio_Future_remove_done_callback, since
future_schedule_callbacks makes a slice first, which cannot be mutated.
I'm attaching a patch. Inada, would you be able to take a look?
--
keywords: +patch
nosy: +ned.
Yury Selivanov added the comment:
Inada-san, when I tested the patch last time, I think there was a regression
somewhere, related to the descriptor protocol. Have you fixed that one?
--
___
Python tracker
<http://bugs.python.org/issue26
Yury Selivanov added the comment:
> Inada-san, when I tested the patch last time, I think there was a regression
> somewhere, related to the descriptor protocol. Have you fixed that one?
Seems to be either fixed, or maybe those bugs were related to my opcode cache
patch. Anyways, I d
Yury Selivanov added the comment:
> I believe that I addressed all the comments in the previous review (although
> its always possible I missed something), and have a new patch with the
> improvements and fixes.
Thanks Eric! I've left a few more comments in the review. Almo
Yury Selivanov added the comment:
Inada-san, thanks for the review. You're right, we need to fix another
edge-case. I'll upload a new patch tomorrow.
Victor, fourth option we should go with is to commit the attached patch (with
Inada-san review comment fixed).
I guess it's
Yury Selivanov added the comment:
Pushed. Thanks a lot, Eric, very good job! (BTW, please enable trailing
whitespace trimming in your editor)
Ned, maybe you want to cherry-pick this commit to 3.6.0, but I guess most
people just use docs.python.org, so it's not that impo
Yury Selivanov added the comment:
Closing this one, the issue was resolved as part of #28091.
--
priority: deferred blocker -> normal
resolution: -> fixed
stage: needs patch -> resolved
status: open -> closed
superseder: -> D
Changes by Yury Selivanov :
--
title: Document PEP 525 -> Document PEP 525 & 530
___
Python tracker
<http://bugs.python.org/issue28091>
___
___
Python-bugs
New submission from Yury Selivanov:
Resolved: https://github.com/python/asyncio/issues/472
--
assignee: yselivanov
components: asyncio
messages: 283413
nosy: gvanrossum, larry, ned.deily, yselivanov
priority: release blocker
severity: normal
status: open
title: asyncio SSL hangs if
Changes by Yury Selivanov :
--
Removed message: http://bugs.python.org/msg283413
___
Python tracker
<http://bugs.python.org/issue28990>
___
___
Python-bugs-list m
New submission from Yury Selivanov:
Upstream link: https://github.com/python/asyncio/pull/476
--
___
Python tracker
<http://bugs.python.org/issue28990>
___
___
Yury Selivanov added the comment:
Ned, would you be able to cherry-pick this in 3.6.0? Guido approved this.
--
resolution: -> fixed
stage: -> resolved
type: -> behavior
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Closing this one, as we decided to not to micro-optimize int ops.
--
resolution: -> wont fix
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
I think we should close this one. Making concurrent.futures awaitable will
likely only complicate things for end-users.
--
resolution: -> wont fix
stage: -> resolved
status: open -> closed
___
Pytho
Yury Selivanov added the comment:
> As far as I look quickly, #10401 uses namei as cache key
and this patch uses opcode index as cache key, am I right?
Correct. Actually, if you don't mind, I'd like to update the patch myself. I
have a few ideas how to restructure it and ad
Yury Selivanov added the comment:
I've added a couple of review comments. Also, it looks like you can count
Antoine Pitrou as +1 too.
Two questions:
1. length or count? Need to look through builtins/stdlib and see what is more
common in CPython.
2. Maybe we should make length/coun
Yury Selivanov added the comment:
> This is just a two-liner:
>
>with memoryview(bytelike) as m:
>bs = bytes(m[start:end])
Which virtually no one follows :(
> Adding new method to builtin type has high bar. I doubts that there are
> enough use cases in whic
New submission from Yury Selivanov:
Quoting Alberto Berdi from python-tulip mailing list:
working with the Python 3.6 asyncio implemented in C, i've got what is
for me a strange behavior of the asyncio.Task.current task
function. Executing the following test:
import asyncio
async def
Changes by Yury Selivanov :
--
keywords: +patch
nosy: +inada.naoki
Added file: http://bugs.python.org/file46284/task.patch
___
Python tracker
<http://bugs.python.org/issue29
Yury Selivanov added the comment:
> * Allow passing arguments as keywoards: str.replace(old='a', new='b')
I think Guido explicitly stated that he doesn't like the idea to always allow
keyword arguments for all methods. I.e. `str.find('aaa')` just re
Yury Selivanov added the comment:
Ethan, thanks for moving my reply on the list to here. Also +1 to what Mark
said.
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue29
Yury Selivanov added the comment:
Signature object provides methods like .bind(), which will be hard to define if
a function has many signatures. Also, inspect.signature currently returns one
Signature object, that shouldn't be changed.
Wouldn't it be easier instead of this:
Yury Selivanov added the comment:
Hi Emily! Python 2.7 is in a maintenance-only mode at this point and mostly
receives security-related patches. The problem with accepting other kind of
patches is that we want 2.7 to be super stable.
You can continue working on this bug anyways, once the
Yury Selivanov added the comment:
Christian, how did you find this (i.e. what module/package is broken because of
this)? I'm still not entirely sure that raising EBADF in socket.close() is a
good thing.
--
nosy: +yselivanov
___
Python tr
Yury Selivanov added the comment:
Great. Can you share the Richards benchmark results? It specifically stresses
class instantiation, so we should be able to see the improvement.
--
___
Python tracker
<http://bugs.python.org/issue29
Yury Selivanov added the comment:
I think the original idea was to document that all methods of the loop are
coroutines, so that:
1. if a user needs a Future object they call ensure_future:
fut = asyncio.ensure_future(loop.method())
2. it gives us ability to refactor things. For instance
Yury Selivanov added the comment:
Emily, if you have time and want to help us with the inspect module, we have
many other unresolved issues. I'd be happy to help you with code reviews etc.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Maybe we should switch all these to "awaitable"?
I like this! Would it be OK to add a new sphinx declaration? So that:
.. coroutinemethod:: AbstractEventLoop.shutdown_asyncgens()
would become:
.. awaitable:: AbstractEventLoop.shutd
Yury Selivanov added the comment:
> Yury, I'm more than happy to help! I've spent a decent amount of time
> learning about code objects, byte code, etc. and I'd love to put that
> knowledge to use. Let me know the best way to find these issues on the
> tracker or ot
Yury Selivanov added the comment:
> Is it safe to use the _callback and _args attributes of asyncio.Handle? Is it
> possible to officially expose them as public API?
I'd be -1 on exposing them. Alternative asyncio event loop implementations
such as uvloop don't have those
Yury Selivanov added the comment:
> @yselivanov I just wanted to use the handler to avoid storing the callback
> and args in my own data structure (I would just store the handlers whenever I
> may need to reschedule). Not a big deal, I don't have to use handler as a
> stora
Yury Selivanov added the comment:
> * Add _PyMethodDescr_FastCallKeywords and call it in call_function.
This option seems to be the easiest to implement.
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
patch looks good to me.
--
___
Python tracker
<http://bugs.python.org/issue29507>
___
___
Python-bugs-list mailing list
Unsub
Yury Selivanov added the comment:
I will in a couple of days.
--
___
Python tracker
<http://bugs.python.org/issue28963>
___
___
Python-bugs-list mailing list
Unsub
Yury Selivanov added the comment:
> In formulating my question for the list, it occurred to me that while
> asynccontextmanager doesn't need to depend on asyncio, the AsyncExitStack
> proposed in issue 29302 likely will, which pushes me towards
Yury Selivanov added the comment:
Alexander,
You don't need asyncio.isocoroutinefunction. Please use
inspect.iscoroutinefunction and inspect.iscoroutine.
Nick,
I'm +1 to have a separate class AsyncExitStack.
> - assume everything passed to it is a coroutine or an async co
Yury Selivanov added the comment:
Looking at the code: we don't need to use iscoroutinefunction at all. If we
had separate methods for sync and async context managers, you can store the
flag if a function is async or sync along with it.
So _exit_callbacks should store tuples `(is_asyn
New submission from Yury Selivanov:
Proxy for https://github.com/python/asyncio/pull/497
Ned, this needs to be in 3.6.1, working code from 3.4 doesn't work in 3.6.0:
http://stackoverflow.com/questions/42546099/python-asyncio-migrate-from-3-4-to-3-5/42566336#42566336
--
ass
Changes by Yury Selivanov :
--
resolution: -> fixed
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue29703>
___
___
Python-bugs-list
Changes by Yury Selivanov :
--
pull_requests: +336
___
Python tracker
<http://bugs.python.org/issue29703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> OK. I assume you will make PRs for python/cpython and cherry-pack to the 3.6
> and 3.5 branches?
Yes, working on it!
--
___
Python tracker
<http://bugs.python.org/i
Changes by Yury Selivanov :
--
components: +asyncio
nosy: +gvanrossum
resolution: fixed ->
status: closed -> open
___
Python tracker
<http://bugs.python.org/i
Changes by Yury Selivanov :
--
pull_requests: +338
___
Python tracker
<http://bugs.python.org/issue29271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +339
___
Python tracker
<http://bugs.python.org/issue28893>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +340
___
Python tracker
<http://bugs.python.org/issue28963>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
Can you guys create a PR on github.com/python/cpython?
--
___
Python tracker
<http://bugs.python.org/issue29406>
___
___
Pytho
Changes by Yury Selivanov :
--
pull_requests: +341
___
Python tracker
<http://bugs.python.org/issue29703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +342
___
Python tracker
<http://bugs.python.org/issue29703>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +344
___
Python tracker
<http://bugs.python.org/issue29271>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +345
___
Python tracker
<http://bugs.python.org/issue28893>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> so it would need to split any code using "async def" and "await" out to a
> separate file that only gets imported on 3.5+ (and similarly only run the
> corresponding test cases on 3.5+).
This seems doable. I'd only vote to
Yury Selivanov added the comment:
New changeset dea5101ae101aefed14de98e6bb1658f4cae8712 by Yury Selivanov in
branch '3.6':
bpo-28893: Set __cause__ for errors in async iteration protocol (#407)
https://github.com/python/cpython/commit/dea5101ae101aefed14de98e6bb165
Yury Selivanov added the comment:
New changeset 13802a3b11eb5202b16e464cbfb85c144f8581ce by Yury Selivanov in
branch '3.6':
bpo-29271: Fix Task.current_task and Task.all_tasks to accept None. (#406)
https://github.com/python/cpython/commit/13802a3b11eb5202b16e464cbfb85c
Changes by Yury Selivanov :
--
pull_requests: +347
___
Python tracker
<http://bugs.python.org/issue29704>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
pull_requests: +346
___
Python tracker
<http://bugs.python.org/issue29704>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
New changeset d8b72e4a0673c414120b029065dbe77055f12e82 by Yury Selivanov in
branch '3.6':
bpo-28963: Fix out of bound iteration in asyncio.Future.remove_done_callback/C
(#408)
https://github.com/python/cpython/commit/d8b72e4a0673c414120b029065dbe7
Yury Selivanov added the comment:
>According to https://www.python.org/dev/peps/pep-0492/#transition-plan, the
>intention was (is?) to make them keywords in 3.7. As of Feb 11, that had not
>happened yet. If and when it does, this issue will be taken care of.
I plan to do that in
Yury Selivanov added the comment:
pyptr2, can you reproduce this with latest asyncio (from
github.com/python/asyncio)?
--
___
Python tracker
<http://bugs.python.org/issue27
Yury Selivanov added the comment:
> Maybe the form requirements for Bluetooth addresses are different than for IP
> or ipv6? I guess the validation should be protocol-specific.
Right, I've just looked at the code [1]. We should return from _ipaddr_info if
family is not an AF_UNSP
Yury Selivanov added the comment:
>> Maybe the form requirements for Bluetooth addresses are different than for
>> IP or ipv6? I guess the validation should be protocol-specific.
>
> Right, I've just looked at the code [1]. We should return from _ipaddr_info
> if
Yury Selivanov added the comment:
Please don't commit this without my review.
--
___
Python tracker
<http://bugs.python.org/issue27172>
___
___
Python-bugs-l
Yury Selivanov added the comment:
Jelle, regarding your patch: it would probably be a good idea to only accept
".0"-like names for POSITIONAL_ONLY parameters. Since functions with
positional-only parameters can only be created in C, that should make
inspect.Parameter less error pro
Yury Selivanov added the comment:
> Yes, it feels ugly. I'd rather "fix" the source of the problem (the weird
> positional attribute name).
+1.
> I have no idea if argument clinic would be of any help here, I haven't looked
> at how these things come to be.
Yury Selivanov added the comment:
> I chatted to Brett Cannon about it, and we agree inspect should handle the
> implicit functions generated by the compiler, even if those signatures can't
> be expressed in normal Python code.
Can we make ".0" parameters positional
Yury Selivanov added the comment:
Nick, what do you think about this one?
I'm +1 to add this, but I'm not sure about the name for the argument. Do you
have better ideas, or "skip_bound_arg" is good enough?
--
nosy: +ncoghlan
__
Yury Selivanov added the comment:
> We definitely can't use a valid identifier in the code generator, since any
> valid identifier we used might shadow a nonlocal, global or builtin name (and
> the latter two cases aren't visible to the compiler at compile time).
I wasn
New submission from Yury Selivanov:
There is a small flaw in PEP 492 design -- __aiter__ should not return an
awaitable object that resolves to an asynchronous iterator. It should return an
asynchronous iterator directly.
Let me explain this by showing some examples.
I've discovered
Yury Selivanov added the comment:
> While I agree this needs to be fixed, one key piece of documentation needed
> will be to cover how to write an __aiter__ method that does the right thing
> on both 3.5.1 and 3.5.2+ (and also avoids the deprecation warning in the
> latter case).
Yury Selivanov added the comment:
It's a rather long & conservative process, but it will be easier for people to
migrate their code.
--
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
> Can you guys get this solid and checked in before then?
Will do my best. I'll update the patch soon with some code comments and docs.
--
___
Python tracker
<http://bugs.python.org
2001 - 2100 of 3136 matches
Mail list logo
