. Python 2.1 function attributes

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.981046930.4615.python-list at python.org...
    [snip]
> We need some context here.  Stephen Figgins wrote a great (IMO) "outsider"
> summary of the brouhaha at the time:
>
>   http://www.oreillynet.com/pub/a/python/2000/08/30/pythonnews.html
    [snip]
> > Oh, I do realize this -- Python *will* have this wart forevermore.
> > That doesn't mean I intend to suffer it *silently*.
>
> No indeed, so long as it's understood that the right to speak is not also
> the right to be listened to -- don't you think there are more
*interesting*
> things to do in the Python world than beat this dead horse?  I do.

There is, in my opinion, a subtle and important distortion in what you
call "a great outsider summary" above -- specifically in its summing
things up (as of August 2000) with "This has quieted some of the complaints
down. I expect them to taper off this week" and "am looking forward to
seeing what controversy will rise up next as this one finally dies down".

This implies that the controversy was a tempest in a teapot, just one
of many, that everybody was by now resigned to what Mr. Figgins calls
"a done deal".  This is not the way I see the "print>>" issue.  I
consider it _by far_ the worst thing to ever have happened to Python
(in the limited timespan in which I've been following Python; but,
judging from what I've read in old mailing list archives and what I
can see now in the language as it stands, then 'ever' does apply).

"Those who cannot remember the past are condemned to repeat it" (this
Santayana quote is often subject to many variations -- I apologize,
but I don't know what the exact wording should be).  If there is
anything at all that I can do, which may decrease by one part in a
million the probability that Python may suffer a repetition of the
"print>>" disaster, it may be worth it; and, if this quote contains
any germ of truth, then ensuring the remembrance is not buried may
perhaps be some part of that one-in-a-million decrease in the risk
of such a repetition.

No, I do not believe there is any Python related endeavour, that
I might be capable of, that is more IMPORTANT ("interesting" is a
different issue) than whatever fraction of a part in a million I may
contribute to avoiding such a repetition (if I thought there was ANY
chance, no matter how tiny, to have the horrid wart REMOVED from the
language, then that would be something else again -- but I don't; so,
the _most_ I can hope for is to perhaps contribute to lowering the
probability of a repetition).

Of course I have no right to be listened to -- killfiles have not
been abrogated, have they?  Everybody, as usual, is _welcome_ to
killfile me if they're not interested in what I have to say -- have
I ever said or implied otherwise?


> their code true to *their* vision.  And then
>
>    print >> sys.stderr, "Hey! I got", `got`, "but expected", `want`
>
> 1 line in 250 is pure pleasure.

How is this "better" than

    sys.stderr.write("Hey! I got %r but expected %r\n" % (got, want))

...?

> *suspect* (but don't know) that one reason Guido found print>> attractive
is
> the number of msgs (over the years) directed to sys.stderr that are
> *missing* crucial spaces when done in the sys.stderr.write(msg) form --
and
> since they're "error msgs", sometimes years go by before we see that one
of
> those is damaged.

When the msg is put together with a %-format, which seems to be
the way that most comes natural to me, it's hard to think that
missing spaces can be an important issue.

> Now a space-eager printing gimmick could have been done via a function
too,
> but Python already *had* a stmt for that purpose.  From that POV, it was
> natural to extend it.

I have no bones to pick against the print statement for its most
elementary, daily use -- rough & ready debugging; no matter how
refined the debuggers I have at hand, I'm enough of a dinosaur
that much of my debugging is inserting and removing print's.  But
for that use case there is no added value in redirecting each of
them separately -- if I find a sudden need to have all of the
print's I currently have use OutputDebugString, or whatever, then
a temporary setting of sys.stdout around the interesting parts
remains preferable (which I think is part of what you were agreeing
on, in the parts of your post that I snipped, above).

_For a specific need to output something onto a given file_, I
find absolutely nothing natural or worthwhile in "extending" a
statement whose main use case is so different (impromptu tracing).

An output function would have required no syntax blotch (I have
just reread Guido's response and see that he does mention the
analogies with sh's use of >> -- he does fail to mention that
those analogies are _misleading_ ones, exactly those that seemed
to trip up my son), and the objection "but for a function I have
no way to say ``and don't use a linebreak''", also part of Guido's
response, is unbelievable -- why not just
    printfun(x,y,z,newline=None)
...?!

*Fortunately*, it's NOT natural in Python for a statement that
already exists for a purpose to be extended, with kludgy syntax,
to other similar purposes a function would serve better.  For
parallel iteration over lists, we didn't get some syntactically
horrid kludge based on the existing for statement -- we got a
usable and elegant zip function instead, good for that one AND
other secondary uses too.  Let's hope the "well, there IS one
statement that does something a BIT like that, let's think of
some C++ish abuse of a binary operator into a unary not-quite-
an-operator-whatever-the-heck-IS-it to have it do that too"
remains a once-a-decade occurrence in Python, rather than have
it become a way of life.


> I don't think print>> is ever a good substitute for .write(), except in

So far, we agree, up to the "except" excluded:-).

> those cases where .write() is being used for human-readable output and the
> author didn't want to do the stdout redirection dance around plain
"print".

The redirection minuet is one thing, but I claim that write
with a %-format doesn't leave me wanting for decent ways to
do output.  A printlike function would be better, but I
don't hunger for it often, because write-plus-% does it well;
if I _did_ hunger for it, it would not be terrible to write
it, either (though having it as a builtin would encourage
its use in small pieces of code meant to be portable).


> Else automagical space-insertion gets in the way more than it helps.
Don't
> know whether Guido would agree, but that's my take on it.

FWIW (little, of course), I agree with your take, from the 'Else' (excluded)
onwards.


> > The "lower expectations" may be important -- but I can't
> > brainwash myself (and wouldn't if I could) to expect the
> > sky and stars from a construct that strikes me so badly:
> > giving it "a fair chance" may thus be impossible for me.
>
> Try thinking of it as a minor convenience?  I do!  I could live without
it;
> I'd rather not.

"convenience" is the most-used euphemism, in today's programming,
for "horrid blotch that anybody should be ashamed of", to justify
complication, irregularity, rampant ad-hocitis and kludges.

Thus, I have no trouble at all thinking of 'print>>' as a
"convenience" (visualize Dr. Evil doing the ``quotes''
finger-gesture...).

It's not "minor", IMHO, mostly because its syntax stands out
like a sore thumb (and BY DESIGN, no less!) from Python's
generally pretty nice picture.  It DOES, as intended, recall
C++, or sh -- but, in THOSE punctuation-obsessed contexts,
what's a >> more or less.  Anything that takes Python's
syntax closer, _by design_, to that of such collections of
syntactic warts as C++ or sh is a MAJOR "convenience" indeed!


> A quick regexp search turns up about 135 uses in the current CVS tree.
Some
> I don't like.  Some I do.  I'll mention two of the latter because I expect
> to hear about all the others from you <wink>.

No need... the "likeable" ones are bad enough!-)  Taking just one:

> 1. The last line of Lib/test/test_largefile.py:
>
>     print >>sys.stderr, name, "exists:", os.path.exists(name)
>
> A human-readable msg and the only use of sys.stderr in the module.  There
is
> no (IMO) alternative as obvious or convenient as this way of writing it.

What about:

    sys.stderr.write("%s exists: %s\n" % (name, os.path.exists(name))

...?  What's so horribly inconvenient or too-subtle about %-formatting?


> While just a few lines of code, it's on the edge of being strained.  I'd
> also rather see these lines as
>
>     DEBUG(some, human, readable, msg)
>
> because it's the DEBUG part that's important, not the "print" part (and,
> indeed, the *normal* use of these lines is *not* to print!).

I fully agree with this assessment.  If a function printfun and/or a
method printmethod existed to do printlike things, I think this would
encourage by example the use of a function here and in similar
contexts -- one might just have DEBUG=fileobject.printmethod to
turn it on, and DEBUG=functionthatdoesnothing to turn it off.


> > I guess, when he comes around to it, since he has no C background
> > to understand the rules for the format string; I'd better write up
> > something for him -- or can somebody help with an URL about %-
> > formatting already written up for somebody with zero C background?).
>
> I don't, but there's a very *good* writeup at:
>
>     http://www-ccs.ucsd.edu/c/lib_prin.html
>
> Lots of examples, explanation, and even a railroad diagram for the syntax
of
> a format code (which I'm afraid is more confusing than helpful!).

I'm not a diagram-oriented person myself, but the rest does
seem useful -- thanks!


> At least the docs for 2.1 contain *a* description of each format code.
The
> contributed patch Fred started from can be found here:
>
> http://sourceforge.net/patch/index.php?func=detailpatch&
>     patch_id=103412&group_id=5470

Thanks again, I'll have a look.


> good-topic-for-a-"howto"!-dense-little-languages-aren't-obvious-ly

Good point...


Alex