Ben Darnell added the comment:
On MacOS in 2015, getaddrinfo was found to be much slower than inet_pton.
Unless that's changed, this patch would be a performance regression on that
platform. Data and benchmark script in
https://groups.google.com/g/python-tulip/c/-SFI8kkQEj4/m/m1-oCMS
Ben Darnell added the comment:
To summarize the justification, this patch does two things: it moves an
optimization from create_connection to getaddrinfo, which makes it apply to
more callers (including Tornado), and it makes the code simpler and less
redundant (net reduction of 47 non-test
Ben Darnell added the comment:
> To be clear, by "cancel" you are not talking about Future.cancel(). Rather,
> your handler causes all running tasks to finish (by sending a special message
> on the socket corresponding to each running task). Is that right?
Correct. My t
Ben Darnell added the comment:
> In IPython, I think you could use new_event_loop() for getting a new loop
> instance.
> Then, save the loop reference somewhere as a direct attribute,
> threading.local or ContextVar.
> Calling loop.run_until_complete() looks pretty normal in
Ben Darnell added the comment:
> The maintenance burden of the introduced deprecation should be pretty low.
This is going to cause an unpleasant amount of churn in the Tornado community.
It's been idiomatic (going back 12 years now) to do all your setup in
synchronous code before
Ben Darnell added the comment:
> It's even slightly easier for tornado, which can reasonably set the
> proactor-wrapper policy at IOLoop start time, which means
> `asyncio.get_event_loop()` returns a loop with add_reader. But pyzmq doesn't
> get invoked until an
Ben Darnell added the comment:
[I'm coming here from https://github.com/tornadoweb/tornado/pull/3010)
UnicodeError is a subclass of ValueError, so I don't see what value that change
would provide. The thing that's surprising to me is that it's not a
`socket.herror
Ben Darnell added the comment:
I have resolved my issue here by moving from ThreadPoolExecutor to a plain
threading.Thread that I manage by hand
(https://github.com/tornadoweb/tornado/commit/15832bc423c33c9280564770046dd6918f3a31b4).
Therefore I no longer need this for myself and I leave it
Ben Darnell added the comment:
> IMO, a better practice would be providing those potentially infinite running
> tasks a direct method of escape and invoking it before calling
> executor.shutdown(), it would be a more reliable approach.
Agreed, but the problem is that I'm in a
New submission from Ben Darnell :
I'm dealing with a subtle deadlock involving
concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python
3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks in
the thread pool, and I cancel them in
Ben Darnell added the comment:
I've fixed the test and added some commentary about the different levels of
clean shutdown we must do to quiet all the warnings:
https://github.com/python/cpython/pull/22066
--
___
Python tracker
&
Change by Ben Darnell :
--
pull_requests: +21156
pull_request: https://github.com/python/cpython/pull/22066
___
Python tracker
<https://bugs.python.org/issue39
Ben Darnell added the comment:
I can confirm that those warnings appear to be coming from the test I added
here. I'm not sure how to interpret them, though - what does it mean for the
main thread to be dangling?
--
___
Python tracker
&
Ben Darnell added the comment:
I've posted a pull request with a test and fix:
https://github.com/python/cpython/pull/22017. It's a more targeted fix than
cmeyer's PR (which I didn't even notice until now due to unfamiliar
Change by Ben Darnell :
--
pull_requests: +21117
pull_request: https://github.com/python/cpython/pull/22017
___
Python tracker
<https://bugs.python.org/issue39
Ben Darnell added the comment:
No, this is unrelated to bpo-39010.
--
___
Python tracker
<https://bugs.python.org/issue39651>
___
___
Python-bugs-list mailin
Ben Darnell added the comment:
> Would it be acceptable for you to *require* use of uvloop when Tornado is
> used with AsyncIO?
How, exactly? Adding the dependency is no problem, but AFAIK I'd still be stuck
with an import-time side effect to set the event loop policy (or a .pth
Ben Darnell added the comment:
I considered using the `selectors` module directly, but it's not as simple as
it sounds. Using the low-level interface means you need to also use a
self-waker-pipe (or socket on windows) and manage a queue analogous to that
used by `call_soon_threadsafe
Ben Darnell added the comment:
I have an implementation of the selector-in-another-thread solution in
https://github.com/tornadoweb/tornado/pull/2815. Is something like this worth
considering for Python 3.9, or was Tornado the only project experiencing this
pain and a tornado-specific
New submission from Ben Darnell :
Proactor and selector event loops behave differently when call_soon_threadsafe
races with a concurrent call to loop.close(). In a selector event loop,
call_soon_threadsafe will either succeed or raise a RuntimeError("Event loop is
closed"). In
Ben Darnell added the comment:
I just spent some time digging into this. Each call to `run_forever` starts a
call to `_loop_self_reading`, then attempts to cancel it before returning:
https://github.com/python/cpython/blob/1ed61617a4a6632905ad6a0b440cd2cafb8b6414/Lib/asyncio
Ben Darnell added the comment:
Yeah, it's definitely a hack. The argument for it, at best, is "practicality
beats purity". The solution is two simple lines, but those lines need to be
repeated in every project that depends on Tornado and cares about Windows, now
or in the f
Ben Darnell added the comment:
> From my understanding, there is no issue for Tornado itself. If Jupiter
> Notebook needs Tornado, Tornado needs selector event loop on Windows --
> Jupiter can install the proper loop.
Right. I'm just advocating for something that would make
New submission from Ben Darnell :
On Windows there are two event loop implementions with different interfaces:
The proactor event loop is missing the file descriptor family of methods
(add_reader()), while the selector event loop has other limitations including
missing support for pipes and
Ben Darnell added the comment:
We have an easy reproduction of this "[Errno 0] Error" on the server side in
https://github.com/tornadoweb/tornado/issues/2504#issuecomment-426782158
It is triggered by a connection from `nc -z` (which I think is doing a TCP
handshake and shuttin
Ben Darnell added the comment:
Yeah, I think that would work at least for the sphinx use case. It seems like a
strange partially-degraded mode and anything that needs structured access to
the annotation would still need typeshed, but just getting the string would
probably be enough for a
New submission from Ben Darnell :
Currently, most type annotations for the standard library are provided in
typeshed rather than in the library itself. Not all consumers of type
annotations are aware of typeshed, and this can cause problems. Specifically,
Sphinx 1.8 accesses type hints via
Ben Darnell added the comment:
Note that a guard on socket objects can only solve part of the problem: in the
case where i've seen this bug, it was with raw file descriptors from libcurl,
and there's nothing python can do about that because there are no (python)
sock
Ben Darnell added the comment:
It's worse than a resource leak - the same file descriptor number could be
reused for a different file/socket, and then depending on the selector in use,
you could see the data from a completely different connection.
I did see a bug like this years ag
New submission from Ben Darnell:
The typing module docs at https://docs.python.org/3/library/typing.html do not
include everything that is documented in the PEP
(https://www.python.org/dev/peps/pep-0484/#the-typing-module). Specifically,
`AnyStr` is mentioned but not defined, the `@overload
Ben Darnell added the comment:
I don't think operator.getfuture() is possible because there are multiple ways
of turning an awaitable into a Future. asyncio has one way; tornado has another.
--
___
Python tracker
<http://bugs.python.org/is
Ben Darnell added the comment:
Yes, I can switch use the ABC instead, and I agree that it doesn't make sense
to have the inspect method if it's going to be equivalent to the ABC.
I'm happy with the outcome here but AFAIK the original issue still stands: the
Awaitable ABC is
Ben Darnell added the comment:
With the two changes I described things appear to be working, although I've
only done light testing so far.
For inspect.isgenerator(), my use case is here:
https://github.com/tornadoweb/tornado/blob/2971e857104f8d02fa9107a0e13f50170eb4f30d/tornado/gen.py#L2
Ben Darnell 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;
just return the resu
Ben Darnell added the comment:
On Tue, Jun 9, 2015 at 10:12 PM, Yury Selivanov
wrote:
>
> 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-typ
Ben Darnell added the comment:
> 4. While this patch addresses initial request from Ben only partially
> (generator-based coroutines still require __instancecheck__),
A partial solution doesn't mean much to me: as long as the __instancecheck__ is
sometimes necessary, I
New submission from Ben Darnell:
The new collections.abc.Awaitable ABC relies on __instancecheck__, which makes
it incompatible with functools.singledispatch (singledispatch works based on
args[0].__class__; any instance-level information is discarded). This surprised
me because the first
Ben Darnell added the comment:
I agree that SSLError should have used a different attribute, but it's too late
for that - changing it would break any code currently relying on SSL errnos (in
particular asynchronous code using the SSL_ERROR_WANT_{READ,WRITE} error codes
for normal oper
New submission from Ben Darnell:
ssl.SSLError is a subclass of OSError but uses error codes that come from a
different scope than the standard errno constants and may have conflicts. For
example, on my system (OSX), ssl.SSL_ERROR_WANT_X509_LOOKUP and errno.EINTR
have the same value. This
Ben Darnell added the comment:
Looks good to me. I've added exarkun and glyph to the nosy list since
Twisted's experience with PyOpenSSL may provide useful feedback even though
Twisted will presumably stick with what they've got instead of switching to
this new interface.
Ben Darnell added the comment:
Giampaolo, where do you see that send() may return zero if the other side has
closed? I've always gotten an error in that case (EPIPE)
I vote -1 to adding a new flag to control whether it returns zero or raises and
+0 to just fixing it in Python 3.5 (I
Changes by Ben Darnell :
--
nosy: +Ben.Darnell
___
Python tracker
<http://bugs.python.org/issue17997>
___
___
Python-bugs-list mailing list
Unsubscribe:
Ben Darnell added the comment:
I vote for enabling SSL_MODE_ACCEPT_MOVING_WRITE_BUFFER by default. It can
catch mistakes (i.e. failure to check the return value of send) in Python just
as easily as in C, but I don't think those mistakes are common enough to be
worth the headache of
Ben Darnell added the comment:
That proposal sounds good to me. I agree that any change here should target
3.4, not backports to older versions.
--
___
Python tracker
<http://bugs.python.org/issue13
Ben Darnell added the comment:
We found a related issue with Tornado:
https://github.com/facebook/tornado/pull/750
We call wrap_socket with do_handshake_on_connect=False and then call
do_handshake when the socket is ready. If the getpeername call in wrap_socket
fails with ENOTCONN because
Ben Darnell added the comment:
Related pypy issue: https://bugs.pypy.org/issue1238
--
nosy: +Ben.Darnell
___
Python tracker
<http://bugs.python.org/issue8
New submission from Ben Darnell:
In python 3.2, unittest.main by default modifies the warning configuration if
no -W options were given on the command line. This undoes the effect of -bb,
turning BytesWarning back into a warning instead of an error.
If both -bb and -Werror::BytesWarning are
New submission from Ben Darnell :
I have a script which attempts to re-invoke itself using sys.argv, but it fails
when run with "python -m package.module". The problem is that the handling of
-m (via the runpy module) rewrites sys.argv as if it were run as "python
package/modu
Ben Darnell added the comment:
Not necessarily. If I want to run python 2.7 or 3.x on an older linux
distribution (e.g. Ubuntu 10.04 LTS, which has python 2.6 and openssl 0.9.8), I
need to build from source, but I wouldn't think to update/rebuild all the
dependencies from the grou
New submission from Ben Darnell :
The ssl module docs claim that the default ssl_version for client-side
operation is SSLv3, but it is actually SSLv23. The exact behavior depends on
the version of openssl: starting in 1.0 the connection is limited by default
to SSLv3 or TLSv1 (as documented
Ben Darnell added the comment:
These functions are used when passing a socket object across a
multiprocessing.Queue.
--
___
Python tracker
<http://bugs.python.org/issue11
New submission from Ben Darnell :
cgi.parse_header doesn't work on headers that contain combinations of double
quotes and semicolons (although it works with either type of character
individually).
>>> cgi.parse_header('form-data; name="files"; filename="
New submission from Ben Darnell :
Line 125 of multiprocessing.c is "*CMSG_DATA(cmsg) = fd;". CMSG_DATA returns
an unsigned char*, while fd is an int, so this code does not support file
descriptors > 256 (additionally, I'm not sure if the buffer is guaranteed to be
init
53 matches
Mail list logo