Tim Peters wrote:
>
> [Vladimir Marangozov]
> > ...
> > 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.
>
> This is so Unix-centric, though; e.g., native windows users have only the
> dimmest knowledge of stderr, and almost none of /dev/null.
Ok, forget about /dev/null. It was just a spelling of "print to None"
which has a meaning even in spoken English.
> Which ties in to:
>
> > So as long as one uses extended print, she's already an advanced user.
>
> Nope! "Now how did I get this to print to a file instead?" is one of the
> faqiest of newbie FAQs on c.l.py, and the answers they've been given in the
> past were sheer torture for them ("sys? what's that? rebind sys.stdout to
> a file-like object? what?! etc").
Look, this is getting silly. You can't align the experienced users' level
of knowledge to the one of newbies. What I'm trying to make clear here is
that you're not disturbing newbies, you're disturbing experienced users
and teachers who are supposed to transmit their knowledge to these newbies.
FWIW, I am one of these teachers and I have had enough classes in this
domain to trust my experience and my judgement on the students' logic
more than Guido's and your's perceptions taken together about *this*
feature in particlar. If you want real feedback from newbies, don't take
c.l.py as the reference -- you'd better go to the nearest school or
University and start teaching. (how's that as a reply to your attempts
to make me think one way or another or trust abbreviations <0.1 wink>)
As long as you have embarked in the output redirection business, you
have done so explicitely, because you're supposed to understand what it
means and how it works. This is "The Next Level" in knowledge, implying
that whenever you use extended print *explicitely*, you're supposed to
provide explicitely the target of the output.
Reverting that back with None, by saying that "print >> None == print"
is illogical, because you've already engaged in this advanced concept.
Rolling back your explicit decision about dealing with redirected output
with an explicit None (yes, you must provide it explicitely to fall back
to the opriginal behavior) is the wrong path of reasoning. If you don't
want to redirect output, don't use extended print in the first place.
And if you want to achieve the effect of "simple" print, you should pass
sys.stdout.
I really don't see the point of passing explicitely None instead of
passing sys.stdout, once you've made your decision about redirecting
output. And in this regard, both Guido and you have not provided any
arguments that would make me think that you're probably right.
I understand very well your POV, you don't seem to understand mine.
And let me add to that the following summary: the whole extended
print idea is about convenience. Convenience for those that know
what file redirection is. Not for newbies. You can't argue too much
about extended print as an intuitive concept for newbies. The present
change disturbs experienced users (the >> syntax aside) and you get
signals about that from them, because the current behavior does not
comply with any existing concept as far as file redirection is concerned.
However, since these guys are experienced and knowledgable, they already
understand this game quite well. So what you get is just "Oh really? OK,
this is messy" from the chatty ones and everybody moves on. The others
just don't care, but they not necessarily agree.
I don't care either, but fact is that I've filled two screens of text
explaining you that you're playing with 2 different knowledge levels.
You shouldn't try to reduce the upper level to the lower one, just because
you think it is more Pythonic for newbies. You'd better take the opposite
direction and raise the newbie stadard to what happens to be a very well
known concept in the area of computer programming, and in CS in gerenal.
To provoke you a bit more, I'll tell you that I see no conceptual difference
between
print >> None, args
and
print >> 0, args -or- print >> [], args -or- print >> "", args
(if you prefer, you can replace (), "", [], etc. with a var name, which can be
assigned these values)
That is, I don't see a conceptual difference between None and any object
which evaluates to false. However, the latter are not allowed. Funny,
isn't it. What makes None so special? <wink>
Now, the only argument I got is the one Fredrik has quoted from the PEP,
dealing with passing the default file as a parameter. I'll focus briefly
on it.
[Fredrik]
> [me]
> > def func(file=sys.stdout):
> > print >> file, args
> >
> > This is a clearer, compared to None which is not a file.
>
> Sigh. You code doesn't work. Quoting the PEP, from the section
> that discusses why passing None is the same thing as passing no
> file at all:
>
> "Note: defaulting the file argument to sys.stdout at compile time
> is wrong, because it doesn't work right when the caller assigns to
> sys.stdout and then uses tables() without specifying the file."
Of course that it doesn't work if you assign to sys.stdout. But hey,
if you assign to sys.stdout, you know what 'sys' is, what 'sys.stdout' is,
and you know basically everything about std files and output. Don't you?
Anyway, this argument is a flawed, because the above is in no way
different than the issues raised when you define a default argument
which is a list, dict, tuple, etc. Compile time evaluation of default args
is a completely different discussion and extended print has (almost)
nothing to do with that. Guido has made this (strange) association between
two different subjects, which, btw, I perceive as an additional burden.
It is far better to deal with the value of the default argument within
the body of the function: this way, there are no misunderstandings.
None has all the symptoms of a hackish shortcut here.
>
> This is one of those cases where Guido is right, but for reasons nobody can
> explain <0.8 wink>.
I'm sorry. I think that this is one of those rare cases where he is wrong.
His path of reasoning is less straigtforward, and I can't adopt it. And
it seems like I'm not alone. If you ever see a columnist talking about
Python's features and extended print (mentioning print >> None as a good
thing), please let me know about it.
>
> sometimes-you-just-gotta-trust-your-bdfl-ly y'rs - tim
>
I would have preferred arguments. The PEP and your responses lack them
which is another sign about this feature.
stop-troubadouring-about-blind-BDFL-compliance-in-public'ly y'rs
--
Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr
http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4