Message292563
I believe importing argparse in the __main__ clause (or a main or test function called therein) is common. I prefer it there as it is not germain to the code that is usually imported. I have a similar view on not immediately importing warnings when only needed for deprecation.
I am interested in argparse import time because I have thought about switching IDLE arg processing from getopt to argparse. But both IDLE and user process startup time are already slow enough. (For IDLE, the numbers for Serhiy's import counter for 3.6 on Win 10 with idlelib.idle instead of argparse are 38 192 154.
I recently sped up user process startup (performed each time one 'runs' code from the editor) by around 25% (.1 second on my machine, just noticeable) by a few fairly straightforword changes. For idlelib.run, the import numbers are 40 182 142 in 3.5.3 and 38 138 100 in 3.6.1. I probably can improve this further, but each change would have to be justified on its own. So I think it appropriate to start with a subset of possible speedup changes for argparse. |
|
Date |
User |
Action |
Args |
2017-04-29 04:26:54 | terry.reedy | set | recipients:
+ terry.reedy, rhettinger, pitrou, bethard, vstinner, christian.heimes, berker.peksag, paul.j3, serhiy.storchaka, wolma, yan12125 |
2017-04-29 04:26:53 | terry.reedy | set | messageid: <1493440013.93.0.700273672418.issue30152@psf.upfronthosting.co.za> |
2017-04-29 04:26:53 | terry.reedy | link | issue30152 messages |
2017-04-29 04:26:52 | terry.reedy | create | |
|