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]

Michael Hoffman <ca*******@mh39 1.invalid> wrote in
news:df******** **@gemini.csx.c am.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(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.

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

Rick Wotnaz wrote:

Michael Hoffman <ca*******@mh39 1.invalid> wrote in
news:df******** **@gemini.csx.c am.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(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.

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

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 [phone] [phone]
Holden Web LLC http://www.holdenweb.com/

[MrJbQ7]

Steve Holden wrote:

I wonder if it would be worth special-casing the AttributeError [snip]

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]

MrJbQ7 wrote:

Steve Holden wrote:

I wonder if it would be worth special-casing the AttributeError [snip]
What is it that Tim Peters said? "Special cases aren't special
enough..."

That suggestion is a little too much magic for me.
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.

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

[tiissa]

Michael Hoffman a écrit :

MrJbQ7 wrote:

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.

Until someone else tries to use your script or module.

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]

tiissa wrote:

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

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

[Paul Watson]

Steve Holden wrote:

Rick Wotnaz wrote:

Michael Hoffman <ca*******@mh39 1.invalid> wrote in
news:df******** **@gemini.csx.c am.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(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.

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

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

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]

Michael Hoffman wrote:

To the contrary, I agree with Larry Wall that laziness is one of the
cardinal virtues of a programmer.
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.

Would you argue that the language is superior because half of its
modules must have "import sys" at the beginning
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.

Sorry, that's incorrect

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]

Paul Watson wrote:

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>

I think it is because that we cannot modify the C language, but
python is a language that's still evolving.