On Tue, May 26, 2015 at 10:06 PM, Oleg Broytman
On Tue, May 26, 2015 at 09:05:06PM +0300, anatoly techtonik
wrote: On Fri, May 22, 2015 at 1:58 PM, Oleg Broytman
wrote: On Fri, May 22, 2015 at 12:59:30PM +0300, anatoly techtonik
wrote: Is the idea to have timer that starts on import is good?
No, because:
-- it could be imported at the wrong time;
Any time is right.
Very much application-dependent. What if you wanna measure import time?
The design principle is that default behaviour is designed: 1. most simple/intuitive thought 2. most often needed operation Every "what if" means you need to do non-default customization, such as care to place starttimer into your bootstrap script. If you want to trace, when exactly the module is imported, it can record the caller full name sys.path:module.class.method (provided that Python supports this), and lines executed from the Python start.
-- it couldn't be "reimported"; what is the usage of one-time timer?
The idea is to have convenient default timer to measure script run-time.
Good idea for a small separate project. Bad for the stdlib. Not every small simple useful module must be in the stdlib.
Yes. That's not a criteria. The criteria that modules that save time during development should come with bundled. Or another idea - the stdlib should provide a standard layout that people can replicate in their "shed" repositories on Github. Then by crawling these repositories, the names and contents could be aggregated into stats to see what are the most popular imports. That way it will be quickly to identify useful stuff that people coming from other languages find missing in Python. Also, it will allow people to document the behavior differences for modules named the same. -- anatoly t.