New submission from Tom Christie :
Raising an issue that's impacting us on `httpx`.
It appears that in some cases SSL unwrapping can cause `.wait_closed()` to hang
indefinately.
Trio are particularly careful to work around this case, and have an extensive
comment on it:
https://github.com
Tom Christie added the comment:
Right, and `requests` *does* provide both those styles.
The point more being that *not* having closed the transport at the point of
exit shouldn't end up raising a hard error. It doesn't raise errors in
sync-land, and it shouldn't do so in async-land
Tom Christie added the comment:
> From my understanding, the correct code should close all transports and wait
> for their connection_lost() callbacks before closing the loop.
Ideally, yes, although we should be able to expect that an SSL connection that
hasn't been gracefully
Tom Christie added the comment:
This appears somewhat related: https://bugs.python.org/issue34506
As it *also* logs exceptions occuring during `_fatal_error` and `_force_close`.
--
___
Python tracker
<https://bugs.python.org/issue36
New submission from Tom Christie :
If an asyncio SSL connection is left open (eg. any kind of keep-alive
connection) then after closing the event loop, an exception will be raised...
Python:
```
import asyncio
import ssl
import certifi
async def f():
ssl_context
Tom Christie <t...@tomchristie.com> added the comment:
Refs: https://github.com/python/cpython/pull/6617
--
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
New submission from Tom Christie <t...@tomchristie.com>:
The `contextvars` documentation, at
https://docs.python.org/3.7/library/contextvars.html starts with the following:
"This module provides APIs to manage, store, and access non-local state."
I assume that must be a d
Tom Christie added the comment:
Confirming that I've also bumped into this for Python 3.5.
A docs update would seem to be the lowest-cost option to start with.
Right now `mimetypes.guess_extension()` isn't terribly useful, and it'd be
better to at least know that upfront.
--
nosy
Christie added the comment:
If #18576 gets merged before this does, I have some updated docs for the new
helper functions.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24033
Christie added the comment:
Hello all!
So the following are waiting for review:
* #24033
* #23981
* #24279
I'm going to hold off on continuing to refactor any other modules for the
moment, would be great to get the above wrapped up and eventually merged when
possible.
Thanks!
- Christie
Christie added the comment:
Hey @vadmium!
I've finally responded to your review feedback. I've attached a new patch,
hopefully this time actually review-able. I've removed the docs for methods I
added in @24033 so that this could be merged without it.
Let me know if you have any more
Christie added the comment:
Uploading a new patch, diffed against a public revision so it's reviewable.
--
Added file: http://bugs.python.org/file39708/issue23981_test_unicode.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Christie added the comment:
Now using existing function spawn_python instead of creating a new function.
--
Added file: http://bugs.python.org/file39710/issue24033_multi.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Christie added the comment:
Uploading a new patch, diffed against a public revision so it's reviewable.
--
Added file: http://bugs.python.org/file39709/issue24279_base64.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Christie added the comment:
If you diffed your patch from a public revision in the main repository, there
should be a nice “Review” link.
Ah, thanks @vadmium!!! I've been confused about why some patches get review
links and others do not .
I'll have a new patch up shortly which is diffed
Christie added the comment:
I can't seem to get test_no_FatalError_infinite_loop to fail - I tried
reverting the fix that this was verifying, but the test still passed and no
infinite loop to be seen. I'm wondering if this is because I can't reproduce it
on a mac
Christie added the comment:
run_python and spawn_python are basically the same, I need to reconcile those.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24033
Christie added the comment:
@ncoghlan I've taken the test.rst changes from the previous diff and reviewed
them against the latest script_helper (including updates from issue24033).
Nothing had fallen behind, but I've added what was missing.
* I've realized that spawn_python and the helper
Christie added the comment:
Created issue24398 for updating test_capi.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
___
___
Python-bugs
New submission from Christie:
As described in Issue9517, many test modules do not make use of the helpers in
script_helpers.py to invoke the python interpreter in a subprocess. Issue9517
will be broken down into several smaller issues so we can address smaller
change sets.
This issue
New submission from Christie:
As described in Issue9517, many test modules do not make use of the helpers in
script_helpers.py to invoke the python interpreter in a subprocess. Issue9517
will be broken down into several smaller issues so we can address smaller
change sets.
This issue
Christie added the comment:
Created Issue24279 for updating test_base64.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
___
___
Python-bugs
Christie added the comment:
Updated TestMain in test_base64 to use test.support.script_helpers. Split
`test_encode_file` into two tests.
--
keywords: +patch
Added file: http://bugs.python.org/file39485/issue24279_base64.patch
___
Python tracker rep
Christie added the comment:
I'm going to take a look at bringing these docs up to date and including the
changes from issue24033.
--
nosy: +bobcatfish
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue18576
Christie added the comment:
@BreamoreBoy, it looks like the next step would be to revisit issue15403 and go
through the steps outlined by @ncoghlan.
--
nosy: +bobcatfish
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue15376
Christie added the comment:
Cool, thanks @ncoghlan! Would you like someone to take on the work of updating
the latest patch on issue 18576?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
Christie added the comment:
Hey @berker.peksag, @r.david.murray, @serhiy.storchaka,
If you get a chance I've got some changes up for review at:
* http://bugs.python.org/issue24033
* http://bugs.python.org/issue23981
Thanks!
--
___
Python tracker
Christie added the comment:
Updated both tests in _test_mulitprocessing.py which were using sys.exectuable
and Popen to use script_helpers instead, refactored script_helpers a bit to
make this work.
--
keywords: +patch
Added file:
http://bugs.python.org/file39347
Christie added the comment:
Thanks very much @berker.peksag!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
___
___
Python-bugs-list
Christie added the comment:
@serhiy.storchaka - just double checking, do you guys need me to make any more
changes to the patch?
And is there any more review needed, or is it possible for this to be merged?
Thanks very much!
--
___
Python tracker
Christie added the comment:
Hey @berker.peksag, I've added a new patch in response to your review!
You should create the patch with hg diff --git to preserve moving. And then
apply it with hg import, not the patch command. Unfortunately Rietveld
don't like patches in git format.
Ick, I'm
Christie added the comment:
Hey @berker.peksag, @r.david.murray!
Here's another change set where script_helpers.py is moved with an hg mv (still
looks in the patch like the file was deleted and re-added, not sure if that's
expected).
I've ALSO removed some unused imports from
New submission from Christie:
As described in Issue9517, many test modules do not make use of the helpers in
script_helpers.py to invoke the python interpreter in a subprocess. Issue9517
will be broken down into several smaller issues so we can address smaller
change sets.
This issue
Christie added the comment:
I am working on this!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24033
___
___
Python-bugs-list mailing list
Christie added the comment:
Created issue24033. If it and issue23981 could be added as dependencies of this
issue (or I could get permission to add them?) that would be swell!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org
Christie added the comment:
So @flipmcf we're sticking with the test.support.script_helper namespace?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
New submission from Christie:
As described in Issue9517, many test modules do not make use of the helpers in
script_helpers.py to invoke the python interpreter in a subprocess. Issue9517
will be broken down into several smaller issues so we can address smaller
change sets.
This issue
Christie added the comment:
I am working on this now.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue23981
___
___
Python-bugs-list mailing list
Christie added the comment:
@r.david.murray I've created issue23981, I don't think I have permissions to
add it as a dependency to this issue.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
Christie added the comment:
@r.david.murray, just bugging you b/c you were commenting on Issue9517, this is
ready for a review. It assumes the patch from Issue9517 has been applied.
I'm thinking for the next issue I'll tackle a few test modules at once, since
this is such a tiny tiny change
Christie added the comment:
I would recommend still moving script_helper into test.support , and adding a
list of symbols from script_helper.py into __init__
Sounds like a great plan to me @flipmcf!
--
___
Python tracker rep...@bugs.python.org
Christie added the comment:
@r.david.murray and @flipmcf:
I've audited all test modules using sys.executable for a starting point, and
these tests look like they could benefit from helper methods to invoke python
(probably the ones in script_helper, but we may want to create others
Christie added the comment:
Hey there @flipmcf, is the change which adds `script_helpers` to test.support
is missing from your patch?
import test.support.script_helper
Traceback (most recent call last):
File stdin, line 1, in module
ImportError: No module named 'test.support.script_helper
Christie added the comment:
Okee dokee, I'll tackle that first!
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
___
___
Python-bugs-list
Christie added the comment:
Okay thanks @r.david.murray, I'll take a look at doing this. I'll open an issue
when I figure out which module to start on.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9517
Christie added the comment:
Hello @r.david.murray!
We probably don't want a multi-module changeset, though, so this could become
a meta issue for new issues for converting particular test files to use
script_helpers.
Does this mean you'd like to leave this issue open until all of the test
Tom Christie added the comment:
I believe the status of this should be reassessed and that python should
default to escaping '\u2028' and '\u2029'. *Strictly* speaking this isn't a bug
and is per the JSON spec.
*However* this *is* a bug in the JSON spec - which *should* be a strict subset
Tom Christie added the comment:
There is explicit note in the documentation about incompatibility with
JavaScript.
That may be, but we're still unnecessarily making for a poorer user experience.
There's no good reason why we shouldn't just treat \u2028 and \u2029 as control
characters
New submission from Tom Christie:
This is one of those behavioural issues that is a borderline bug.
The seperators argument to `json.dumps()` behaves differently across python 2
and 3.
* In python 2 it should be provided as a bytestring, and can cause a
UnicodeDecodeError otherwise
Tom Christie added the comment:
Not too fussed if this is addressed or not, but I think this is closed a little
prematurely.
I don't think there's a problem under Python 3, that's entirely reasonable.
However under Python 2, `json.dumps()` will normally handle *either* bytes or
unicode
Tom Christie added the comment:
But only if you use non-ascii in the binary input, in which case you get an
encoding error, which is a correct error.
Kind of, except that this (python 2.7) works just fine:
data = {'snowman': '☃'}
json.dumps(data, ensure_ascii=False)
'{snowman
Tom Christie added the comment:
So, as soon as (but only as soon as) you mix unicode with your non-ascii
data, your program blows up.
Indeed. For context tho my example of running into this the unicode literals
used as seperators weren't even in the same package as the non-ASCII binary
New submission from Tom Christie t...@tomchristie.com:
json.dumps() documentation is slightly incorrect.
http://docs.python.org/library/json.html#json.dumps
Reads:
If ensure_ascii is False, then the return value will be a unicode instance.
Should read:
If ensure_ascii is False
53 matches
Mail list logo
