Proposal: add sys to __builtins__

[Rick Wotnaz]

"Michael J. Fromberger"
<Michael.J.Fromberger at Clothing.Dartmouth.EDU> wrote in
news:Michael.J.Fromberger-3F0330.09342305092005 at localhost: 

> In article <Xns96C4A9300C939reederz at 63.223.7.253>,
>  Rick Wotnaz <desparn at wtf.com> wrote:
> 
>> Michael Hoffman <cam.ac.uk at mh391.invalid> wrote in
>> news:df7jlu$1te$1 at gemini.csx.cam.ac.uk: 
>> 
>> > 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