> Fredrik> what's the point? doesn't from-import already do > Fredrik> exactly that on C extensions? [Skip Montanaro] > Consider os. At one point it does "from posix import *". Okay, which > symbols now in its local namespace came from posix and which from its > own devices? It's a lot easier to do > > from posix import __all__ as _all > __all__.extend(_all) > del _all > > than to muck about importing posix, looping over its dict, then > incorporating what it finds. > > It also makes things a bit more consistent for introspective tools. I'm afraid I find it hard to believe people will *keep* C-module __all__ lists in synch with the code as the years go by. If we're going to do this, how about adding code to Py_InitModule4 that sucks the non-underscore names out of its PyMethodDef argument and automagically builds an __all__ attr? Then nothing ever needs to be fiddled by hand for C modules. but-unsure-i-like-__all__-at-all-ly y'rs - tim
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