variable declaration

[Alex Martelli]

Michael Tobis <mt at 3planes.com> wrote:

> With all due respect, I think "so go away if you don't like it" is
> excessive, and "so go away if you don't like it and you obviously don't
> like it so definitely go away" is more so. The writer is obviously

I disagree: I believe that, if the poster really meant what he wrote, he
may well be happier using other languages and all the declarations he
cherishes, so recommending that course of action to him is quite proper
on my part.  Nobody forces him to follow my advice, in particular if, as
you suggest, he's mis-expressed himself.

> neither a native speaker of English nor an accomplished user of Python,
> so there are two language issues here. Try expressing your reply in
> Russian before deciding that "very ugly" means exactly what you think
> it does.

I don't know any Russian, and I don't see how that's relevant.  If the
poster said "it's very ugly" meaning "I'm not fully comfortable with it"
or "it's the best thing I've ever seen in my life", he can perfectly
well correct his misexpression if he cares to -- not my job to try to
read his mind and perform exegesis on his words.

> I think just saying that "experienced Python users have not
> found the lack of declarations to be a major hindrance" would have been
> more appropriate.

I think it would have been true, but weak and insufficient.  Not only
experienced Python users have that opinion: lack of declarations didn't
faze me even I was a total newbie (other things did, and I learned that
most of them were good only gradually; but if I'd blocked on something
as obviously *fundamental* to Python, I'd never have gone deeper, of
course).  Plus, I did offer a URL for a classic post by Robert Martin,
who's not even talking about Python yet came to exactly the same
conclusion *while using statically typed languages*, just on the basis
of unit-testing experience.


> Also, the assertion that "Python has no declarations whatsoever" is no
> longer obviously true. In the 2.4 decorator syntax, a decorator line is
> not executable, but rather a modifier to a subsequent symbol binding. I
> call it a declaration.

You may call it a strawberry, if you wish, but that doesn't mean it will
taste good with fresh cream.  It's nothing more and nothing less than an
arguably weird syntax for a perfectly executable statement:

@<expression>
def functionname <rest of function header and body>

means EXACTLY the same thing as

def functionname <rest of function header and body>
functionname = <expression>(functionname)

Nothing more, nothing less.  The splat-syntax isn't a "declaration" in
any sense of the word, just a not-so-short shortcut for an assignment
statement.  Proof by disassembly:

>>> def f():
...   @foo
...   def g(): pass
... 
>>> dis.dis(f)
  2           0 LOAD_GLOBAL              0 (foo)
              3 LOAD_CONST               1 (<code object g at 0x3964e0,
file "<stdin>", line 2>)
              6 MAKE_FUNCTION            0
              9 CALL_FUNCTION            1
             12 STORE_FAST               0 (g)
             15 LOAD_CONST               0 (None)
             18 RETURN_VALUE        
>>> def f():
...   def g(): pass
...   g = foo(g)
... 
>>> dis.dis(f)
  2           0 LOAD_CONST               1 (<code object g at 0x389ee0,
file "<stdin>", line 2>)
              3 MAKE_FUNCTION            0
              6 STORE_FAST               0 (g)

  3           9 LOAD_GLOBAL              1 (foo)
             12 LOAD_FAST                0 (g)
             15 CALL_FUNCTION            1
             18 STORE_FAST               0 (g)
             21 LOAD_CONST               0 (None)
             24 RETURN_VALUE        

the splat-syntax optimizes away one STORE_FAST of g and the
corresponding LOAD_FAST, by having the LOAD_GLOBAL of foo earlier; nice,
but not earth-shaking, and definitely no "declaration" whatsoever.


> Let me add that I remain unconvinced that a language cannot combine the
> best features of Python with very high performance, which is ultimately

I'm also unconvinced.  Fortunately, so is the EU, so they have approved
very substantial financing for the pypy project, which aims in good part
exactly at probing this issue.  If any single individual can be called
the ideator of pypy, I think it's Armin Rigo, well-known for his
excellent psyco specializing-compiler for Python: the key research
thesis behind both projects is that a higher-level, dynamic language
need not have performance inferior to a lower-level one and indeed may
well beat it.

> what I want. It seems to me that such a language (possibly Python,
> possibly a Python fork, possibly something else) will need substantial
> programmer control over references as well as referents.

pypy is dedicated to proving you're wrong.  With at least half a dozen
great people now finally having started working full-time on the
project, and due to continue so doing for the next couple of years, I
like our chances.


> It seems to me that Python has a weaker case for purity in this regard
> now that the dam has been breached with decorator syntax, which is, I
> think, a declaration.

I entirely disagree that a minor syntax wheeze to introduce a shortcut
for a particular executable statement ``is a a declaration''.

 
> Let me conclude with the confession that I'm still on the steep part of
> the learning curve (if it ever flattens out at all...). Python has
> definitely significantly modified how I think about things, and I
> deeply appreciate all the efforts of you veterans. So I say this all
> with some trepidation, because I don't want to join Alexander in
> inadvertently offending you. And since I presumably missed some intense
> flame wars about decorators by only a couple of months,  this may be a
> real hornet's nest I am poking.

Almost nobody really liked the splat-syntax for decorators, except of
course Guido, who's the only one who really counts (the BDFL).  But that
was strictly a syntax-sugar issue -- which was exactly the reason making
the flamewars SO ferocious.  It's one of Parkinson's Laws: the amount
and energy of discussion on an issue is inversely proportional to the
issue's importance.  Fortunately, I was otherwise busy, so didn't enter
the fray at all (I intensely dislike the splat, but I don't care all
that much about such minor syntax sugar one way or another, anyway).

fici
> In summary, again with all due respect and gratitude for the
> spectacularly excellent product that Python is today, I wonder  *why*
> this strong aversion to declarative statements, and *whether* decorator
> syntax constitutes a violation of it. I'd appreciate any responses or
> links.

If "declarative statement" means anything, I guess it means "having to
tell stuff to the compiler to be taken into account during compilation
but irrelevant at runtime".  Python does have one such wart, the
'global' statement, and it's just as ugly as one might imagine, but
fortunately quite marginal, so one can almost forget it.

I have nothing against a declarative style _per se_ -- it just doesn't
fit Python's "everything happens at runtime" overall worldview, and that
simple and powerful worldview is a good part of what makes Python tick
SO well.  I think there's a space for declarative languages, and it is
mostly ``orthogonal'' to Python.  See, for example,
<http://www.strakt.com/docs/ep04_caps.pdf>, specifically the part of the
presentation that's about BLAM -- that's a declarative language (with
embedded Python for ``actions'', e.g., triggers, and computations), and
I think a neat and useful design, too.


Alex