putting on my "on the other hand" hat for a moment...
:::
Guido van Rossum wrote:
> 1. It's always been there
> 2. We don't want to type parentheses
> 3. We use it a lot
> 4. We don't want to change our code
there's also:
5. A reserved word makes it easy to grep for (e.g. to weed out
debugging prints before release).
6. It does the right thing under the hood: converts things to their
string representation, calls write repeatedly instead of allocating
a buffer large enough to hold all components, doesn't print un-
necessary trailing spaces, etc.
7. Using a statement syntax makes it possible to use a readable
syntax for redirection (and other possible extensions); it's obvious
that this isn't printing to stdout:
print >>file, bacon(ham), spam, "=", eggs(number=count)
while
print(bacon(ham), spam, "=", eggs(number=count), to=file)
is a lot harder to parse, especially if you add more elements and
print lines (how fast can you answer the question "do all these
redirect to the same place" ?).
8. It can print to anything that implements a "write" method, no
matter what it is or what other methods it implements.
(etc)
:::
and my "on the other hand" gloves...
> - I quite often come to a point in the evolution of a program where I
> need to change all print statements into logging calls, or calls into
> some other I/O or UI library.
never happens to me -- in my experience, good logging requires
some basic design up front, so you might as well log via functions
right from the start. print is reserved for debugging, tracing during
development, and console-oriented scripts. I cannot recall ever
having converted one of the latter to a component that needed
logging.
> - Having special syntax puts up a much larger barrier for evolution of
> a feature.
on the other hand, having special syntax gives you a lot more flexibility
in coming up with readable, grokkable solutions. not everything fits into
the callable paren list of comma separated stuff some of it with equal
signs in it end paren pattern.
> - There is a distinct non-linearity in print's ease of use once you
> decide that you don't want to have spaces between items
in practice, % is a great way to deal with this.
> - If it were a function, it would be much easier to replace it within
> one module (just def print(*args):...) or even throughout a program
> (e.g. by putting a different function in __builtin__.print).
if that's an important feature, what keeps us from adding a hook
(along the lines of __import__) ?
one could even argue that making it easier to override it locally
may make it harder to override it globally; consider this local
override:
def print(fmt, *args):
sys.stdout.write("MY MODULE SAYS " + fmt % args)
print("blabla")
with this in place, changing __builtin__.print will override everything
except the prints in "MY MODULE"... so you end up doing a stdout
redirect, just as in today's python.
(etc)
:::
</F>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
