variable declaration

Discussion in 'Python' started by Alexander Zatvornitskiy, Jan 31, 2005.

  1. 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,
    Alexander Zatvornitskiy, Jan 31, 2005
    #1
    1. Advertising

  2. Alexander Zatvornitskiy

    EP Guest

    > ------------Original Message------------
    > From: 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:

    >>> for epsilon in range (0,10):

    S=S+epsilon

    >>> for epsilon in range (0,10):

    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.
    EP, Jan 31, 2005
    #2
    1. Advertising

  3. Alexander Zatvornitskiy

    Peter Otten Guest

    Alexander Zatvornitskiy wrote:

    > 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
    Peter Otten, Jan 31, 2005
    #3
  4. Alexander Zatvornitskiy
    <3.n5025.z2.fidonet.org> wrote:

    > 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
    Alex Martelli, Jan 31, 2005
    #4
  5. Alexander Zatvornitskiy

    Steve Holden Guest

    Alex Martelli wrote:

    > Alexander Zatvornitskiy
    > <3.n5025.z2.fidonet.org> wrote:
    >
    >
    >>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

    >

    [...]
    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
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
    Steve Holden, Jan 31, 2005
    #5
  6. 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.

    --
    mt
    Michael Tobis, Jan 31, 2005
    #6
  7. Michael Tobis wrote:

    > 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>
    Fredrik Lundh, Jan 31, 2005
    #7
  8. > 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?
    --
    mt
    Michael Tobis, Jan 31, 2005
    #8
  9. Michael Tobis wrote:

    >> that's a nice theory, but since the decorator line is executed by the
    >> interpreter, it's a little weak.

    >
    > Well, uh, who else would process it?


    the compiler.

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

    </F>
    Fredrik Lundh, Jan 31, 2005
    #9
  10. Alexander Zatvornitskiy

    DogWalker Guest

    "EP" <> said:

    >> ------------Original Message------------
    >> From: 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:
    >
    >>>> for epsilon in range (0,10):

    > S=S+epsilon
    >
    >>>> for epsilon in range (0,10):

    > 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
    DogWalker, Jan 31, 2005
    #10
  11. > 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.

    --
    Regards,

    Diez B. Roggisch
    Diez B. Roggisch, Jan 31, 2005
    #11
  12. Michael Tobis <> 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
    Alex Martelli, Jan 31, 2005
    #12
  13. Alexander Zatvornitskiy

    Steve Holden Guest

    Alex Martelli wrote:

    > Michael Tobis <> wrote:
    >

    [...]
    >>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
    --
    Steve Holden http://www.holdenweb.com/
    Python Web Programming http://pydish.holdenweb.com/
    Holden Web LLC +1 703 861 4237 +1 800 494 3119
    Steve Holden, Jan 31, 2005
    #13
  14. "Alexander Zatvornitskiy"
    <3.n5025.z2.fidonet.org> wrote in message
    news:MSGID_2=3A5025=...
    > 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
    Thomas Bartkus, Jan 31, 2005
    #14
  15. Alexander Zatvornitskiy

    Carl Banks Guest

    Thomas Bartkus wrote:
    > 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.


    --
    CARL BANKS
    Carl Banks, Jan 31, 2005
    #15
  16. Alexander Zatvornitskiy

    Aahz Guest

    In article <1gr98se.102e9b1qnsknwN%>,
    Alex Martelli <> wrote:
    >
    >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 () <*> 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
    Aahz, Jan 31, 2005
    #16
  17. This is definitely a wart:

    .... z = 42.3
    ....
    .... def f():
    .... if False:
    .... global z
    .... z = -666
    ....
    .... f()
    .... print z
    Michael Tobis, Jan 31, 2005
    #17
  18. Alex Martelli wrote:
    > Michael Tobis <> 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.

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


    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.

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


    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.
    --
    mt
    Michael Tobis, Feb 1, 2005
    #18
  19. Michael Tobis wrote:

    > 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>
    Fredrik Lundh, Feb 1, 2005
    #19
  20. "Michael Tobis" <> writes:

    > 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.
    Jacek Generowicz, Feb 1, 2005
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Noah
    Replies:
    5
    Views:
    945
  2. Alex Vinokur
    Replies:
    4
    Views:
    571
    Jonathan Turkanis
    Apr 5, 2004
  3. Ovidesvideo
    Replies:
    4
    Views:
    479
    Andrey Tarasevich
    Dec 10, 2004
  4. baumann@pan

    variable definiton / variable declaration

    baumann@pan, May 11, 2005, in forum: C Programming
    Replies:
    3
    Views:
    531
    CBFalconer
    May 11, 2005
  5. Bolin
    Replies:
    4
    Views:
    394
Loading...

Share This Page