New submission from Nathaniel Smith:
A common problem when working with async functions is to attempt to call them
but forget the 'await', which eventually leads to a 'Warning: coroutine ... was
never awaited' (possibly buried in the middle of a bunch of traceback shrapnel
Changes by Nathaniel Smith :
--
nosy: +njs
___
Python tracker
<http://bugs.python.org/issue30482>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nathaniel Smith:
Currently, traceback objects don't expose any public constructor, are
immutable, and don't have a __dict__ or allow subclassing, which makes it
impossible to add extra annotations them.
It would be nice if these limitations were lifted, because
Nathaniel Smith added the comment:
Uh, please ignore the random second paste of the jinja2 URL in the middle of
the second to last paragraph.
--
___
Python tracker
<http://bugs.python.org/issue30
Nathaniel Smith added the comment:
My understanding is that the major difference between a real traceback object
and a TracebackException object is that the latter is specialized for printing,
so it can be lighter weight (no pinning of frame objects in memory), but loses
some utility (can&#
Nathaniel Smith added the comment:
I can think of two downsides to using __annotations__ for this:
1) Obviously contextlib itself isn't going to add any kind of annotation in any
versions before 3.7, but third-party projects might (like contextlib2, say).
And these projects have been kno
Changes by Nathaniel Smith :
--
pull_requests: +2056
___
Python tracker
<http://bugs.python.org/issue30594>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Nathaniel Smith:
If you pass a server_hostname= that fails IDNA decoding to
SSLContext.wrap_socket or SSLContext.wrap_bio, then the SSLContext object has a
spurious Py_DECREF called on it, eventually leading to segfaults.
Demo attached.
--
assignee
Nathaniel Smith added the comment:
If the SSL module followed the pattern of encoding all str to bytes at the
edges while leaving bytes alone, and used exclusively bytes internally (and in
this case by "bytes" I mean "bytes objects containing A-labels"), then it would
a
Changes by Nathaniel Smith :
--
nosy: +njs
___
Python tracker
<http://bugs.python.org/issue17305>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nathaniel Smith :
--
pull_requests: +2058
___
Python tracker
<http://bugs.python.org/issue30594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Changes by Nathaniel Smith :
--
pull_requests: +2057
___
Python tracker
<http://bugs.python.org/issue30594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nathaniel Smith added the comment:
posted backports for 3.5 and 3.6. It looks like 2.7 is actually unaffected,
because it doesn't have IDNA support, so there's no failure path in between
when the reference is stored and when its INCREFed.
--
versions: -
Changes by Nathaniel Smith :
--
pull_requests: +2065
___
Python tracker
<http://bugs.python.org/issue30594>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nathaniel Smith added the comment:
Looks good to me, thanks Serhiy.
--
___
Python tracker
<http://bugs.python.org/issue29943>
___
___
Python-bugs-list mailin
Nathaniel Smith added the comment:
I guess now would be a good time to decide whether this should be backported to
3.6, with 3.6.2 coming out in a few days :-). (Or if not, then it can probably
be closed?)
--
___
Python tracker
<h
Nathaniel Smith added the comment:
I think you mean it's backwards *compatible*? There's definitely no change in
APIs or ABIs or anything, all that changes is the order of some statements
inside Python's signal handler. (We used to we write to the magic wakeup fd and
then set
Nathaniel Smith added the comment:
But, by that definition, like... every change is backwards incompatible.
I'm pretty confident that no-one was relying on this race condition. I can't
even figure out what that would mean.
--
___
Pyth
Nathaniel Smith added the comment:
It's because Julian thinks _PyTraceMalloc_Untrack is going to lose its
underscore in 3.7, so he made numpy assume that. Numpy issue, I'll see what we
can do.
--
___
Python tracker
<http://bu
Nathaniel Smith added the comment:
@Arek: It's great that you're testing your code against the latest 3.7
pre-release, because that helps give early warning of issues in CPython as its
developed, which helps everyone. BUT, you really cannot expect to use
in-development versions
Nathaniel Smith added the comment:
This broke cffi:
gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3
-Wall -g -fstack-protector --param=ssp-buffer-size=4 -Wformat
-Werror=format-security -fPIC -DUSE__THREAD -DHAVE_SYNC_SYNCHRONIZE
-I/opt/python/3.8-dev/include
Nathaniel Smith added the comment:
The cffi issue is:
https://bitbucket.org/cffi/cffi/issues/403/build-fails-on-38-dev-pyinterpreterstate
Armin already went ahead and committed the change to make cffi include
internal/pycore_pystate.h. I guess this might not be the ideal final outcome
Nathaniel Smith added the comment:
There are some tricky subtleties here around the distinction between
list/dict/set comprehensions and generator expressions.
For list/dict/set comprehensions, they're evaluated eagerly, so an async
comprehension can only occur in async context
Nathaniel Smith added the comment:
> Except that your first example (an asynchronous generator in a synchronous
> comprehensions) is allowed in the current code and can occur inside a
> synchronous function.
Oh yeah, you're r
Nathaniel Smith added the comment:
Yeah, the check makes sense on a system like the comment says IRIX used to be,
where getpid() actually returns a thread id *and* signals are delivered to all
threads (wtf). But any modern system should do the POSIX thing, where getpid()
returns the same
Nathaniel Smith added the comment:
Yeah, seems like a simple oversight to me. (Actually this is the first I've
heard of weakref.proxy...)
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
> My response was to not take care of that in the first time, but provide the
> building blocks for alternative REPL, in a second time provide an
> async-input, and a way to register runner for alternative async libraries.
Yeah, I think this
New submission from Nathaniel Smith :
Background: Doing I/O to files on disk has a hugely bimodal latency. If the I/O
happens to be in or going to cache (either user-space cache, like in
io.BufferedIOBase, or the OS's page cache), then the operation returns
instantly (~1 µs) without blo
Nathaniel Smith added the comment:
Whoa, cool.
bpo-32561 is complementary to this. (They both make sense on their own, but
they're even better together.)
--
___
Python tracker
<https://bugs.python.org/is
New submission from Nathaniel Smith :
In 3.6, trying to connect to a AF_UNIX socket using a pathlib.Path object
doesn't work:
Python 3.6.4 (default, Dec 27 2017, 13:02:49)
[GCC 7.2.0] on linux
Type "help", "copyright", "credits" or "license" for
Nathaniel Smith added the comment:
> BufferedIOBase is an abstract class and, despite the name, doesn’t
> necessitate a buffer or cache
Right, sorry, skimmed too fast.
> In Issue 32475 there is a proposal to add a “getbuffn” method returning the
> amount of unread pending data
Nathaniel Smith added the comment:
Hmm, why did I use "unbuffered" as my term above? That's a very odd name. It's
like, exactly the opposite of what we actually want. Clearly I did not think
this through properly. Please pretend I said "buffer-only" instead, th
Nathaniel Smith added the comment:
That's a reasonable concern. Do you think we can deprecate the existing broken
non-blocking mode?
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
Putting .dll's next to their .pyd's isn't a general solution, because sometimes
you want to be able to use the same .dll's from .pyd's that are in different
directories. For example, scipy.spatial.qhull, scipy.optimize._lbfsgb, and
Nathaniel Smith added the comment:
Conda is cool but we're not currently planning to abandon wheels.
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
> However, the principal reason that I'm opening this issue is that Ray
> complained that packages shouldn't be altering the DLL search path
If that's crucial context, can you link to it?
--
_
Nathaniel Smith added the comment:
Steve said:
> The import hook was my proposal to let you only preload DLLs when the
> extension module is being loaded, rather than having to load all the DLLs on
> the first "import scipy" just in case one of its submodules gets import
Nathaniel Smith added the comment:
> it still won't help if another import has loaded a different DLL by the same
> name. This is where you can't avoid recompilation or activation contexts.
Ah, there's an important bit of context you're missing: there is actually
Nathaniel Smith added the comment:
> That looks like recompilation (or at least how recompilation would look if
> you'd been granted permission). Assuming you can recompile the binary, you
> could rename the dependency and regenerate the import library so that you can
> link
Nathaniel Smith added the comment:
Can I ask why this is a private API? It's extremely useful for extension
modules too. For example, numpy has been carrying around a reimplementation of
PyObject_GetAttr for years, exactly to avoid the cost of creating an
AttributeError exception in c
Nathaniel Smith added the comment:
Well, mostly I just want to draw your attention to that use case to encourage
you to make it public when it's ready :-)
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
Python's codecs already support partial decode, exactly to handle this kind of
case. See codecs.getincremental{en,de}coder and
https://docs.python.org/3/library/codecs.html#incremental-encoding-and-decoding
--
nosy:
New submission from Nathaniel Smith :
sys.set_coroutine_wrapper is a problematic API. It was added to solve a
specific problem: asyncio debug mode wanting to track where coroutine objects
are created, so that when unawaited coroutines are GC'ed, the warning they
print can include a trac
Nathaniel Smith added the comment:
> I'm not sure how exactly the warning print logic will work with a list of
> tuples in cr_origin, I propose to start working on the implementation and
> figure that out during the review process.
I think the simplest thing is probably to wri
New submission from Nathaniel Smith :
There's a curious bit of code in genobject.c:_PyGen_Finalize:
if (!error_value) {
PyErr_WarnFormat(PyExc_RuntimeWarning, 1,
"coroutine '%.50S' was never awaited",
Change by Nathaniel Smith :
--
keywords: +patch
pull_requests: +5097
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32591>
___
___
Py
Nathaniel Smith added the comment:
I have a patch for this, but it will be simplest if we can merge
https://github.com/python/cpython/pull/5250 (for bpo-32591) first, because they
touch a lot of overlapping code.
--
___
Python tracker
<ht
Change by Nathaniel Smith :
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue32391>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nathaniel Smith added the comment:
The current default is hard to defend -- it's a clear violation of the TLS
specs. But I suspect that changing it will be pretty disruptive, because
suppress_ragged_eof=True is the de facto standard for HTTP-over-TLS (generally
justified on the grounds
Nathaniel Smith added the comment:
@Christian: I'm surprised and somewhat dismayed to hear that OpenSSL
invalidates sessions on hard close -- that hasn't been part of the spec since
2006 when TLS 1.1 came out. I'm not a cryptographer, but the spec explicitly
allows keeping the
Nathaniel Smith added the comment:
It doesn't help that Python spells SSL_shutdown as "unwrap".
I think in practice basically the only two things you want are unidirectional
shutdown, or "soft" shutdown. Bidirectional shutdown has some extremely
theoretical uses,
Nathaniel Smith added the comment:
Why would an exception inside 'with ssl_sock' have anything to do with the
validity of the session shared secret?
I mean, maybe it does, but I *really* don't think we should be waving our hands
and guessing a
Change by Nathaniel Smith :
--
keywords: +patch
pull_requests: +5123
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue30491>
___
___
Py
New submission from Nathaniel Smith :
The test_asyncio tests are generating some warnings:
0:00:00 load avg: 2.14 [1/1] test_asyncio.test_tasks
/home/njs/src/cpython/Lib/test/test_asyncio/test_tasks.py:100: RuntimeWarning:
coroutine 'SetMethodsTest.test_set_exception_causes_invalid_state
Change by Nathaniel Smith :
--
keywords: +patch
pull_requests: +5124
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32633>
___
___
Py
Nathaniel Smith added the comment:
Huh, weird. I'll take a look.
--
___
Python tracker
<https://bugs.python.org/issue32636>
___
___
Python-bugs-list m
Nathaniel Smith added the comment:
Question: there are lots of tests -- for example
test.test_asyncio.test_tasks.CTaskSubclass_PyFuture_Tests.test_wait_with_exception,
which freezes for me -- that use 'yield from asyncio.sleep(...)', e.g.:
@asyncio.coroutine
d
Nathaniel Smith added the comment:
(However, I can report that at least that particular test starts working again
if I convert 'sleeper' into an 'async def' coroutine.)
--
___
Python tracker
<https://bug
Nathaniel Smith added the comment:
How confident are we that this is a regression from the coroutine origin
tracking changes? (I'd double-check myself, but my cpython checkout is tied up
for the next few hours doing --enable-optimizations builds.)
Looking at @asyncio.coroutine, in parti
Nathaniel Smith added the comment:
Ah-hah, I get what's going on.
@asyncio.coroutine has always been buggy: when debug mode is turned on, then it
fails to set CO_ITERABLE_COROUTINE.
However, when debug mode is turned on, then traditionally native coroutines got
wrapped into CoroWr
Change by Nathaniel Smith :
--
keywords: +patch
pull_requests: +5137
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32636>
___
___
Py
Nathaniel Smith added the comment:
Please insert the usual caveats around how reliable benchmarking is impossible.
(Last month when I tried this with a previous version of the patch, the
interpreter that had the patch applied -- and thus was doing slightly *more*
work -- was consistently a
Nathaniel Smith added the comment:
Yury also asked me to try running a generator/coroutine microbenchmark from PEP
492 (https://www.python.org/dev/peps/pep-0492/#async-await). I'm attaching the
actual script for that as well (pep492bench.py), since I had to add a few lines
to actuall
Nathaniel Smith added the comment:
Thanks for the summary, Yury! One quick note:
> Effectively, the previously merged origin-tracking API (the one with which we
> replaced set_coroutine_wrapper) achieves the same goal.
I would say the two features are complementary. This feature (una
Nathaniel Smith added the comment:
> I attempted to implement my weakref idea (i.e. raw file keeps a weakref to
> the buffered file, calls flush before the raw file gets closed). That
> doesn't work either because the GC clears the weakref before calling __del__.
This may be a
Nathaniel Smith added the comment:
Right, I *knew* I should be nervous about calling into Python from a C-level
destructor... what's happening is:
- Somehow, that coroutine object is managing to survive until the very, very
end of the shutdown sequence (PyImport_Cleanup). I'm no
Change by Nathaniel Smith :
--
pull_requests: +5184
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue32591>
___
___
Python-
Nathaniel Smith added the comment:
What should happen for:
def f():
if random.random() < 0.5:
a = 1
b = 2
else:
b = 1
a = 2
return locals()
? Right now co_varnames preserves the order that names were encountered when
compiling, so it'd be
Nathaniel Smith added the comment:
Greg: That's bpo-28414. There's currently no motion towards builtin IDNA 2008
support (this bug), but I *think* in 3.7 the ssl module will be able to handle
pre-encoded A-labels like that. I'm a little confused about the exact status
right
Nathaniel Smith added the comment:
The "obvious" solution would be to move the "idna" module into the stdlib, but
someone would still have to work that out, and it's clearly not happening for
3.7.
--
versions: +Python 3.8 -Python 3.7
_
New submission from Nathaniel Smith :
Example (minimal version of https://github.com/python-trio/trio/issues/425):
-
async def open_file():
pass
async def main():
async with open_file(): # Should be 'async with await open_file()'
pass
coro = main()
coro
Nathaniel Smith added the comment:
> Yury's theory: maybe BEFORE_ASYNC_WITH's error-handling path is forgetting to
> DECREF the object.
Nope, that doesn't seem to be it. This version prints "refcount: 2" twice,
*and* prints a proper "was never awaited&quo
Nathaniel Smith added the comment:
> So let's retarget this to 3.8 as it's too close to 3.7 feature freeze to get
> seriously considered/merged.
I *think* I have a better idea than this for 3.8, but it's definitely
PEP-sized. The unawaited coroutine tracking proposal he
Nathaniel Smith added the comment:
Well, I feel silly then: bpo-32605
--
___
Python tracker
<https://bugs.python.org/issue32703>
___
___
Python-bugs-list mailin
Nathaniel Smith added the comment:
Ah, gotcha. I'll take a look. (For posterity: the RuntimeWarnings Yury
mentioned are also real, but they're from the branch Yury is testing for
bpo-32605 / bpo-32703, nothing to do with this issue.)
--
Change by Nathaniel Smith :
--
pull_requests: +5246
stage: resolved -> patch review
___
Python tracker
<https://bugs.python.org/issue32591>
___
___
Python-
Nathaniel Smith added the comment:
New changeset 95e214713a7da4e5cbfb73f35b2119f76074fc3f by Nathaniel J. Smith in
branch 'master':
bpo-32591: silence deprecation warnings in test_coroutine (GH-5412)
https://github.com/python/cpython/commit/95e214713a7da4e5cbfb73f35b2119
Nathaniel Smith added the comment:
Okay, more context for future archaelogists / me in 6 months, phrased in the
form of a timeline:
This discussion started back in March, when I made an issue on the trio tracker
[1] with notes on rough edges in CPython that it might make sense to try to
Nathaniel Smith added the comment:
Ok, yeah, that's a test that a warning is emitted, which fails when the warning
is converted into an error instead. Need to normalize the warnings filter
settings inside that test, I guess.
How does this not cause the same problem for every other test
Change by Nathaniel Smith :
--
keywords: +patch
pull_requests: +5317
stage: -> patch review
___
Python tracker
<https://bugs.python.org/issue32733>
___
___
Py
Nathaniel Smith added the comment:
New changeset 2efb9735899c7c642f3e75a121af82b1679577d3 by Nathaniel J. Smith in
branch 'master':
bpo-32733: Make test_coroutines robust against -Werror (GH-5487)
https://github.com/python/cpython/commit/2efb9735899c7c642f3e75a121af82
Nathaniel Smith added the comment:
New changeset 709f6ad7f84855ebdbe3e7702571b0e1447b885b by Nathaniel J. Smith
(Miss Islington (bot)) in branch '3.7':
bpo-32733: Make test_coroutines robust against -Werror (GH-5487) (GH-5490)
https://github.com/python/cpyt
Nathaniel Smith added the comment:
Thanks!
--
resolution: -> fixed
stage: patch review -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
New submission from Nathaniel Smith :
Currently, if you use asyncio.wait_for(future, timeout=) and the timeout
expires, then it (a) cancels to the future, and then (b) returns. This is fine
if the future is a Future, because Future.cancel is synchronous and completes
immediately. But if
Nathaniel Smith added the comment:
The other option would be to always hide the new constant on Windows in 3.6,
and make it unconditionally available on 3.7.
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue32
Nathaniel Smith added the comment:
I definitely don't think we should get into the game of trying to guess which
flags are supported at runtime and only exposing those. It's not as simple as
keeping a table of OS versions -- which would be hard enough to get right --
but on Lin
Nathaniel Smith added the comment:
There's two separate issues here: the warning spew because asyncio's internal
signal handling code starts losing signals when they arrive too quickly, and
the way the child reaping loop polls all the children on every SIGCHLD, which
makes reaping
Nathaniel Smith added the comment:
I think I agree with Serhiy here... the whole difference between run([a]) and
run(a) is that in the first case 'a' is treated as a path, and in the second it
isn't. This distinction long predates pathlib.
Say I have an oddly named binary w
Nathaniel Smith added the comment:
I'm sympathetic to the idea that we don't want to carry around these checks,
but also to the idea that this caused a regression in a micro release and
that's not cool. Hence the idea that maybe we should keep everything the way it
is in 3.7,
Nathaniel Smith added the comment:
If a task refuses to be cancelled, then is waiting for it forever actually
wrong? That's the same thing as happens if I do 'task.cancel(); await task',
right? Currently wait_for will abandon such a task, but then it's still left
runni
Nathaniel Smith added the comment:
How do you tell the difference between a cancelled task that's about to exit,
and one that will never exit?
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
I think you meant to file this on pyenv, which is the tool that travis needs to
have updated to know about 3.8 before they can start providing builds. Their
bug tracker is here: https://github.com/pyenv/pyenv/issues
--
nosy: +njs
Change by Nathaniel Smith :
--
nosy: +asvetlov, giampaolo.rodola, njs, yselivanov
___
Python tracker
<https://bugs.python.org/issue32810>
___
___
Python-bug
Nathaniel Smith added the comment:
Interesting case! This is super subtle. I think the patch is correct though.
(In Trio this is one of the cases where we use shielding:
https://github.com/python-trio/trio/blob/f48d8922dfe2118bfaaf9a85f2524e58146ba369/trio/_sync.py#L749-L752
. But
Nathaniel Smith added the comment:
It does make me wonder if asyncio.shield *should* wait for the thing it's
shielding though, so that it *would* work in this case? (Similar to bpo-32751.)
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
> Having shield not cancel immediately but rather wait and cancel will cause
> long timed shielded operations to stall the task cancellation, usually for no
> good. This isn't the general case.
What I'm suggesting is that maybe it actu
Change by Nathaniel Smith :
--
nosy: +ezio.melotti, njs
___
Python tracker
<https://bugs.python.org/issue32850>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Nathaniel Smith :
--
nosy: +njs
___
Python tracker
<https://bugs.python.org/issue32865>
___
___
Python-bugs-list mailing list
Unsubscribe:
Nathaniel Smith added the comment:
Christian: we're less than a week out from b2. Do you need any help here?
--
___
Python tracker
<https://bugs.python.org/is
Nathaniel Smith added the comment:
Can you back up a bit and give an example of the problem you're running into?
--
___
Python tracker
<https://bugs.python.org/is
201 - 300 of 488 matches
Mail list logo
