"Michael J. Fromberger" <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]:
> In article <[EMAIL PROTECTED]>, > Rick Wotnaz <[EMAIL PROTECTED]> wrote: > >> Michael Hoffman <[EMAIL PROTECTED]> wrote in >> news:[EMAIL PROTECTED]: >> >> > What would people think about adding sys to __builtins__ so >> > that "import sys" is no longer necessary? This is something I >> > must add to every script I write that's not a one-liner since >> > they have this idiom at the bottom: >> > >> > if __name__ == "__main__": >> > sys.exit(main(sys.argv[1:])) >> > >> > [...] >> > >> > In short, given the wide use of sys, its unambiguous nature, >> > and the fact that it really is built-in already, although not >> > exposed as such, I think we would be better off if sys were >> > always allowed even without an import statement. >> >> +1 here. As far as I'm concerned, both os and sys could be >> special- cased that way. That said, I would guess the >> likelihood of that happening is 0. > > While I'm mildly uncomfortable with the precedent that would be > set by including the contents of "sys" as built-ins, I must > confess my objections are primarily aesthetic: I don't want to > see the built-in namespace any more cluttered than is necessary > -- or at least, any more than it already is. > > But "os" is another matter -- the "os" module contains things > which might well not be present in an embedded Python > environment (e.g., file and directory structure navigation, > stat). Do you really want to force everyone to deal with that? > Is it so much more work to add "import os" to those Python > programs that require it? > > Of course, you might counter "why should we force everybody else > to type `import os' just in case somebody wants to imbed > Python?" But then, why don't we just include the whole standard > library in __builtins__? Or, since that would be too much, > maybe we survey the user community and include the top fifteen > most included modules! Where do you draw the line? Do you > really want to hard-code user opinions into the language? > > Right now, we have a nice, simple yet effective mechanism for > controlling the contents of our namespaces. I don't think this > would be a worthwhile change. -1. > You're right that there is no necessity for such a change. I was not actually talking about importing *any* module in every case, but rather about importing, say, 'sys' when, for example, sys.argv appeared in the code and no import had been specified. In another post I go into a little more detail about what I meant, but in any case I did not and do not think it's necessary. I have no problem keying in the import statement and the current system works fine. It could be argued that it would be convenient in the case of quick utility code not to have to import well-known modules explicitly, and it could be argued that 'sys' in particular contains much that is so seemingly fundamental that it could be built in. I'd not argue that it should be split out if it were already built in; it seems to be borderline standard as it is. I suppose it's a C mindset talking, there. When I'm cobbling together a Q&D script, my routine often involves running it once and then going back in and inserting the single import line that I forgot. It's a minor annoyance, because it seems clear to me that the needed information is actually available to Python when it kicks out its NameError. But it *is* minor, and I am not seriously proposing a change to Python in this regard. -- rzed -- http://mail.python.org/mailman/listinfo/python-list
