[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Christie added the comment: Created issue24398 for updating test_capi. -- ___ Python tracker <http://bugs.python.org/issue9517> ___ ___ Python-bugs-list mailin

[issue24398] Update test_capi to use test.support.script_helper

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

[issue18576] Document test.support.script_helper

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

[issue24033] Update _test_multiprocessing.py to use script helpers

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

[issue24398] Update test_capi to use test.support.script_helper

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

[issue23981] Update test_unicodedata.py to use script_helpers

Changes by Christie : -- nosy: +berker.peksag, ezio.melotti, r.david.murray ___ Python tracker <http://bugs.python.org/issue23981> ___ ___ Python-bugs-list mailin

[issue24279] Update test_base64 to use test.support.script_helper

Changes by Christie : -- nosy: +berker.peksag, ezio.melotti, r.david.murray ___ Python tracker <http://bugs.python.org/issue24279> ___ ___ Python-bugs-list mailin

[issue18576] Document test.support.script_helper

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

[issue23981] Update test_unicodedata.py to use script_helpers

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

[issue24279] Update test_base64 to use test.support.script_helper

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

[issue24033] Update _test_multiprocessing.py to use script helpers

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

[issue24033] Update _test_multiprocessing.py to use script helpers

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue18576] Document test.support.script_helper

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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.

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Christie added the comment: Okee dokee, I'll tackle that first! -- ___ Python tracker <http://bugs.python.org/issue9517> ___ ___ Python-bugs-list m

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Christie added the comment: So @flipmcf we're sticking with the test.support.script_helper namespace? -- ___ Python tracker <http://bugs.python.org/i

[issue23981] Update test_unicodedata.py to use script_helpers

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

[issue23981] Update test_unicodedata.py to use script_helpers

Christie added the comment: I am working on this now. -- ___ Python tracker <http://bugs.python.org/issue23981> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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.

[issue23981] Update test_unicodedata.py to use script_helpers

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue24033] Update _test_multiprocessing.py to use script helpers

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

[issue24033] Update _test_multiprocessing.py to use script helpers

Christie added the comment: I am working on this! -- ___ Python tracker <http://bugs.python.org/issue24033> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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 >

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Christie added the comment: Thanks very much @berker.peksag! -- ___ Python tracker <http://bugs.python.org/issue9517> ___ ___ Python-bugs-list mailing list Unsub

[issue24033] Update _test_multiprocessing.py to use script helpers

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

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

[issue18576] Document test.support.script_helper

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

[issue15376] Refactor the test_runpy walk_package support code into a common location

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

[issue24279] Update test_base64 to use test.support.script_helper

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

[issue24279] Update test_base64 to use test.support.script_helper

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

[issue9517] Make test.script_helper more comprehensive, and use it in the test suite

Christie added the comment: Created Issue24279 for updating test_base64. -- ___ Python tracker <http://bugs.python.org/issue9517> ___ ___ Python-bugs-list mailin

[issue39758] StreamWriter.wait_closed() can hang indefinately.

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

[issue14042] json.dumps() documentation is slightly incorrect.

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

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

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

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

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

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

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

[issue36709] Asyncio SSL keep-alive connections raise errors after loop close.

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

[issue33366] `contextvars` documentation incorrectly refers to "non-local state".

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

[issue33366] `contextvars` documentation incorrectly refers to "non-local state".

Tom Christie added the comment: Refs: https://github.com/python/cpython/pull/6617 -- ___ Python tracker <https://bugs.python.org/issue33366> ___ ___ Python-bug

[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x

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

[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x

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

[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x

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': '☃'} >

[issue22767] `separators` argument to json.dumps() behaves unexpectedly across 2.x vs 3.x

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

[issue18290] json encoder does not support JSONP/JavaScript safe escaping

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

[issue18290] json encoder does not support JSONP/JavaScript safe escaping

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

[issue1043134] Add preferred extensions for MIME types

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.