variable declaration

[Alexander Zatvornitskiy]

Hello All!

I'am novice in python, and I find one very bad thing (from my point of view) in
language. There is no keyword or syntax to declare variable, like 'var' in
Pascal, or special syntax in C. It can cause very ugly errors,like this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

Even Visual Basic have 'Option Explicit' keyword! May be, python also have such
a feature, I just don't know about it?

Alexander, (e-mail address removed)

 

[EP]

------------Original Message------------

From: (e-mail address removed)3.n5025.z2.fidonet.org (Alexander Zatvornitskiy)

Hello All!

I'am novice in python, and I find one very bad thing (from my point of
view) in
language. There is no keyword or syntax to declare variable, like 'var'
in
Pascal, or special syntax in C. It can cause very ugly errors,like
this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

Hmmm. I am surely an expert in writing buggy code, but I can not say I make this error in Python. Why is that?

I'm not sure, but a couple things that may help me miss making this mistake in practice may be (somewhat informal in my case) unit testing - I test for correct results for at least a few cases.

It may also help that with Python I can code at a somewhat higher conceptual level, or maybe it is just the syntax that helps avoid these problems:
S=S+epsilon
S=S+epselon

Traceback (most recent call last):
File "<pyshell#6>", line 2, in ?
S=S+epselon
NameError: name 'epselon' is not defined


It may seem like jumping off a cliff, but the improvement in readability (the variable declarations being visual clutter) makes it much easier for me to see my code, and any typos in it.

It seems it would be simple enough to have one's code, or another script, automatically print out a sorted list of the variables - which would make the error you note obvious. But I haven't needed this, yet at least.

You might like Python and find the lack of variable declaration checking not a problem. It's worth a shot.

 

[Peter Otten]

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

pychecker may help you find misspelled variable names. You have to move the
code into a function, though:

$ cat epsilon.py
def loop():
epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

$ pychecker epsilon.py
Processing epsilon...

Warnings...

epsilon.py:6: Local variable (epselon) not used

Peter

 

[Alex Martelli]

Alexander Zatvornitskiy

Hello All!

I'am novice in python, and I find one very bad thing (from my point of
view) in language. There is no keyword or syntax to declare variable, like
'var' in

Since the lack of declarations is such a crucial design choice for
Python, then, given that you're convinced it's a very bad thing, I
suggest you give up Python in favor of other languages that give you
what you crave. The suggestions about using pychecker, IMHO, amount to
"band-aids" -- the right way to deal with minor annoying scratches, but
surely not with seriously bleeding wounds, and your language ("very bad
thing", "very ugly errors") indicates this is a wound-level issue for
you. Therefore, using Python, for you, would mean you'd be fighting the
language and detesting its most fundamental design choice: and why
should you do that? There are zillions of languages -- use another one.

Pascal, or special syntax in C. It can cause very ugly errors,like this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

Actually, this while loop never terminates and never prints anything, so
that's gonna be pretty hard to ignore;-). But, assume the code is
slightly changed so that the loop does terminate. In that case...:

It's absolutely trivial to find this bug, if you write even the tiniest
and most trivial kinds of unit tests. If you don't even have enough
unit tests to make it trivial to find this bug, I shudder to think at
the quality of the programs you code. Even just focusing on typos,
think of how many other typos you could have, besides the misspelling of
'epsilon', that unit tests would catch trivially AND would be caught in
no other way whatsoever -- there might be a <= where you meant a <, a
1.0 where you meant 10, a - where you meant a +, etc, etc.

You can't live without unit tests. And once you have unit tests, the
added value of declarations is tiny, and their cost remains.

A classic reflection on the subject by Robert Martin, a guru of C++ and
other languages requiring declarations, is at:
<http://www.artima.com/weblogs/viewpost.jsp?thread=4639>.

Even Visual Basic have 'Option Explicit' keyword! May be, python also have
such a feature, I just don't know about it?

Python has no declarations whatsoever. If you prefer Visual Basic, I
strongly suggest you use Visual Basic, rather than pining for Visual
Basic features in Python. If and when your programming practices ever
grow to include extensive unit-testing and other aspects of agile
programing, THEN you will be best advised to have a second look at
Python, and in such a case you will probably find Python's strengths,
including the lack of declarations, quite compelling.

Some people claim a language should change the way you think -- a
frequent poster, excellent Python contributor, and friend, even has that
claim in his signature. That may be alright in the groves of academia.
If you program to solve problems, rather than for personal growth, on
the other hand, changing "the way you think" with each programming
language is a rather steep price to pay. As a pragmatist, I prefer a
motto that I've also seen about Python: "it fits your brain". I find
it's true: Python gets out of my way and let me solve problems much
faster, because it fits my brain, rather than changing the way I think.

If Python doesn't fit YOUR brain, for example because your brain is
ossified around a craving for the declaration of variables, then, unless
you're specifically studying a new language just for personal growth
purposes, I think you might well be better off with a language that
DOES, at least until and unless your brain changes by other means.


Alex

 

[Steve Holden]

Alexander Zatvornitskiy

[...]
There are zillions of languages -- use another one.
[...]

If Python doesn't fit YOUR brain, for example because your brain is
ossified around a craving for the declaration of variables, then, unless
you're specifically studying a new language just for personal growth
purposes, I think you might well be better off with a language that
DOES, at least until and unless your brain changes by other means.


Alex

I think we should all remember that Python isn't for everyone, and least
of all for those with little knowledge of Python and preconceptions
about what Python *should* be like.

regards
Steve

 

[Michael Tobis]

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
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 think just saying that "experienced Python users have not
found the lack of declarations to be a major hindrance" would have been
more appropriate.

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. I found this disappointing in that it seems to
me a violation of "Special cases aren't special enough to break the
rules" but on further reflection it enables consideration of what a
whole slew of declarative constructs could achieve.

To begin with, now that the design constraint of "no declarations" has
been shown to be less than absolute, why not allow for perl-style ('use
strict') declarations? It actually is very useful in the small-script
space (up to a few hundred lines) where the best Perl codes live.

Let me add that I remain unconvinced that a language cannot combine the
best features of Python with very high performance, which is ultimately
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.

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.

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.

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.

 

[Fredrik Lundh]

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

that's a nice theory, but since the decorator line is executed by the inter-
preter, it's a little weak.

</F>

 

[Michael Tobis]

that's a nice theory, but since the decorator line is executed by the
inter-

preter, it's a little weak.

Well, uh, who else would process it?

"use strict' and 'my epsilon' in perl are executed by the perl
interpreter as well, but they have a declarative flavor.

A decorator is a modifier to a subsequent binding, and it modifies the
reference and not the referent. So how is it anythng but declarative?

 

[Fredrik Lundh]

Well, uh, who else would process it?

the compiler.

from __future__ is a declaration. @expression is an executable statement.

</F>

 

[DogWalker]

Hmmm. I am surely an expert in writing buggy code, but I can not say I make this error in Python. Why is that?

I'm not sure, but a couple things that may help me miss making this mistake in practice may be (somewhat informal in my case) unit testing - I test for correct results for at least a few cases.

It may also help that with Python I can code at a somewhat higher conceptual level, or maybe it is just the syntax that helps avoid these problems:

S=S+epselon

Traceback (most recent call last):
File "<pyshell#6>", line 2, in ?
S=S+epselon
NameError: name 'epselon' is not defined


It may seem like jumping off a cliff, but the improvement in readability (the variable declarations being visual clutter) makes it much easier for me to see my code, and any typos in it.

It seems it would be simple enough to have one's code, or another script, automatically print out a sorted list of the variables - which would make the error you note obvious. But I haven't needed this, yet at least.

You might like Python and find the lack of variable declaration checking not a problem. It's worth a shot.

class MyVars(object):
__slots__ = ['epsilon', 'thud', 'foo']

mv = MyVars()

mv.epselon = 42
Traceback (most recent call last)

/home/dw/KirbyBase-1.7/<console>

AttributeError: 'MyVars' object has no attribute 'epselon'

mv.epsilon = 42

 

[Diez B. Roggisch]

A decorator is a modifier to a subsequent binding, and it modifies the

reference and not the referent. So how is it anythng but declarative?

I learned the hard way that it still is simply interpreted - its a pretty
straight forward syntactic sugaring, as this shows:

foo = classmethod(foo)

becomes:

@classmethod

Now @classmethod has to return a callable that gets passed foo, and the
result is assigned to foo - not more, not less, so it becomes equivalent to
the older type of creating a class method.

Is this a declaration? I'd personally say and think "practically, yes", as I
also view

class Bar:
....

as a declaration. But obviously some people like Alex Martelli have
different views on this (and are right), because you can do this in python:

if condition:
class Foo:
def bar(self):
pass

else:
class Foo:
def schnarz(self):
pass

So that makes class statements not as declarative as they are in languages
like java.

So to sum it up (for me at least): things like metaclasses, decorators and
so on make me write code more declarative - if they are a declaration in
the strict sense, I don't bother.

 

[Alex Martelli]

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:
.... @foo
.... def g(): pass
.... 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 g(): pass
.... g = foo(g)
.... 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

 

[Steve Holden]

[...]

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.

I should be failing in my duty as Chairman if I didn't remind readers at
this point that they can hear Armin Rigo's talk "PyPy and Type
Inference" at PyCon at 5:30 on Wednesday March 23.

http://www.python.org/pycon/dc2005/register.html

While Alex is not necessarily too modest to mention it he might forget
that he is also giving three talks to PyCon. I believe this is the first
year he has been able to attend PyCon, so delegates are definitely in
for a treat this year.

regards
Steve

 

[Thomas Bartkus]

"Alexander Zatvornitskiy"

Hello All!

I'am novice in python, and I find one very bad thing (from my point of view) in
language. There is no keyword or syntax to declare variable, like 'var' in
Pascal, or special syntax in C. It can cause very ugly errors,like this:

epsilon=0
S=0
while epsilon<10:
S=S+epsilon
epselon=epsilon+1
print S

It will print zero, and it is not easy to find such a bug!

Even Visual Basic have 'Option Explicit' keyword! May be, python also have such
a feature, I just don't know about it?

Exactly so!
Python *does* require that your variables be declared and initialized before
you use them. You did that with epsilon=0 and S=0 at the top. It is
unfortunate, however, that the statement epselon=epsilon+1 also declares a
new variable in the wrong place at the wrong time. Such mispellings are a
*common* error caught instantly in languages that require a more formal
declaration procedure.

Another irksome sitiuation is that while Python does enforce strict type
checking, you can re-declare variables and morph them in the middle of
nowhere.
S = 0 # It's an Integer!
S = S + 'Hello' # No can do! Strong type checking forbids this.
S = 'GoodBye' # Whoops - Now it's a string! Unfortunately
legal!
This seemingly demolishes all the good reasons one has for wanting strict
type checking.

That second example is just bad programming practice and easy to avoid. The
problem you point out in your code, however, hurts! Was that an I, an l or a
1 in the variable name?

Hey! - I like Python a lot.
But nothings perfect
Thomas Bartkus

 

[Carl Banks]

Python *does* require that your variables be declared and initialized before
you use them. You did that with epsilon=0 and S=0 at the top. It is
unfortunate, however, that the statement epselon=epsilon+1 also declares a
new variable in the wrong place at the wrong time. Such mispellings are a
*common* error caught instantly in languages that require a more formal
declaration procedure.

I have no interest in arguing this right now, but it does raise a
question for me: How common is it for a local variable to be bound in
more than one place within a function? It seems that it isn't (or
shouldn't be) too common.

Certainly the most common case where this occurs is for temporary
variables and counters and stuff. These typically have short names and
thus are not as likely to be misspelled.

Another common place is for variables that get bound before and inside
a loop. I would guess that's not as common in Python as it is in other
languages, seeing that Python has features like iterators that obviate
the need to do this. (The OP's original example should have been "for
epsilon in range(10)"; epsilon only needed bound in one place.)

I guess this might be why, in practice, I don't seem to encounter the
misspelling-a-rebinding error too often, even though I'm prone to
spelling errors. Perhaps, if someone runs into this error a lot, the
problem is not with Python, but with their tendency to rebind variables
too much? Just a thought.

 

[Aahz]

Some people claim a language should change the way you think -- a
frequent poster, excellent Python contributor, and friend, even has that
claim in his signature.

Generally speaking, I change my .sig either when I get bored or when
someone references it. So here's the new one.
--
Aahz ([email protected]) <*> http://www.pythoncraft.com/

"Given that C++ has pointers and typecasts, it's really hard to have a serious
conversation about type safety with a C++ programmer and keep a straight face.
It's kind of like having a guy who juggles chainsaws wearing body armor
arguing with a guy who juggles rubber chickens wearing a T-shirt about who's
in more danger." --Roy Smith, c.l.py, 2004.05.23

 

[Michael Tobis]

This is definitely a wart:

.... z = 42.3
....
.... def f():
.... if False:
.... global z
.... z = -666
....
.... f()
.... print z

 

[Michael Tobis]

Michael Tobis <[email protected]> wrote:

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.

Well, I hate to try to tell you your job, but it doesn't seem to be to
be all that great of a marketing strategy to actively chase people
away... Hey, he might have been a Nutshell customer.

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

It did me, and it did many others. Perhaps you are unrepresentative.

It's one thing to say "no can do, sorry", it's another to say "you
don't need this anyway and if you think you do you aren't worthy".

In fact, it was your book I spent the most time thumbing through
looking for the "use strict" equivalent that I was absolutely certain
must exist. Hell, even Fortran eventually gave in to "IMPLICIT NONE".
It's practically the only thing I've ever expected to find in Python
that hasn't vastly exceeded my expectations, aand I'm sure Alexander is
not the only person to be put off by it. In fact, I'd recommend a
paragraph early in the Nutshell book saying "there are no declarations,
no use strict, no implicit none, sorry, forget it", and an index
listing under "declarations" pointing to a detailed exegesis of their
nonexistence. It would have saved me some time.

It's true that in some sense an assignment is all the declaration you
need. I think Carl Banks's point (what we think of as assignment as a
carryover from other languages is really rebinding, and in many cases
can be avoided) is also helpful.

But that doesn't make the "epselon" bug go away, and wanting to have a
way to catch it quickly isn't, to my mind, obviously a criminal act.
Also, based on what DogWalker demonstrates, it's really not that alien
to Python and should be feasible.

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:

This may well be true in implementation, but cognitively it is a
declaration that modifies the reference and not the referent. I see
that it is a big deal to ask for more of these, but I don't see why.

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.

I hope this works out, but it's hard for me to see how pypy will avoid
lots of hashing through dictionaries. I'm willing to help it by
declaring an immutable reference. Here, don't look this up; it always
points to that.

I'm guessing that this will also be considered a bad idea, and maybe
someday I'll understand why. I'm looking for insight, not controversy.

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:

I'm hoping I can make the meeting. Maybe proximity to the core group
will help me approach the sort of enlightenment I seek. Just being in
the vicinity of Ian Bicking's aura on occasion has been most inspiring.

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

Um, sugar isn't exactly what I'd call it. I think it matters a lot
though. Python's being easy on the eyes is not a trivial advantage for
some people, myself incuded.

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 am trying to talk about having expressive power in constraining
references as well as the referents. Python studiously avoids this, but
decorators change that. I am not deep enough into the mojo as yet to
have more than a glimmer of an idea about the distinction you are
making. It's not the one I'm trying to make.

decorators may not be implemented as declarations, but they cognitively
act as declarations, and that's what I care about here.

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'm glad you have said something something I absolutely agree with. I'm
alarmed at the suggestions here that class and def blocks are
declarative. The fact that they're executable is really a core part of
the beauty of Python.

However, I don't see how an 'import strict' would necessarily violate
this, nor an "import immutableref", which is something I would find
useful in trying to wrestle with NumArray, and which a high-performance
Python could (I think) use to advantage.

Now I may be wrong; in fact I'd bet against me and in favor of you and
Frederik if I had to bet. It's just that I don't see why I'm wrong.

 

[Fredrik Lundh]

This is definitely a wart:

... z = 42.3
...
... def f():
... if False:
... global z
... z = -666
...
... f()
... print z

no, it's a declaration. from the documentation:

http://docs.python.org/ref/global.html

"The global statement is a declaration which holds for the entire
current code block."

"the global is a directive to the parser. It applies only to code
parsed at the same time as the global statement"

</F>

 

[Jacek Generowicz]

In fact, I'd recommend a paragraph early in the Nutshell book saying
"there are no declarations, no use strict, no implicit none, sorry,
forget it",

It would have to be a pretty long paragraph, if it were to list all
the things that you do NOT find in Python.

and an index listing under "declarations" pointing to a detailed
exegesis of their nonexistence.

Think about this. You are either asking that the book's author
anticipate your personal expectations, and write the book to cater for
YOUR PERSONAL expectiations ... or you are asking for a book with an
inifititely long index. The list of things absent from Python is
infinite.

It would have saved me some time.

You don't want a book, you want a personal tutor.