Brett, thanks for persevering on importlib! Given how complicated imports are in Python, I really appreciate you pushing this forward. I've been knee deep in both import.c and importlib at various times. ;)
On Feb 07, 2012, at 03:07 PM, Brett Cannon wrote: >One is maintainability. Antoine mentioned how if change occurs everyone is >going to have to be able to fix code in importlib, and that's the point! I >don't know about the rest of you but I find Python code easier to work with >than C code (and if you don't you might be subscribed to the wrong mailing >list =). I would assume the ability to make changes or to fix bugs will be >a lot easier with importlib than import.c. So maintainability should be >easier when it comes to imports. I think it's *really* critical that importlib be well-documented. Not just its API, but also design documents (what classes are there, and why it's decomposed that way), descriptions of how to extend and subclass, maybe even examples for doing some typical hooks. Maybe even a guided tour or tutorial for people digging into importlib for the first time. >So, that is the positives. What are the negatives? Performance, of course. That's okay. Get it complete, right, and usable first and then unleash the Pythonic hoards to bang on performance. >IOW I really do not look forward to someone saying "importlib is so much >slower at importing a module containing ``pass``" when (a) that never >happens, and (b) most programs do not spend their time importing but >instead doing interesting work. Identifying the use cases are important here. For example, even if it were a lot slower, Mailman wouldn't care (*I* might care because it takes longer to run my test, but my users wouldn't). But Bazaar or Mercurial users would care a lot. -Barry _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
