[Python-Dev] PEP 318: Can't we all just get along?

Gareth McCaughan gmccaughan at synaptics-uk.com
Thu Aug 19 12:58:12 CEST 2004


On Thursday 2004-08-19 06:58, Guido van Rossum wrote:
> > From the posts I've seen here, the only alternatives that have
> > considerable popular support are ones that you've already
> > rejected. So I suspect nobody really feels it's worth trying.
> 
> Well, do people generally buy those rejections, or is their consensus
> that I'm mistaken?

I'm one of the people who doesn't really feel it's worth trying.
*My* consensus :-) is that you're mistaken. I think that

  - the @-syntax is horrible and unpythonic as all-get-out,
    but usable;

  - your arguments against the []-before-colon form are utterly
    bogus;

  - I don't recall seeing a compelling argument against the
        decorate:
            classmethod
            memoize
            wibblify(3,"aardvark")
        def make_foo(cls, *args):
            do_something(args)
    proposal that was made recently in python-dev (but must surely
    have come up before). That syntax looks much better to me
    than the pie syntax. The "only" problem is that it's weird
    to have a suite of things that aren't statements to execute,
    but it doesn't seem any weirder to me than pie. Oh, one other
    problem: the order of application is non-obvious. Same as
    with pie. (I think it's obvious, by the way, that this syntax
    should include a without-line-break version for single decorators.)

I should expand on that second point, though I expect it's
all been said before.

Here's what you said about the list-before-colon syntax,
quoted from the Wiki page about decorators, with comments.

  | That's a total jumble of stuff ending with a smiley.  (True story: I
  | left out the colon when typing up this example and only noticed in
  | proofing.)

The jumbliness of your example is a consequence of the jumbly
set of decorators it uses, and has precious little to do with
the decorator syntax being used. It doesn't look much better,
to me at least, using pie syntax. And if you're seriously using
the fact that it ends with "]:" as an argument against it, then
something has gone badly wrong.

The fact that you made a minor error of the sort Python
catches automatically while typing in an example in a
syntax you have strong negative feelings about doesn't
seem to me like much of an argument against that syntax,
either.

  | Problems with this form:
  |
  | - it hides crucial information (e.g. that it is a static method)
  |   after the signature, where it is easily missed

I don't believe it's substantially more easily missed after the signature
than before.

  | - it's easy to miss the transition between a long argument list and a
  |   long decorator list

Not much easier than to miss the transition between a long argument
list and the function body. Anyway, what's so difficult about, say,

    def cumbersomely_named_method(arg1, arg2, arg3, arg4, arg5,
                                  arg91232, arg8724, arg8123721) \
        [ staticmethod,
          accepts(int, int, str, dict, int, None, None, int),
          memoize((1, 2, 3)) ]:
        """Here's the docstring."""
        do_something()
        do_something_else(arg1)
        # etc

This sort of thing is the worst case for the list-before-colon
syntax. It still doesn't seem much worse than pie. Whereas in
the simplest case I think pie is a lot worse:

    def make_foo(cls) [classmethod]:
        return cls("foo")

    @classmethod
    def make_foo(cls):
        return cls("foo")

  | - it's cumbersome to cut and paste a decorator list for reuse, because
  |   it starts and ends in the middle of a line

If a decorator list is long enough to be worth cutting and pasting
then (1) it's probably worth building a new decorator that encapsulates
what it does, and (2) you can always use a layout that *does* put it
on separate lines, like the cumbersomely_named_method example above.

  | Given that the whole point of adding decorator syntax is to move the
  | decorator from the end ("foo = staticmethod(foo)" after a 100-line
  | body) to the front, where it is more in-your-face, it should IMO be
  | moved all the way to the front.

That isn't the whole point, though it's certainly a lot of the point.
And list-before-colon seems pretty in-your-face to me, though
admittedly it doesn't have that "Oi, you, listen up, there's something
utterly unlike anything else in Python happening here" feel about it
that pie does.

                              *

Now, having said all that: let's suppose for the sake of argument
that your arguments against list-before-colon are completely without
merit. There's still the *fact* that you dislike it, and your
intuition is notoriously pretty good :-). So I suspect that maybe
there's something really bad about list-before-colon that I haven't
noticed, or that I've not seen the importance of. But, until such
time as that's pointed out to me in a way I'm not too stupid to
appreciate, I still like list-before-colon.

                              *

I'm not sure what you're thinking *should* happen here that would
convince you (or anyone else) to adopt a different syntax. All the
other Python developers choosing another syntax and agreeing to
go with it? That's never going to happen spontaneously when there's
more than one possible alternative.

I think that either list-before-colon or indented-suite (options
C1 and J2 on the Wiki page) are clearly preferable to pie, and for
what little it's worth I hereby declare my support for any
consensus or partial consensus that might emerge for either.

-- 
g



More information about the Python-Dev mailing list