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-oCMSABgAJ
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 start
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 event loo
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` (or `gaierror
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
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 libr
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 an `atexit
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
<ht
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
<ht
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 unfamiliarity with the
BPO UI
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 file
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`. We
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 future
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 the t
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
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 shu
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
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 <ben.darn...@gmail.com> 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)
Ben Darnell <ben.darn...@gmail.com> 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 bu
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 rep...@bugs.python.org
http
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 unusual
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#L222
I
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'll have to use
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 result without
Ben Darnell added the comment:
On Tue, Jun 9, 2015 at 10:12 PM, Yury Selivanov rep...@bugs.python.org
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-typing? Awaitable is an object
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 operation
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
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.
--
nosy
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 don't
Changes by Ben Darnell ben.darn...@gmail.com:
--
nosy: +Ben.Darnell
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17997
___
___
Python-bugs-list
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
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 rep...@bugs.python.org
http://bugs.python.org/issue13721
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 rep...@bugs.python.org
http://bugs.python.org/issue8240
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
New submission from Ben Darnell ben.darn...@gmail.com:
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
New submission from Ben Darnell ben.darn...@gmail.com:
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
Ben Darnell ben.darn...@gmail.com 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
Ben Darnell ben.darn...@gmail.com added the comment:
These functions are used when passing a socket object across a
multiprocessing.Queue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue11657
New submission from Ben Darnell ben.darn...@gmail.com:
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=fo\\o;bar')
('form
New submission from Ben Darnell ben.darn...@gmail.com:
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
53 matches
Mail list logo
