Proposal: add sys to __builtins__

[Michael Hoffman]

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(s ys.argv[1:]))

Additionally, the necessity of "import sys" makes some one-liners a
little more unwieldy than they should be--it is surely the module I am
missing the most in one-liners. For example, with this proposal, this
inelegant one-liner:

$ python -c "import sys; print ''.join(sorted( sys.stdin.readl ines()))"

could be replaced by:

$ python -c "print ''.join(sorted( sys.stdin.readl ines()))"

Since sys is surely the most commonly used module (it is imported in 108
of 188 Python 2.4 stdlib modules on my system, and certainly more than
any other module), I would hope few people would be affected by a
namespace collision.

Other languages (e.g. C#) always make their system namespace available
without needing a special import.

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.
--
Michael Hoffman

[Rick Wotnaz]

Re: Proposal: add sys to __builtins__

Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote in
news:df7jlu$1te $1@gemini.csx.c am.ac.uk:
[color=blue]
> 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(s ys.argv[1:]))
>
> Additionally, the necessity of "import sys" makes some
> one-liners a little more unwieldy than they should be--it is
> surely the module I am missing the most in one-liners. For
> example, with this proposal, this inelegant one-liner:
>
> $ python -c "import sys; print
> ''.join(sorted( sys.stdin.readl ines()))"
>
> could be replaced by:
>
> $ python -c "print ''.join(sorted( sys.stdin.readl ines()))"
>
> Since sys is surely the most commonly used module (it is
> imported in 108 of 188 Python 2.4 stdlib modules on my system,
> and certainly more than any other module), I would hope few
> people would be affected by a namespace collision.
>
> Other languages (e.g. C#) always make their system namespace
> available without needing a special import.
>
> 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.[/color]

+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.

--
rzed

[Steve Holden]

Re: Proposal: add sys to __builtins__

Rick Wotnaz wrote:[color=blue]
> Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote in
> news:df7jlu$1te $1@gemini.csx.c am.ac.uk:
>
>[color=green]
>>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(s ys.argv[1:]))
>>
>>Additionall y, the necessity of "import sys" makes some
>>one-liners a little more unwieldy than they should be--it is
>>surely the module I am missing the most in one-liners. For
>>example, with this proposal, this inelegant one-liner:
>>
>>$ python -c "import sys; print
>>''.join(sorte d(sys.stdin.rea dlines()))"
>>
>>could be replaced by:
>>
>>$ python -c "print ''.join(sorted( sys.stdin.readl ines()))"
>>
>>Since sys is surely the most commonly used module (it is
>>imported in 108 of 188 Python 2.4 stdlib modules on my system,
>>and certainly more than any other module), I would hope few
>>people would be affected by a namespace collision.
>>
>>Other languages (e.g. C#) always make their system namespace
>>available without needing a special import.
>>
>>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.[/color]
>
>
> +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.
>[/color]
I wonder if it would be worth special-casing the AttributeError
exception handling at the outermost lexical scope to try and import a
module with the troublesome name and then retrying the attribute access
if the import succeeded (possibly even from a path limited to the
standard locations).

That way none of the standard library modules would need to be imported
before use.

I can see that this would create problems as well as solving some, but
it would be nice not to have to import the standard library modules. I
don't personally find it a hardship, but some people do.

though-i-could-just-be-raving-ly y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/

[MrJbQ7]

Re: Proposal: add sys to __builtins__

Steve Holden wrote:[color=blue]
> I wonder if it would be worth special-casing the AttributeError [snip][/color]

What is it that Tim Peters said? "Special cases aren't special
enough..."

Besides, a better way is to use your ~/.pythonrc file for customizing
according to your needs.

A simple:

echo "import sys, os" >> ~./pythonrc

will do the job.

Thanks,
John Benediktsson

[Michael Hoffman]

Re: Proposal: add sys to __builtins__

MrJbQ7 wrote:[color=blue]
> Steve Holden wrote:
>[color=green]
>>I wonder if it would be worth special-casing the AttributeError [snip][/color]
>
> What is it that Tim Peters said? "Special cases aren't special
> enough..."[/color]

That suggestion is a little too much magic for me.
[color=blue]
> Besides, a better way is to use your ~/.pythonrc file for customizing
> according to your needs.
>
> A simple:
>
> echo "import sys, os" >> ~./pythonrc
>
> will do the job.[/color]

Until someone else tries to use your script or module.
--
Michael Hoffman

[tiissa]

Re: Proposal: add sys to __builtins__

Michael Hoffman a écrit :
[color=blue]
> MrJbQ7 wrote:
>[color=green]
> > Besides, a better way is to use your ~/.pythonrc file for customizing
> > according to your needs.
> >
> > A simple:
> >
> > echo "import sys, os" >> ~./pythonrc
> >
> > will do the job.[/color]
>
> Until someone else tries to use your script or module.[/color]

A developper should not be too lazy to add one small line in a complete
script/module.
Besides your entire justification to this proposal was based on shell
one-liners, not script or modules.

[Michael Hoffman]

Re: Proposal: add sys to __builtins__

tiissa wrote:
[color=blue]
> A developper should not be too lazy to add one small line in a complete
> script/module.[/color]

To the contrary, I agree with Larry Wall that laziness is one of the
cardinal virtues of a programmer. Although my personal desire to be lazy
is not at issue here--I always start new scripts and modules from a
template that includes import sys.

Would you argue that the language is superior because half of its
modules must have "import sys" at the beginning, although sys is already
imported? The only difference is that the namespace is not exposed by
default. I suggest that the default be changed.

It would simplify introductions to the language as well. In the current
tutorial it is necessary to use "import sys" before it has time to
explain modules and importing.
[color=blue]
> Besides your entire justification to this proposal was based on shell
> one-liners, not script or modules.[/color]

Sorry, that's incorrect; please go back and read the original post again.
--
Michael Hoffman

[Paul Watson]

Re: Proposal: add sys to __builtins__

Steve Holden wrote:[color=blue]
> Rick Wotnaz wrote:
>[color=green]
>> Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote in
>> news:df7jlu$1te $1@gemini.csx.c am.ac.uk:
>>[color=darkred]
>>> 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(s ys.argv[1:]))
>>>
>>> Additionally, the necessity of "import sys" makes some
>>> one-liners a little more unwieldy than they should be--it is
>>> surely the module I am missing the most in one-liners. For
>>> example, with this proposal, this inelegant one-liner:
>>>
>>> $ python -c "import sys; print
>>> ''.join(sorted( sys.stdin.readl ines()))"
>>> could be replaced by:
>>>
>>> $ python -c "print ''.join(sorted( sys.stdin.readl ines()))"
>>>
>>> Since sys is surely the most commonly used module (it is
>>> imported in 108 of 188 Python 2.4 stdlib modules on my system,
>>> and certainly more than any other module), I would hope few
>>> people would be affected by a namespace collision.
>>>
>>> Other languages (e.g. C#) always make their system namespace
>>> available without needing a special import.
>>>
>>> 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.[/color]
>>
>>
>>
>> +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.[/color]
>
> I wonder if it would be worth special-casing the AttributeError
> exception handling at the outermost lexical scope to try and import a
> module with the troublesome name and then retrying the attribute access
> if the import succeeded (possibly even from a path limited to the
> standard locations).
>
> That way none of the standard library modules would need to be imported
> before use.
>
> I can see that this would create problems as well as solving some, but
> it would be nice not to have to import the standard library modules. I
> don't personally find it a hardship, but some people do.
>
> though-i-could-just-be-raving-ly y'rs - steve[/color]

This sounds pretty interesting. How about a switch to invoke this
handling for the one-liner crowd and those who wish to use it?

Somehow, I never heard any C programmers suggest that the default
processing not include the need for:

#include <stdio.h>

[tiissa]

Re: Proposal: add sys to __builtins__

Michael Hoffman wrote:[color=blue]
> To the contrary, I agree with Larry Wall that laziness is one of the
> cardinal virtues of a programmer.[/color]

There's lazy and too lazy.
You don't want to be too lazy to even get out of bed to code in Python.
Of course, with Perl, that's entirely another mattress^Wmatte r.

[color=blue]
> Would you argue that the language is superior because half of its
> modules must have "import sys" at the beginning[/color]

I wouldn't dare arguing about superiority.

I was just stating your proposal didn't really solve anything. A good
editor/template and .pythonrc already save you the typing of 'import
sys' in scripts for the former and shell command for the latter.

[color=blue]
> Sorry, that's incorrect[/color]

Alright, that was a bit of an overstatement.
I should have said your proposal is perceptibly useful in those shell
one-liners. The distribution of script and modules is another matter.


As for my opinion, you've already guessed I don't perceive 'import sys'
as an issue. Therefore, the special case of an implicit import of sys
does not appeal to me.

[Xiao Jianfeng]

Re: Proposal: add sys to __builtins__

Paul Watson wrote:
[color=blue]
>This sounds pretty interesting. How about a switch to invoke this
>handling for the one-liner crowd and those who wish to use it?
>
>
>[/color]
[color=blue]
>Somehow, I never heard any C programmers suggest that the default
>processing not include the need for:
>
>#include <stdio.h>
>
>[/color]
I think it is because that we cannot modify the C language, but
python is a language that's still evolving.

[Colin J. Williams]

Re: Proposal: add sys to __builtins__

Rick Wotnaz wrote:[color=blue]
> Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote in
> news:df7jlu$1te $1@gemini.csx.c am.ac.uk:
>
>[color=green]
>>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(s ys.argv[1:]))
>>
>>Additionall y, the necessity of "import sys" makes some
>>one-liners a little more unwieldy than they should be--it is
>>surely the module I am missing the most in one-liners. For
>>example, with this proposal, this inelegant one-liner:
>>
>>$ python -c "import sys; print
>>''.join(sorte d(sys.stdin.rea dlines()))"
>>
>>could be replaced by:
>>
>>$ python -c "print ''.join(sorted( sys.stdin.readl ines()))"
>>
>>Since sys is surely the most commonly used module (it is
>>imported in 108 of 188 Python 2.4 stdlib modules on my system,
>>and certainly more than any other module), I would hope few
>>people would be affected by a namespace collision.
>>
>>Other languages (e.g. C#) always make their system namespace
>>available without needing a special import.
>>
>>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.[/color]
>
>
> +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.
>[/color]
+1 for both.

Colin W.

[Terry Reedy]

Re: Proposal: add sys to __builtins__


"Colin J. Williams" <cjw@sympatico. ca> wrote in message
news:JEBSe.55$v N.6924@news20.b ellglobal.com.. .[color=blue]
> Rick Wotnaz wrote:[color=green]
>> +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.
>>[/color]
> +1 for both.[/color]

Some people might prefer that math be special cased. Or some other module.
A neutral criterion is needed.

Terry J. Reedy

[Rick Wotnaz]

Re: Proposal: add sys to __builtins__

"Terry Reedy" <tjreedy@udel.e du> wrote in
news:mailman.12 0.1125883780.42 49.python-list@python.org :
[color=blue]
>
> "Colin J. Williams" <cjw@sympatico. ca> wrote in message
> news:JEBSe.55$v N.6924@news20.b ellglobal.com.. .[color=green]
>> Rick Wotnaz wrote:[color=darkred]
>>> +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.
>>>[/color]
>> +1 for both.[/color]
>
> Some people might prefer that math be special cased. Or some
> other module. A neutral criterion is needed.
>[/color]

Actually, I don't think it's beyond reason to suggest that any
module included with the standard distribution be special-cased in
this way. That is, a reference to xxx.func(), without a previous
import of xxx *could* be resolvable automatically, at least for
those modules that can be found in a standard location. Whether
it's a good idea to do so is another question.

Offhand, I am not sure why it would be an insanely poor idea. It
would mean some funky namespace building and possibly redundant
imports, I guess. I'll certainly defer to just about anybody else's
opinion as to the difficulty and advisability, but I believe it
would be possible to do.

Note that I am not saying that a reference to, say, 'argv' should
provoke an automatic import. I don't mean that some automatic
search for a matching function name should be done through some
undefined module chain. I'm talking only about qualified
references, like os.path or sys.stderr.

As it is, a NameError is generated if the proper import has not
been done. At the point of that error, the module name is known.
For the programmer to fix the situation, an import statement has to
be added to the code and then the code must be rerun. I don't see
why it would be impossible to make that happen automatically,
provided the module to be imported was recognized (through some
undefined magic). I'd think the module would have to be known,
because trying to import a nonexistent module -- "import ssy", say
(in the event of a typo for "sys") -- would fail, so there would
have to be a way to avoid looping on the "ssy.func() " line.

Is it worth adding that kind of complexity to execution of a Python
program? Probably not.

Is it even a good idea to try to make it happen automatically?
Possibly not. For one thing, it wouldn't always be the right thing
to do. A developer would most likely want to set up the imports
properly, and to know when they were not correctly set up instead
of having Python fix things quietly. There's a reason why Explicit
is better than Implicit.

But *could* it be done? I'd think so.

--
rzed

[Sybren Stuvel]

Re: Proposal: add sys to __builtins__

Rick Wotnaz enlightened us with:[color=blue]
> That is, a reference to xxx.func(), without a previous import of xxx
> *could* be resolvable automatically, at least for those modules that
> can be found in a standard location.[/color]

-1 on that one. If I want to use a module, I'll write an import
statement for it. Those import statements make it very easy to get an
overview of the modules in use.

Automatically importing modules has the counter-effect of not
generating errors when they should be. Someone could have a class
stored in a variable 'os' and call a function on it. If this person
forgets to assign a value to 'os', an error message should be given
instead of importing the 'os' module.

Another issue is speed. If every reference in the form xxx.yyy has to
trigger an import when xxx isn't known, it will probably slow down
programs quite badly.

A programming language should not be ambiguous. The choice between
importing a module and calling a function should not depend on the
availability of a (local) variable.
[color=blue]
> I don't see why it would be impossible to make that happen
> automatically, provided the module to be imported was recognized
> (through some undefined magic).[/color]

The question is not if it's possible or not - in principle, everything
is possible. The question is if it is desirable.
[color=blue]
> A developer would most likely want to set up the imports properly,
> and to know when they were not correctly set up instead of having
> Python fix things quietly.[/color]

Yep.
[color=blue]
> But *could* it be done? I'd think so.[/color]

Sure.

Sybren
--
The problem with the world is stupidity. Not saying there should be a
capital punishment for stupidity, but why don't we just take the
safety labels off of everything and let the problem solve itself?
Frank Zappa

[Michael J. Fromberger]

Re: Proposal: add sys to __builtins__

In article <Xns96C4A9300C9 39reederz@63.22 3.7.253>,
Rick Wotnaz <desparn@wtf.co m> wrote:
[color=blue]
> Michael Hoffman <cam.ac.uk@mh39 1.invalid> wrote in
> news:df7jlu$1te $1@gemini.csx.c am.ac.uk:
>[color=green]
> > 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(s ys.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.[/color]
>
> +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.[/color]

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.

-M

--
Michael J. Fromberger | Lecturer, Dept. of Computer Science
http://www.dartmouth.edu/~sting/ | Dartmouth College, Hanover, NH, USA