eric wrote: [Frederic Giacometti] > > because the obvious reason of increased name space collision, > > increased run-time overhead etc... > > I'm missing something here because I don't understand why this > increases name space collision. Currently, os.py in a package masks the real one from anywhere inside the package. This would extend that to anywhere inside any nested subpackage. Whether that's a "neat" or a "dirty" trick is pretty subjective. The wider the namespace you can trample on, the more it tends to be "dirty". > If the objection is to the fact > that SciPy can have a version of Numeric in it that masks a > Numeric installed in site-packages, I guess I consider this a > feature, not a bug. Afterall, this is already the behavior for > single level packages, extending it to multi-level packages seems > natural. If this isn't your objection, please explain. Well, it's a feature that can crash Python. If the package (which the user has, and you have a hijacked, incompatible copy of) contains an extension module, all kinds of nasty things can happen when both are loaded. Submit patches to the package authors, or require a specific version, or write a wrapper that adapts to different versions or fork or do without. This is definitely a dirty trick. > The current runtime overhead isn't so bad. Under anything near normal usage, no - packages structures are nearly always shallow. It wouldn't be much work to construct a case where time spent in import doubled, however. When the "try relative, then try absolute" strategy was introduced with packages, it added insignificant overhead. It's not so insignificant now. When (and if) the standard library moves to a package structure, it's possilbe it will be seen as a burden. - Gordon
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