M.-A. Lemburg <mal@lemburg.com> wrote: > > given a name, check if you have a > > module with that name, and install > > it. if you cannot, fail (in which case > > python asks the next importer along > > the path). > > > > why do you have to complicate things beyond that? > > why not just let Python provide a few base classes > > and mixins for people who want to create custom > > importers, and be done with it? > > Because importing in Python has become *much* more > complicated over time. There are requests for new > features which touch subjects such as storage mechanisms, > lookups, signatures (for trusted code), lazy imports, etc. sorry, I still don't understand it. our applications already use different storage mechanisms, databases, signatures, lazy importing, version handling, etc, etc. now, if *we* have managed to build all that on top of an old version of imputil.py, how come it's not sufficient for the rest of you? > A chain of simple minded importers won't work together > too well why? it sure works for us... > duplicate work avoiding duplicate work is what object oriented design is all about. and last time I checked, Python had excellent support for that. > and downgrade performance considerably due to the > many recursive function calls now that's what I call premature optimization. and this scares the hell out of me: if the rest of the python-dev crowd don't seriously believe that Python is (or can be made) fast enough to implement things like this, why the heck are you using Python at all? am I the only one here who doesn't believe in osterhout's talk about "the great system vs. scripting language divide"? </F>
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