. Python 2.1 function attributes

[Alex Martelli]

"Tim Peters" <tim.one at home.com> wrote in message
news:mailman.980717974.17843.python-list at python.org...
> [Tim, replying to Clarence, who "was somewhat amazed at the addition
>  of print>>, and I assure you that I will never use it"
> ]
> > would-be-more-impressed-by-the-damnation-of-people-who've-actually-
> >     tried-it-ly y'rs  - tim
>
> [Alex Martelli]
> > Would you?
>
> Of course.  You would too; so would most people.  The testimony of one
> person who tried a thing and found it lacking is more compelling than 100
> virgins speculating about why they're certain they would despise it if
only
> they could bear stooping low enough to try it <wink>.  There's also the

Actual experience with using some tool may be a _part_ of what
gives 'impressiveness' to reports that said tool is inferior,
but it's generally not a major component thereof -- e.g., the
tool may have been misunderstood, misused, etc.

> telling fact that Guido rejected Barry's print>> proposal before giving it
a
> test drive in his own code -- pure argument never had much to do with this
> one.

Interesting -- I don't recall hearing about this detail previously.

It _does_ interestingly contradict Guido's posts at the time,
requesting _arguments_ (NOT "experiences") -- which, to me and I
guess to other respondents, implied that the requested arguments
*would* have a bit to do with something; I'm less surprised, now
that I hear this, that said arguments mattered not a whit.


> > OK, assuming this is not just cheap rhetoric, then:
>
> Na, I stopped beating my wife almost a month ago.  But of course it's
> "cheap":  even if I were so impressed that I made it my life ambition to
> remove this "wart" from the language, it's a done deal *and* Guido likes
it.
> It's not going away.

Oh, I do realize this -- Python *will* have this wart forevermore.
That doesn't mean I intend to suffer it *silently*.


> > I've tried it and I damn it worse then ever.
>
> Then I would have liked to hear how it botched *you* up in practice (I've
> read your "head" objections multiple times over the months, and that's not
> the same thing).  You tried it, and what bad thing happened as a result?
> That's still missing (the rest of the msg was about your son).

I thought I had posted (must have been 4-5 months ago) about my
"print>>" experiments?  Briefly -- I took one module that was
using about 20 print statements in two functions (and used the
sys.stdout setting for redirect when needed, from a separate
wrapping function) and recoded it using '>>blotch' on every
print (with 'blotch' a function parameter defaulting to None on
the operating functions).  The small wrapper was not bad:

from [before 'print>>']:

def foobarRedirect(fileob, *args):
    save = sys.stdout
    try: return foobar(*args)
    finally: sys.stdout = save

to the simpler:

def foobarRedirect(fileob, *args):
    return foobar(*args, blotch=fileob)

However, function foobar itself was cluttered by a more
substantial amount than the wrapper was simplified, what with
each 'print x' becoming 'print>>blotch,x' (plus the extra
blotch=None argument to both foobar and the other function,
also exposed from the module, that foobar calls).

This has as little 'scientific' value as any other similar
experiment, of course (which is part of why I find your
'more-impressed' somewhat unlikely) -- it's not a controlled
ergonomics experiment: in the end, the evaluation of "how
readable and maintainable is the resulting code" is about
as subjective and aesthetic as one's original appreciation
of the construct.  But then, actual human-factors controlled
experiments are just as scarce on the side _supporting_
'print>>', aren't they?

I don't think I posted on the similar experience I did with
code previously using flob.write, but it was even worse from
my point of view.  Changing the calls, typically originally
all in the form:
    flob.write(format % (a,b,c))
to print-with-redirect:
    print >> flob, format % (a,b,c),
not only had no observable benefit, but actually gave a
slight problem in a case where an unwanted blank space got
inserted by two back-to-back 'print>>' (while the .write
calls, of course, did not insert it).  But then, I had even
lower expectations this time -- it seems that 'print>>' is
studied to substitute for print-plus-sys.stdout-changes,
not for .write (which is what I most often use for output).

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.

Still, we're all humans (or bots), and thus, this is no
doubt a widespread issue.  I've spent an hour or so on it,
confirmed the preconceived ideas I had before I did, and
my opinions about 'print>>' are, as could be expected,

Be that as it may, I'm still waiting to see real-life
examples, in my code *or others'*, where the use of
'print>>' will strike me as "ah yes, clearly the one
right, obvious way to do it".


> > I guess -- and he paid Python the highest possible compliment when he
> > said 'it gets out of my way and just lets me DO things').
>
> Curiously, that last was Barry's motivation for adding print>> (chiefly
that
> the old stdout redirection dance *was* getting in his way in his Mailman
> work).

I doubt my son is currently maintaining years-old scripts chock
full of 'print' (neither am I, I'll admit); if we were, either or
both of us might perhaps see things differently (but we aren't).


> > d. he thought print>>file would APPEND to the file object and never
> >     OVERWRITE it
>
> Well, print>> does append, unless he explicitly seek()'ed to an earlier
file
> position between prints.

It writes to wherever .write would write, right?-)

> > -- at least once tried writing 'print>file' for the latter purpose
>
> Ah, so he's mixing up the functionality of open() and print.  Would he
also
> have thought that
>
>     sys.stdout = open("somefile", "w")
>     print "Hi"
>
> should append to somefile rather than overwriting it?  If so, his
confusion
> isn't due to ">>".  That is, it isn't so clear *where* he got confused.

I don't think he has any problems with print or write 'overwriting'; the
"where", I suspect, comes from his only previous experience with a >> (he
has no C++ background, and I don't think he's doing any bit-shifts yet) --
the DOS command-line (I doubt he still recalls much Linux from back when
it was the Martelli family OS -- that was MANY years ago).

> >  -- and I also heard him complain than then 'of course' input<file
> >     should also work.
>
> So he's actually a ">>" fan who wants to see it extended until it takes
over
> the entire language <0.9 wink>.

I think it's just more of the "unwonted parallels with the shell" syndrome.

> >     Last I heard he deemed it a 'total mess' and swore he'd stick
> >     with write/writelines for his file output needs.
>
> So he doesn't like plain "print" either(?).  Of course he's *welcome* to

I don't think he has yet met with the 'assign to sys.stdout' idiom, so
he may not realize that print, even without the '>>plok', CAN be used
to output text to files other than standard-output.

> stick with write/writelines, and given his Pascal background that's what
> he's used to (btw, did he first expect writelines to supply trailing
> newlines for him?  thinking of the write/writeln distinction in Pascal
> there).

Not sure -- he may have used .writelines on a list of strings obtained
from .readlines so the trailing newlines were already there.  I do recall
a mention of .write(i) not working (with i being an integer) but that was
not phrased as him raising an issue with the language, rather as a request
to explain if .write(str(i)) was OK or whether he should look into '%'
(the latter's going to be a problem, 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?).


> > but, me, I was impressed that the 'print>>' made up 1/3 of the grand
> > total of his objections to Python -- just about anything else he took
> > in stride and found to work just as expected
>
> I take it he never tried
>
>     except ValueError, KeyError:
>
> then <wink>.

No exception-catching yet, I believe.


Alex