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://githu
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 s
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 gracef
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 added the comment:
Refs: https://github.com/python/cpython/pull/6617
--
___
Python tracker
<https://bugs.python.org/issue33366>
___
___
Python-bug
New submission from Tom Christie :
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 documentation bug, right. The mo
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.
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!
- Chr
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 yo
Christie added the comment:
If #18576 gets merged before this does, I have some updated docs for the new
helper functions.
--
___
Python tracker
<http://bugs.python.org/issue24
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
<http://bugs.python.org/issue24
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
<http://bugs.python.org/is
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
<http://bugs.python.org/is
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 pat
Changes by Christie :
--
nosy: +berker.peksag, ezio.melotti, r.david.murray
___
Python tracker
<http://bugs.python.org/issue24279>
___
___
Python-bugs-list mailin
Changes by Christie :
--
nosy: +berker.peksag, ezio.melotti, r.david.murray
___
Python tracker
<http://bugs.python.org/issue23981>
___
___
Python-bugs-list mailin
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 reprodu
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
Christie added the comment:
run_python and spawn_python are basically the same, I need to reconcile those.
--
___
Python tracker
<http://bugs.python.org/issue24
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 is to
Christie added the comment:
Created issue24398 for updating test_capi.
--
___
Python tracker
<http://bugs.python.org/issue9517>
___
___
Python-bugs-list mailin
Christie added the comment:
Created Issue24279 for updating test_base64.
--
___
Python tracker
<http://bugs.python.org/issue9517>
___
___
Python-bugs-list mailin
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
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 is to
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
<http://bugs.python.org/issue15
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
<http://bugs.python.org/is
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
<http://bugs.python.org/issue9
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 tr
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
<http://bugs.python.org/issue9517>
___
___
Python-bugs-list mailing list
Unsub
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
>
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
<http://bugs.python.org/issue9
Christie added the comment:
I am working on this!
--
___
Python tracker
<http://bugs.python.org/issue24033>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 is to
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 unus
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 t
Christie added the comment:
I am working on this now.
--
___
Python tracker
<http://bugs.python.org/issue23981>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
<http://bugs.python.
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 is to
Christie added the comment:
So @flipmcf we're sticking with the test.support.script_helper namespace?
--
___
Python tracker
<http://bugs.python.org/i
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 i
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
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 "", line 1, in
ImportError: No module named 'test.sup
Christie added the comment:
Okee dokee, I'll tackle that first!
--
___
Python tracker
<http://bugs.python.org/issue9517>
___
___
Python-bugs-list m
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
<http://bugs.python.
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 op
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 a
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 *shoul
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-A
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': '☃'}
>
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* by
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.
* In
New submission from Tom Christie :
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, then the r
55 matches
Mail list logo
