Changes by Shivaram Lingamneni sling...@cs.stanford.edu:
--
nosy: +slingamn
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue16298
___
___
Python
Shivaram Lingamneni added the comment:
Are there any possible next steps on this?
This issue is very counterintuitive and challenging to debug --- it commonly
presents as a nondeterministic edge case, and it appears to be a failed system
call but doesn't show up in strace.
Thanks for your
Shivaram Lingamneni added the comment:
I wanted to check in about the status of this patch. Here's the case for the
patch, as I understand it:
1. It is not a novel optimization, it just consistently applies design
decisions that were made previously (RFE #1472176 and bpo-22127).
2
New submission from Shivaram Lingamneni :
Importing the idna encoding has a significant time and memory cost. Therefore,
the standard library tries to avoid importing it when it's not needed (i.e.
when the domain name is already pure ASCII), e.g. in Lib/http/client.py and
Modules
Change by Shivaram Lingamneni :
--
keywords: +patch
pull_requests: +29484
stage: -> patch review
pull_request: https://github.com/python/cpython/pull/31328
___
Python tracker
<https://bugs.python.org/issu
Shivaram Lingamneni added the comment:
Thanks for the prompt response. As evidence that this was of concern to the
development team in the past, here's an issue where the unnecessary import of
idna was treated as a regression:
https://bugs.python.org/issue22127
The discussion there also
Shivaram Lingamneni added the comment:
Sorry, I should have been more clear: I am including the initial costs of
importing stringprep and unicodedata. On my system:
$ python3 -c "import time; start = time.time(); r = 'a'.encode('idna'); elapsed
= time.time() - start; print(el
Shivaram Lingamneni added the comment:
(Looks like it was 15 milliseconds when measuring inside `python -i`; I'm not
sure what the root cause of the difference is, but clearly the 5 millisecond
measurement from regular `python` is more accurate
