Yury Selivanov added the comment:
Thanks, Łukasz!
--
___
Python tracker
<http://bugs.python.org/issue27223>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
type: -> behavior
___
Python tracker
<http://bugs.python
Yury Selivanov added the comment:
I'm merging David's patch. I concur with David that the only viable way to fix
this is to loop through the CancelledError until the lock is acquired (and
Condition is in a right state).
Thanks, David. It should make it to 3.5.2 now.
--
Yury Selivanov added the comment:
> Yury's raises a RuntimeError in the loop situation.
> Serhiy's simply reorders the exception context to put the referred to one at
> the front of the chain in the event of a loop.
Right, and I believe that my solution is more Pythonic
Yury Selivanov added the comment:
> issue27122_broken_cm.py also shows why I think "make it work" is the right
> answer here [..]
But fixing this issue by reordering the exception chain will only mask bugs
that just better to be fixed. And sometimes, this will cause weird ex
Yury Selivanov added the comment:
> @Yury, any comments? The fix looks fine to me.
I've left a comment in code review. Other than that, the patch/approach looks
good.
--
___
Python tracker
<http://bugs.python.org
Yury Selivanov added the comment:
> On Jun 26, 2016, at 12:05 PM, Jim Fulton wrote:
>
> I've switched my code to use create_server, but this has led to stability
> problems.
BTW, did you try to run ZEO tests on uvloop? I'm just curious if stability is
somehow related
Yury Selivanov added the comment:
> yuri, did you saw guido added review on your patch?
Yes. There are few more issues with the patch that I want to resolve before
re-submitting it for another review. Will do it soon.
--
___
Python tracker
&l
Yury Selivanov added the comment:
> SSL contexts, https://docs.python.org/3/library/ssl.html#ssl-contexts,
have an attribute, check_hostname, which controls whether hostname checking is
required. If set to false in a context passed to create_connection, then it
makes no sense to requ
Yury Selivanov added the comment:
> However, IMO, it's useful to be able to accept a connection outside of an
> asyncio event loop and then hand the loop the connected socket.
Looks like what you're asking for is a way to wrap existing socket object into
a (transport, protoco
Yury Selivanov added the comment:
> Yury, I'm curious what you think the socket argument to create_connection is
> about.
:) The current intended purpose of create_connection is to create a client
connection. You're proposing to add a new argument -- server_side -- whi
Yury Selivanov added the comment:
Jim, I think you wanted to post this link in this issue:
https://bugs.launchpad.net/zodb/+bug/135108/comments/9 instead of in #27392.
I can reproduce this on my mac, but so far I've no idea what'
Yury Selivanov added the comment:
Running out of time to debug this today. I think this is a bug in CPython, in
either socket or select module. When I inject some debug code in selectors.py
and replace KQueue with select(), I can see that the server thread's selector
stops working at
Yury Selivanov added the comment:
> It also doesn't occur with uvloop, which I assume still uses sockets.
No, uvloop doesn't use python sockets or select for IO at all. All IO is done
in libuv.
> WRT CPython/sockets this problem doesn't happen if I use asyncore to acce
Yury Selivanov added the comment:
> Rather tham monkey-patching, in general I recommend just copying some
code from the asyncio library and calling that. In this case you'd be
copying a tiny bit of code from create_connection(). You'd still be
calling an internal API, _make_ssl_tra
Yury Selivanov added the comment:
See also https://github.com/python/asyncio/issues/286
I also wanted to raise this question. I think transports should set NODELAY by
default (as Golang, for instance). I've been hit by this thing a few times
already -- performance of protocols over T
Yury Selivanov added the comment:
Jim, I can make a PR, unless you want to do that.
--
___
Python tracker
<http://bugs.python.org/issue27456>
___
___
Python-bug
Yury Selivanov added the comment:
> Is there a similar update that can be made to uvloop?
Yes. Once it's committed to asyncio, I'll add it to uvloop immediately.
That's one benefit of using uvloop -- it gets updates faster ;)
--
Yury Selivanov added the comment:
PR: https://github.com/python/asyncio/pull/373
--
___
Python tracker
<http://bugs.python.org/issue27456>
___
___
Python-bug
Yury Selivanov added the comment:
> wrap_socket implies that it's for wrapping client or server sockets, but it's
> not. It's only for handling server sockets. Also, I prefer a name that
> reflects goal, not mechanism.
> I think the name should be di
Yury Selivanov added the comment:
> I'm working on this. Some bugs are fixed, but doesn't pass tests for now.
Thanks a lot! I couldn't find time to finish this myself. I can definitely
help you and review the patch once it's ready.
> Yury, could you explain what
Yury Selivanov added the comment:
> How about we use connect_socket() or a variant on that name? That feels
> similar to connect_{read,write}_pipe(), which also take a protocol_factory
> and an already-opened I/O object.
I like the idea to use "connect_" prefix here
Yury Selivanov added the comment:
> Before working on it, could someone give me idea to run whole test_asyncio
with and without C version Future easily?
asyncio uses loop.create_future() to create sockets. I'd suggest you to create
two base test classes: one that monke
Yury Selivanov added the comment:
Let's keep this issue open until we have the docs updated.
--
___
Python tracker
<http://bugs.python.org/issue27392>
___
___
Yury Selivanov added the comment:
Jim, the patch lgtm. Will merge it soon.
--
assignee: -> yselivanov
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
I guess someone has to step forward -- i can propose an initial patch with the
tutorial.
--
___
Python tracker
<http://bugs.python.org/issue27
Yury Selivanov added the comment:
Yes. Most people will use vanilla asyncio anyways.
--
___
Python tracker
<http://bugs.python.org/issue26081>
___
___
Python-bug
Yury Selivanov added the comment:
> Can you prove that packets may be lost even in UNIX sockets ?
> (it is not related to this task directly)
Quoting wiki:
"""Like named pipes, Unix domain sockets support transmission of a reliable
stream of bytes (SOCK_STREAM, compare
Yury Selivanov added the comment:
> A proper solution IMO should somehow merge the selectors so that a
> single select() or whatever wakes up when either network I/O happens
> or a UI event comes in (which could be something that Tk transparently
> handles but it still needs to
Yury Selivanov added the comment:
I think we should fix this. BaseEventLoop is just an implementation detail of
asyncio (I think we shouldn't have exposed it in asyncio.__all__ at all).
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Did the patch not get merged??
connect_accepted_socket was merged. The docs patch is still pending (nothing
wrong with it, I just need to commit it)
--
___
Python tracker
<http://bugs.python.org/issu
Yury Selivanov added the comment:
The patch looks good.
I have a question: do we actually want to document BaseEventLoop? It's not a
user-facing class, and the knowledge that it exists doesn't add to anything IMO.
--
___
Python trac
Yury Selivanov added the comment:
Fair enough. I don't have any other questions about the patch.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
Hm, I'm working on adding connect_accepted_socket to the uvloop. There is one
difference between connect_accepted_socket and
create_server/create_unix_server: the latter APIs forbid to pass boolean `ssl`
argument, they require `ssl` to be an instan
Yury Selivanov added the comment:
Also I think we should add a check, that the passed socket is AF_UNIX or
AF_INET(6)
--
___
Python tracker
<http://bugs.python.org/issue27
Yury Selivanov added the comment:
> What would happen if some other socket type was passed? Would anything go
wrong, assuming it's a socket type that understands connections? (I think
checking for SOCK_STREAM is more important maybe).
In uvloop I have to create different libuv han
Yury Selivanov added the comment:
> Yury, could you review this before 3.6a4?
Left a couple of comments; the important one -- Future.__await__ (and
Future.__iter__) should always return a *new* instance of a generator-like
object (tied to the Future obj
Yury Selivanov added the comment:
> What parts of Future are performance critical? Maybe it is worth to implement
> in C only the most critical code.
Basically everything. Contrary to @contextmanager, Futures are the building
blocks of asyncio, so instantiation + awaiting on them + s
Yury Selivanov added the comment:
> WRT boolean for SSL, I think it's very common for clients to verify server
> certificates, but relatively uncommon for servers to require client
> certificates. The impression I have from reading docs and stack overflow
> posts that th
Yury Selivanov added the comment:
I'd also think about implementing asyncio.Handle in C (with a freelist).
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Implementing full behavior of generator seems difficult to me.
I'll implement minimum implementation in next patch.
Sure, but you have to implement send() and throw().
--
___
Python tracke
Yury Selivanov added the comment:
I think that Victor is right, it would be better to have two distinct entries
in the docs. Besides that - LGTM.
--
___
Python tracker
<http://bugs.python.org/issue22
Yury Selivanov added the comment:
I think we should just fix the documentation, and update the code in example
with a proper check:
for param in sig.parameters.values():
if (param.name not in ba.arguments
and param.default is not param.empty):
ba.arguments[param.name
Yury Selivanov added the comment:
> - modify tests to set the event loop to the newly created event loop, instead
> of setting it to None
I'm not sure that this particular change is a great idea. I kind of liked that
unittests ensure that loop is passed everywhere explicitly
Yury Selivanov added the comment:
> Should this be closed now?
Yes, let's close it.
David and Walter, you're welcome to re-open the issue if you want to discuss it
in more detail.
--
resolution: -> wont fix
status: open -> closed
___
Yury Selivanov added the comment:
Hi Victor,
I left you some feedback in code review.
I'm kind of leaning towards your proposal that we should force users to always
use safe API. But I also understand Guido's point.
--
___
Python trac
Yury Selivanov added the comment:
Patch attached. Tests pass on Linux.
--
keywords: +patch
Added file: http://bugs.python.org/file37387/epoll_01.patch
___
Python tracker
<http://bugs.python.org/issue23
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file37388/epoll_02.patch
___
Python tracker
<http://bugs.python.org/issue23009>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
I agree. Please see another one.
--
___
Python tracker
<http://bugs.python.org/issue23009>
___
___
Python-bugs-list mailin
Yury Selivanov added the comment:
> Please add a comment explaining the complaint from epoll.poll() we're
trying to avoid here.
Good point! Committed.
--
___
Python tracker
<http://bugs.python.org
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue23009>
___
___
Yury Selivanov added the comment:
@Claudiu, you should also add this test and make sure that it passes:
class Parent:
__doc__ = 'some documentation'
class Child(Parent):
__doc__ = None
assert getdoc(Child) is None
In other words -- we use __doc__ defined
Yury Selivanov added the comment:
Thank you for the patch, Claudiu!
--
nosy: +yselivanov
resolution: -> fixed
stage: patch review -> 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/issue1218234>
___
___
Python-bugs-
Yury Selivanov added the comment:
Fixed in 3.5. Not sure if we need to backport this to 3.4 and 2.7.
Closing this issue. Thanks to Björn Lindqvist and Berker Peksag!
--
___
Python tracker
<http://bugs.python.org/issue1218
Yury Selivanov added the comment:
@Jason: done ;)
--
___
Python tracker
<http://bugs.python.org/issue1218234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
versions: -Python 3.4
___
Python tracker
<http://bugs.python.org/issue19903>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
I'd like to see PEP 468 explicitly rejected or postponed till 3.6 before we
make this change in 3.5.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> What do you think of this feature? Does it make sense to expose (internally)
> the "handle currently executed"?
I think it's OK to have something like `loop._current_handle` to work ~only~ in
debug mode. Enhancing `loop.call_excepti
Yury Selivanov added the comment:
> rather, it *is* passing now :)
Eric, thanks for working on this! Could you please go through your patch and
replace "//" comments with "/* .. */" ones? It would also be great if you can
Changes by Yury Selivanov :
--
priority: normal -> deferred blocker
___
Python tracker
<http://bugs.python.org/issue21998>
___
___
Python-bugs-list mai
Yury Selivanov added the comment:
> Other solution is to change Tools/scripts/generate_opcode_h.py to generate a
> file without trailing spaces.
I like this option. I saw the whitespace, but I usually don't touch
autogenerated files, so I naturally thought that someone has m
Yury Selivanov added the comment:
> How do other event loops handle fork? Twisted, Tornado, libuv, libev,
libevent, etc.
It looks like using fork() while an event loop is running isn't recommended in
any of the above. If I understand the code correctly, libev & gevent
reinitial
Yury Selivanov added the comment:
> I think only (3) is reasonable -- raise RuntimeError.
Just to be clear -- do we want to raise a RuntimeError in the parent, in the
child, or both processes?
--
___
Python tracker
<http://bugs.pyth
Yury Selivanov added the comment:
> I was thinking only in the child. The parent should be able to continue to
> use the loop as if the fork didn't happen, right?
Yes, everything should be fine.
I'll rephrase my question: do you think there is a way (and need) to at least
th
Yury Selivanov added the comment:
> I don't understand. If the fork fails nothing changes right? I guess I'm
> missing some context or use case.
Maybe I'm wrong about this. My line of thoughts is: a failed fork() call is a
bug in the program. Now, the master process wi
Yury Selivanov added the comment:
> That's really the problem of the code that calls fork(), not directly of
> the event loop. There are some very solid patterns around that (I've
> written several in the distant past, and Unix hasn't changed that much :-).
Alrigh
Yury Selivanov added the comment:
> I would therefore, in the child after a fork, close the loop without
> breaking the selector state (closing without unregister()'ing fds), unset
> the default loop so get_event_loop() would create a new loop, then raise
> RuntimeError.
&g
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue16500>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
lgtm
--
___
Python tracker
<http://bugs.python.org/issue24288>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
timemodule.c no longer compiles on MacOSX:
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv
-O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include
-I. -IInclude -I/usr/local/include -I/Users/yury/dev/py
Yury Selivanov added the comment:
Attached is a new unittest to make sure that symbol.py is always updated.
Essentially it's the same test that we have for keywords.py. Please review.
--
assignee: -> yselivanov
keywords: +patch
nosy: +yselivanov
stage: -> patch revi
Yury Selivanov added the comment:
This exact sequence of commands
$ make clean
$ ./configure
$ make -j8
does not build.
--
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
$ hg status
shows nothing, branch is default (but 3.5 doesn't get built either) etc.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
But why was it building just fine before this commit? I haven't updated my
system packages in a while.
--
___
Python tracker
<http://bugs.python.org/is
Yury Selivanov added the comment:
> Wild guess: perhaps you did a ./configure or the Makefile did an implicit
> call to configure recently and/or you did a make install (to /usr/local)
> before?
I don't have 'python' in /usr/
Yury Selivanov added the comment:
yury@ysmac ~/dev/py/cpython (HG: default?) $ ls /usr/local/include/
librtmp osxfuse pycairo
--
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
FWIW, I think that in order to use _Py_BEGIN_SUPPRESS_IPH timemodule.c should
be compiled with PY_CORE_CFLAGS, and that should be reflected in the Makefile.
--
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Steve, maybe you can surround "_Py_BEGIN_SUPPRESS_IPH" with "#ifdef
Py_BUILD_CORE"?
--
___
Python tracker
<http://bug
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24298>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
nosy: +ncoghlan
___
Python tracker
<http://bugs.python.org/issue24298>
___
___
Python-bugs-list mailing list
Unsubscribe:
Yury Selivanov added the comment:
> Towards the end of the configured top-level Makefile, you should see:
Yes, I don't see that line. What should I do to regenerate it? And another
question: what did go wrong with my checkout?
--
__
Yury Selivanov added the comment:
> Check the times and contents on all of your Modules/Setup* files. Try
> deleting Setup.local for one.
I just made a clean checkout and that helped. I have no idea what caused this.
Thank you, Ned, for troubleshooting this with me!
--
pr
Yury Selivanov added the comment:
Thanks for reporting this, Petr!
Nick, could you please take a look at the patch?
--
assignee: -> yselivanov
keywords: +patch
stage: -> patch review
versions: +Python 3.6
Added file: http://bugs.python.org/file39524/signature
Changes by Yury Selivanov :
Added file: http://bugs.python.org/file39526/signature2.patch
___
Python tracker
<http://bugs.python.org/issue24298>
___
___
Python-bugs-list m
Yury Selivanov added the comment:
> That's also a little more future-proof, in case any further checks happen to
> be inserted ahead of the check for __wrapped__.
Well, we unwrap until we see a "__signature__" attribute (or we can't unwrap
anymore). And right
Yury Selivanov added the comment:
> I'm OK with the patch as is, but I'm definitely concerned about the
> maintainability of inspect.signature in general.
I agree, _signature_from_callable is getting quite complex. The good news is
that we have a very good test coverage for
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
> 2) Awaitable.register(Coroutine)
> I think this is incorrect. A Coroutine is not Awaitable unless it also
> implements "__await__". How else should it be awaited?
It *is* correct, see PEP 492. Awaitable is either a coroutine *or*
Yury Selivanov added the comment:
> > It *is* correct, see PEP 492. Awaitable is either a coroutine *or* an
> > object with an __await__
> method.
>
> "coroutine", yes. But "Coroutine"? Shouldn't the Coroutine ABC then require
> "__awa
Yury Selivanov added the comment:
> For your first question, I agree getawaitablefunc / aiternextfunc /
> getaiterfunc should all be dropped and replaced with the existing "unaryfunc".
I have no problem with that. But why do we have iternextfunc & getiter
New submission from Yury Selivanov:
See issue 24017 for details.
--
assignee: yselivanov
components: Library (Lib)
files: abcs.patch
keywords: patch
messages: 244305
nosy: gvanrossum, ncoghlan, scoder, yselivanov
priority: normal
severity: normal
stage: patch review
status: open
title
Changes by Yury Selivanov :
--
dependencies: +collections.abc: Coroutine should be derived from Awaitable
___
Python tracker
<http://bugs.python.org/issue24
New submission from Yury Selivanov:
Stefan,
This patch should solve the problem with types.coroutine accepting only pure
python generator functions.
The approach is, however, slightly different from what you've proposed.
Instead of having a wrapper class (delegating .throw, .send etc
Changes by Yury Selivanov :
--
dependencies: +collections.abc: Coroutine should be derived from Awaitable
___
Python tracker
<http://bugs.python.org/issue24
Yury Selivanov added the comment:
Stefan,
I've already committed fixes for:
1. getawaitablefunc / aiternextfunc / getaiterfunc -> unaryfunc
2. strange code in tasks.py doing "coro = iter(coro)" is now removed
I've also opened a couple of new issues (with pa
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
Yury Selivanov added the comment:
Marius, thanks for reporting the bug and review!
--
___
Python tracker
<http://bugs.python.org/issue24297>
___
___
Python-bug
Changes by Yury Selivanov :
--
nosy: +yselivanov
___
Python tracker
<http://bugs.python.org/issue24321>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Yury Selivanov :
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<http://bugs.python.or
2101 - 2200 of 3098 matches
Mail list logo
