On Sat, 4 Dec 1999, M.-A. Lemburg wrote: >... > > Don't worry Fredrik... I'm with you on this one. I do not believe there is > > a problem with the speed. Nobody has yet profiled imputil to find out > > where/how the time is being spent. Nobody has tried to speed it up. > > Sorry, Greg, but that is simply not true. I've spend a few > days on trying to get more performance out of it and have > succeeded, but in the end it wasn't enough to convince me > of the approach. You sent me your changes... I don't believe that you were aggressive enough. As I've mentioned before, I think it is quite possible to retain the general Importer style and get_code() interface, but to shift some functionality out (to be computed once) to a higher-level mechanism. The patches that you sent me did not do this, so I'm not surprised that you hit a wall. Ack. See? Now I'm getting into discussions about performance and implementation without truly knowing where the timing is spent. Eyeballing it, I have an idea, but it would be best too see a profile output. My mantra is always "90% of the time you're wrong about where 90% of the time is being spent." I am unconcerned about performance, but will work on it so that I don't need to continue this conversation. That burden is on me. > > Therefore, any claims about its performance are simply FUD. > > BTW, did anybody mention that an import manager wouldn't > be able to provide an API which is useable for imputil > style importers ? I'm not argueing against the possibility > to use imputil style importers, just against making it the > sole method of adding wisdom to Python imports. Since the core will delegate out to Python (note: current working theory), then it certainly is not the "sole method" (since you can just replace the Python code). But there must be a default mechanism. The ihooks stuff was too complicated. imputil seems to be much easier. I'd love to see a third mechanism.... so I can steal ideas :-) > The imputil importers could well benefit from a manager > providing logic to do basic things like importing > shared libs, checking signatures, downloading modules > from the web, etc. For shared libs, yes. For the others: geez... I don't want to see that in the core infrastructure. Shift that out to specialized Importers. The infrstructure ought to be teeny and agnostic about how to map a module name to a module. Side note to python-dev people: I apologize... I realize that I'm beginning to get a bit defensive here. I'm going to be at XML '99 until Friday, so that should give me a breather. When I get back, I'll skip the talk and do some code. Cheers, -g -- Greg Stein, http://www.lyra.org/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4