. Python 2.1 function attributes

[Tim Peters]

[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
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.

> 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.

> 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).

> Specifically, my son is learning Python as a spare-time activity
> (age: 17, background: Pascal, some assembler), and is loving it and
> finding it extremely impressive (he thinks of computers as tools,
> not ends in themselves -- a trait he must have gotten from his mother,
> 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).

> Issues that have given him problems so far, and resolutions of said
> issues:
>
> a. undefined-variables: he somehow expected that an x+=1, if x had
>     not been bound yet, would set x to 1; after reasoning about it he
>     agreed that it was clearer to start by setting x=0 before the loop
>     and AFAIK he doesn't do that mistake any more.

Good!  That one's not going to change either <wink>.

> b. he keeps trying to use x.length() and slapping his forehead after
>     getting the error and changing to len(x); still claims this makes no
>     sense and that it SHOULD be a method, and not abbreviated, from
>     what the rest of the language leads him to expect.

We're of the same mindset there:  it's something I stumbled over too when I
first learned Python.  Not the "abbreviation" part, because Python had
plenty of those from the start ("def", "del", "int", "str", "abs", "cmp",
"chr", "ord", "dir", ... were all in 0.9.6, off the top of my head).  But
"so was that thing a method or a function again?!" was a repeated question.

I still don't know whether it was an intentional part of the design, but it
eventually dawned on me that no builtin immutable object supported methods
(and, IIRC, that remained true until complex numbers were added, and by
someone other than Guido).  After that, len(x) vs x.len() was "obvious",
since strings were immutable -> (at the time) strings had no methods -> so
len must be a function.

It's harder to rationalize away now, eh?  Curiously, if it *had* been a
method from the start, I bet its name *would* have been "length":
abbreviations are common among the builtin function names but not among the
builtin method names.  Not much help deciding which is the case, but that
makes the "len"+function and "length"+method combos most likely.

> c. he keeps forgetting to end clauses with a colon ('else', etc); still
>    grumbles that omitting that colon should be OK.

This certainly is a blind spot for some people, but don't know how many; it
pops up regularly but rarely on c.l.py (a few times per year).  It's not one
of mine (to the contrary, it may actually be the case that I've never
forgotten a trailing colon on a block-opener in Python -- not even on the
first day), so I can't speculate about the character flaws that must account
for it in others <wink>.  Whatever, I expect this one is here to stay
(certain to stay if nobody who wants it otherwise champions a PEP).

> [No problem with / truncating, mixed-case issues, nor scoping -- all
> things I _thought_ might give him problems given how Pascal does
> it -- so I guess my preliminary explanations sufficed for those].

Indeed, I would have guessed those would be problems for him too!  If Guido
had it to do over again, adding Pascal's "div" would at the top of his list.

> 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.

> -- 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.

>  -- 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>.

>     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
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).

> I guess the unbiased opinions of a Python newbie don't count for
> much,

Sure they do -- they *point* rather than *proscribe*, though, because a
baffled newbie isn't usually able to articulate the precise cause(s) of
their confusion (if they could, they wouldn't remain baffled ...).  When ABC
hit one of these newbie sticking points, they would guess at the most likely
causes for the confusion, then set up a formal experiment to test which was
the case.  We don't have funding for that kind of approach, but I wish we
did.  OTOH, it was exactly that kind of study that caused ABC to require
colons at the end of block-opening statements, so there's no guarantee that
*every* newbie benefits.

> 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>.

> (his two other enduring objections, interestingly enough, are _also_
> to minor syntax-sugar issues -- and they don't look totally unfounded
> to me, either).

All objections have *some* foundation; nobody means to write off objections
as empty.  That includes people griping about whitespace-based block
structure, and that regexp notation isn't part of the core, too.  But it is
the Python philosophy that "X or Y?" cases get resolved by picking a winner;
a side effect is that there's also a loser.

> It is of course possible that I subconsciously passed my biases
> to him, but he's a pretty independent guy (and the fact that he
> has no trouble with / truncating seems to confirm that).

Real users are biased -- part of the game.  Besides, I would rather give
*extra* weight to people "biased" by you:  you usually do a thorough job of
softening them up for Guido's view of the world <wink>.

On print>>, though, I'm afraid you two will never agree.  It's unclear
whether Guido would make even plain "print" a statement again if the time
machine's batteries were up to the task, but given that it is a statement,
"print>>" looked like a natural, pleasant and useful extension.  I use it a
lot; so does Barry; so does Guido.  That's 60% of his direct team.  Don't
know about Fred and Jeremy, but Fred is controversy-aversive and Jeremy
probably doesn't want to hurt his standing in academia by admitting to
secret vice <wink>.

abc-had-simple-i/o-but-then-abc-couldn't-read-files-it-didn't-write-
    either-ly y'rs  - tim