[Python-Dev] Challenge about print >> None

Vladimir Marangozov Vladimir.Marangozov@inrialpes.fr
Tue, 12 Sep 2000 01:22:46 +0200 (CEST)


Guido van Rossum wrote:
> 
> >   GvR> Don't think of it as
> > 
> >   GvR>   print >>None, args
> > 
> >   GvR> Think of it as
> > 
> >   GvR>   def func(file=None):
> >   GvR>     print >>file, args

I understand that you want me to think this way. But that's not my
intuitive thinking. I would have written your example like this:

def func(file=sys.stdout):
    print >> file, args

This is a clearer, compared to None which is not a file.

> ...  This is intended to let you specify file=<some file>
> and have the default be sys.stdout, but passing an explicit value of
> None has the same effect as leaving it out.  This idiom is used in
> lots of places!

Exactly.
However my expectation would be to leave out the whole print statement.
I think that any specialization of None is mysterious and would be hard
to teach. From this POV, I agree with MAL that raising an exception is
the cleanest and the simplest way to do it. Any specialization of my
thought here is perceived as a burden.

However, if such specialization is desired, I'm certainly closer to
/dev/null than sys.stdout. As long as one starts redirecting output,
I believe that one already has enough knowledge about files, and in
particular about stdin, stdout and stderr. None in the sense of /dev/null
is not so far from that. It is a simple concept. But this is already
"advanced knowledge" about redirecting output on purpose.

So as long as one uses extended print, she's already an advanced user.
From this perspective print >> F means "redirect the output of
print to the file <F>". If F is not really a file, the F object must
have a write() method. This is the second approximation which is easy
to grasp.  But if F is not a file and does not have a write() method,
then what? Then, you say that it could be None which equals sys.stdout
(a file!). This is contradictory with the whole logic above and frankly,
this concept specialization is not intuitive and difficult to grasp.
(despite the "nice, leaving out" property that you seem to value, which
in this context doesn't worth much in my eyes because I think that
it results in more enigmatic code - it's not explicit, but rather
magically implicit).

-- 
       Vladimir MARANGOZOV          | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252