gratuitous new features in 2.0

[Alex Martelli]

"Aahz Maruch" <aahz at netcom.com> wrote in message
news:8o4e4o$mat$1 at slb3.atl.mindspring.net...
> In article <slrn8qbdro.4aa.nascheme at cranky.arctrix.com>,
> Neil Schemenauer <nascheme at enme.ucalgary.ca> wrote:
> >Andrew Kuchling <akuchlin at mems-exchange.org> wrote:
> >>
> >>Agreed; there is a small (but apparently growing) number of people
> >>unhappy with the unprecedented slew of added features to 2.0.  I'm
> >>particularly irked by weird special cases, like the .setdefault(key,
> >>default_value) method of dictionaries that was recently added.
> >
> >My beef is with the new syntax for print.  I don't like new
> >syntax unless absolutely necessary.  What would have been wrong
> >with:
> >
> >    write(sys.stderr, "foo", "bar", "baz")
> >
> >instead of:
> >
> >    print >>sys.stderr, "foo", "bar", "baz"
> >
> >Yuck, it looks like C++ or Perl.  I'm with Andrew on the
> >setdefault() method as well.
>
> I've been exchanging some e-mail with Guido and Barry about this;
> Guido particularly isn't following the discussion here.  Unfortunately,
> I seem to be unable to find a sufficiently powerful argument to sway
> BDFL's mind.  My primary argument at this point is that I *shouldn't*
> have to argue against PEP 0214: the onus should be on whoever is
> proposing a language change to develop a powerful argument in favor.  So
> far, I haven't seen one.

Let's see if I can help supply some arguments, since you may
have the ear[s] of the BDFL and friends -- feel totally free
to make any selective or total use of the following material.

I haven't seen one either, including the URL you kindly give for
Tim Peters' comments.  Apparently, the 'print>>bah' syntax is
only being compared with the current situation, rather than with
the many alternative ways of exposing the same functionality:

    print >> bah, foo, bar, baz
    println(bah, foo, bar, baz)
    println(foo, bar, baz, file=bah)
    sys.println as above
    bah.println(foo, bar, baz)

I absolutely can't see why the first syntax is deemed to be "more
pythonic" than the others; on the contrary, it strikes me (and
apparently most other respondants) as a hack -- with the notable
exceptions of the BDFL and timbot.  Now, if they could just
articulate how and why the ">>hack" is more Pythonic than any
of the ways to expose the same functionality as a function and/or
method (without changing the language itself), I guess us peons
might, if not share their superior understanding, at least
acquiesce in it more quietly.

The "powerful argument" is presumably made for the functionality
to exist; assigning and restoring sys.stdout is no doubt somewhat
cumbersome, what with the try/finally needs, etc.  On general
principles, reliance on global status, even with the ability of
saving/changing/restoring such status, is dirtier than explicit
passing of the (local) status information needed.

But why need this functionality be presented as a language
change, when it seems so much more natural to offer it as
a function or method instead?  _That_ is the part I really
can't fathom.

Choosing between a function (either builtin or in some module,
that is a secondary, naming issue) and a method (on file like
objects) is a different thing.  I believe a function might be
better here, as the need to customize for specific files, that
the method would enable, does not seem present; on the other
hand, if the function is there, it will presumably just rely
on the .write method of the file-like object, so the object
itself (which may pre-exist the introduction of the println
function) need not be further enriched/customized.  But I'd
be relatively happy with either resolution of this secondary
stuff, as long as the language itself does not get 'wantonly'
(as it appears to me) extended with functionality that might
be at least as well exposed as a function (or method).

The advantages of exposing a given functionality as a function
or method, rather than by a language-change to the print
statement, should be pretty clear.  If I have a function for
a task, it's a full-fledged object, which I can save, pass
around, compose, subject to map/apply/etc; a statement does
not give me anywhere as much functional flexibility.  E.g.,
consider the 'tee' functionality that is often requested --
printing to a set of files.  How do you implement 'print
this info to this set of files' if print is a statement, not
a function?  You presumably have to implement a tee-object,
say:
class teeObject:
    def __init__(self, *files):
        self.files=files
    def write(self, stuff):
        for file in self.files:
            write(file, stuff)
and do something like:
    print >> teeObject(afile, another), foo, bar, baz
as opposed to wrapping it easily in a function:
    teePrint((afile,another), foo, bar, baz)
with
def teePrint(files, *stuff):
    for file in files:
        println(file, *stuff)

The class-based solution, made necessary by the statement,
appears to be about twice as complicated as the function
based solution which a println function would enable.

If I just wanted to output, for debugging purposes, a
bunch of stuff which I have received as arguments, the
function shines again, I think:

def trace1(header,*stuff,file=sys.stdout):
    println(file,header,*stuff)

def myfunc(*stuff):
    trace1("myfunc args:",*stuff):
    # now do the real work

versus

def trace2(header,*stuff,file=sys.stdout):
    print >> file, header,
    for stiff in stuff[:-1]:
        print >> file, stiff,
    if len(stuff)>0:
        print >> file, stuff[-1]

Again, having to work with a print statement rather than
a println function does seem to me to make things much,
much more complicated -- several times as much.


What would be the offsetting advantages of having the
statement instead of the function?  I can't see them!

Rebuttals by charter members of the "Friends of print>> Society"
are of course welcome...!


> Note that while I don't have a strong visceral reaction against
> dict.setdefault(), I have to agree with the dismay at the speed with
> which it's going in.

I don't know anything about this "dict.setdefault" thing; can
you please provide an URL where I might learn something?  Thanks!


Alex