On Tue, Feb 7, 2012 at 15:24, Barry Warsaw <ba...@python.org> wrote: > 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. >
That's fine and not difficult to do. > > >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. > Right, which is why I'm looking for some agreed upon, concrete benchmark I can use which isn't fluff. -Brett > > -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/brett%40python.org >
_______________________________________________ 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