> I wasn't thinking of this from a security POV -- more from the
> perspective of trying to understand roughly what a module does.
> Looking at the imports is often a good place to start.
In the case of open(), this may be a false benefit. Too many other calls
(logging, shelve, etc) can open files, so the presence or absence of an IO
import is not a reliable indicator of anything.
Also, the character of a script doesn't change when it decides to switch from
stdin/stdout to actual files. I don't think we gain anything here and are
instead adding a small irritant. The open() function is so basic, it should
remain a builtin. In theory, all builtins could be moved to other modules, but
in practice it would be a PITA for day-to-day script writing.
I enjoy being able to dash off quick, expressive lines like this:
for i, line in enumerate(open('data.txt')): ...
Needing an import for that frequently used function would detract from the
enjoyment.
Taking a more global viewpoint, I'm experiencing a little FUD about Py3k.
There were good reasons for introducing the print() function, but then we've
made "hello world" a little less lightweight. Larger applications have some
legitimate needs which make abstract base classes attractive, but they are
going to add significantly to the learning curve for beginners when using APIs
that require them. Packages were introduced to address the needs of large
applications and complicated namespace issues, but now we're about to split the
trivially simple string module into a package. One of the design goals should
be to keep the core language as trivially simple/straightforward as possible
for day-to-day use. Requiring an import for file opening runs contrary to that
goal.
Raymond
_______________________________________________
Python-3000 mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
