block scope?

Discussion in 'Python' started by Neal Becker, Apr 6, 2007.

  1. Neal Becker

    Neal Becker Guest

    One thing I sometimes miss, which is common in some other languages (c++),
    is idea of block scope. It would be useful to have variables that did not
    outlive their block, primarily to avoid name clashes. This also leads to
    more readable code. I wonder if this has been discussed?
    Neal Becker, Apr 6, 2007
    #1
    1. Advertising

  2. Neal Becker

    James Stroud Guest

    Neal Becker wrote:
    > One thing I sometimes miss, which is common in some other languages (c++),
    > is idea of block scope. It would be useful to have variables that did not
    > outlive their block, primarily to avoid name clashes. This also leads to
    > more readable code. I wonder if this has been discussed?
    >


    Probably, with good code, block scope would be overkill, except that I
    would welcome list comprehensions to have a new scope:


    py> i
    ------------------------------------------------------------
    Traceback (most recent call last):
    File "<ipython console>", line 1, in <module>
    <type 'exceptions.NameError'>: name 'i' is not defined

    py> [i for i in xrange(4)]
    [0, 1, 2, 3]
    py> i # hoping for NameError
    3
    James Stroud, Apr 7, 2007
    #2
    1. Advertising

  3. Neal Becker

    Paul Rubin Guest

    James Stroud <> writes:
    > Probably, with good code, block scope would be overkill, except that I
    > would welcome list comprehensions to have a new scope:


    Block scope is a win because it gets rid of the uncertainty of whether
    the variable is used outside the block or not. The "good code" theory
    (just manually don't use the variable elsewhere) doesn't always hold
    up under release deadline pressure and so on and doesn't make sense
    anyway. What's the point of NOT having block scope if you don't want
    to allow for creating variables in inner blocks and using them in
    other blocks? I think it's best to require creating the variable
    in a mutually enclosing scope if you want to use it that way.
    Paul Rubin, Apr 7, 2007
    #3
  4. Neal Becker

    John Nagle Guest

    Paul Rubin wrote:
    > James Stroud <> writes:
    >
    >>Probably, with good code, block scope would be overkill, except that I
    >>would welcome list comprehensions to have a new scope:

    >
    >
    > Block scope is a win because it gets rid of the uncertainty of whether
    > the variable is used outside the block or not.


    In a language with few declarations, it's probably best not to
    have too many different nested scopes. Python has a reasonable
    compromise in this area. Functions and classes have a scope, but
    "if" and "for" do not. That works adequately.

    Javascript got it wrong. They have declarations, but the default,
    in the absence of a declaration, is global, not local or an error.
    Bad design. It's a result of retrofitting declarations to a language,
    which usually has painful aftereffects.

    John Nagle
    John Nagle, Apr 7, 2007
    #4
  5. Neal Becker

    Paul Rubin Guest

    John Nagle <> writes:
    > In a language with few declarations, it's probably best not to
    > have too many different nested scopes. Python has a reasonable
    > compromise in this area. Functions and classes have a scope, but
    > "if" and "for" do not. That works adequately.


    I think Perl did this pretty good. If you say "my $i" that declares
    $i to have block scope, and it's considered good practice to do this,
    but it's not required. You can say "for (my $i=0; $i < 5; $i++) { ... }"
    and that gives $i the same scope as the for loop. Come to think of it
    you can do something similar in C++.
    Paul Rubin, Apr 7, 2007
    #5
  6. Neal Becker

    James Stroud Guest

    Paul Rubin wrote:
    > John Nagle <> writes:
    >> In a language with few declarations, it's probably best not to
    >> have too many different nested scopes. Python has a reasonable
    >> compromise in this area. Functions and classes have a scope, but
    >> "if" and "for" do not. That works adequately.

    >
    > I think Perl did this pretty good. If you say "my $i" that declares
    > $i to have block scope, and it's considered good practice to do this,
    > but it's not required. You can say "for (my $i=0; $i < 5; $i++) { ... }"
    > and that gives $i the same scope as the for loop. Come to think of it
    > you can do something similar in C++.


    How then might one define a block? All lines at the same indent level
    and the lines nested within those lines?

    i = 5
    for my i in xrange(4):
    if i: # skips first when i is 0
    my i = 100
    if i:
    print i # of course 100
    break
    print i # i is between 0 & 3 here
    print i # i is 5 here


    Doesn't leave a particularly bad taste in one's mouth, I guess (except
    for the intended abuse).

    James
    James Stroud, Apr 7, 2007
    #6
  7. Neal Becker

    Neal Becker Guest

    James Stroud wrote:

    > Paul Rubin wrote:
    >> John Nagle <> writes:
    >>> In a language with few declarations, it's probably best not to
    >>> have too many different nested scopes. Python has a reasonable
    >>> compromise in this area. Functions and classes have a scope, but
    >>> "if" and "for" do not. That works adequately.

    >>
    >> I think Perl did this pretty good. If you say "my $i" that declares
    >> $i to have block scope, and it's considered good practice to do this,
    >> but it's not required. You can say "for (my $i=0; $i < 5; $i++) { ... }"
    >> and that gives $i the same scope as the for loop. Come to think of it
    >> you can do something similar in C++.

    >
    > How then might one define a block? All lines at the same indent level
    > and the lines nested within those lines?
    >
    > i = 5
    > for my i in xrange(4):
    > if i: # skips first when i is 0
    > my i = 100
    > if i:
    > print i # of course 100
    > break
    > print i # i is between 0 & 3 here
    > print i # i is 5 here
    >
    >
    > Doesn't leave a particularly bad taste in one's mouth, I guess (except
    > for the intended abuse).
    >
    > James


    Yes, the above is pretty much what I had in mind. +1.
    Neal Becker, Apr 7, 2007
    #7
  8. Neal Becker

    Guest

    On Apr 7, 6:48 am, James Stroud <> wrote:
    > Neal Becker wrote:
    > > One thing I sometimes miss, which is common in some other languages (c++),
    > > is idea of block scope. It would be useful to have variables that did not
    > > outlive their block, primarily to avoid name clashes. This also leads to
    > > more readable code. I wonder if this has been discussed?

    >
    > Probably, with good code, block scope would be overkill, except that I
    > would welcome list comprehensions to have a new scope:


    Generator expressions have a new scope, and in Python 3.0 list
    comprehensions will have one as well (according to http://www.python.org/dev/peps/pep-0289/
    ). It's a fix that might break existing code so it couldn't be
    introduced in "minor" versions like 2.4 and 2.5.
    , Apr 7, 2007
    #8
  9. Neal Becker <> wrote:
    ...
    > > i = 5
    > > for my i in xrange(4):
    > > if i: # skips first when i is 0
    > > my i = 100
    > > if i:
    > > print i # of course 100
    > > break
    > > print i # i is between 0 & 3 here
    > > print i # i is 5 here
    > >
    > >
    > > Doesn't leave a particularly bad taste in one's mouth, I guess (except
    > > for the intended abuse).
    > >
    > > James

    >
    > Yes, the above is pretty much what I had in mind. +1.


    I prefer Java's approach (14.4.2 in the JLS 2nd edition): forbid "inner"
    blocks from shadowing variables in "outer" ones. I quote:
    """
    If a declaration of an identifier as a local variable of the same
    method, constructor, or initializer block appears within the scope of a
    parameter or local variable of the same name, a compile-time error
    occurs.
    Thus the following example does not compile:

    class Test {
    public static void main(String[] args) {
    int i;
    for (int i = 0; i < 10; i++)
    System.out.println(i);
    }
    }
    This restriction helps to detect some otherwise very obscure bugs.
    """
    I entirely agree with the JLS here, having fought just such bugs in C++
    and other languages that lack the restriction in question. I just wish
    Python had adopted the same restriction regarding nested functions, when
    proper lexical scoping was introduced -- I argued for it at the time,
    but backwards compatibility blocked its introduction. There are
    definitely NOT many Java-specific language characteristics that I like,
    but this one is a winner!-) [[but, I disagree with the lack in Java of
    a similar restriction against shadowing between instance variables and
    local variables, and the weak rationale for that in the JLS:)]].


    Alex
    Alex Martelli, Apr 7, 2007
    #9
  10. Neal Becker

    Steve Holden Guest

    Alex Martelli wrote:
    > Neal Becker <> wrote:
    > ...
    >>> i = 5
    >>> for my i in xrange(4):
    >>> if i: # skips first when i is 0
    >>> my i = 100
    >>> if i:
    >>> print i # of course 100
    >>> break
    >>> print i # i is between 0 & 3 here
    >>> print i # i is 5 here
    >>>
    >>>
    >>> Doesn't leave a particularly bad taste in one's mouth, I guess (except
    >>> for the intended abuse).
    >>>
    >>> James

    >> Yes, the above is pretty much what I had in mind. +1.

    >
    > I prefer Java's approach (14.4.2 in the JLS 2nd edition): forbid "inner"
    > blocks from shadowing variables in "outer" ones. I quote:
    > """
    > If a declaration of an identifier as a local variable of the same
    > method, constructor, or initializer block appears within the scope of a
    > parameter or local variable of the same name, a compile-time error
    > occurs.
    > Thus the following example does not compile:
    >
    > class Test {
    > public static void main(String[] args) {
    > int i;
    > for (int i = 0; i < 10; i++)
    > System.out.println(i);
    > }
    > }
    > This restriction helps to detect some otherwise very obscure bugs.
    > """
    > I entirely agree with the JLS here, having fought just such bugs in C++
    > and other languages that lack the restriction in question. I just wish
    > Python had adopted the same restriction regarding nested functions, when
    > proper lexical scoping was introduced -- I argued for it at the time,
    > but backwards compatibility blocked its introduction. There are
    > definitely NOT many Java-specific language characteristics that I like,
    > but this one is a winner!-) [[but, I disagree with the lack in Java of
    > a similar restriction against shadowing between instance variables and
    > local variables, and the weak rationale for that in the JLS:)]].
    >

    What do you think the chances are of this being accepted for Python 3.0?
    It is indeed about the most rational approach, though of course it does
    cause problems with dynamic namespaces.

    regards
    Steve
    --
    Steve Holden +44 150 684 7255 +1 800 494 3119
    Holden Web LLC/Ltd http://www.holdenweb.com
    Skype: holdenweb http://del.icio.us/steve.holden
    Recent Ramblings http://holdenweb.blogspot.com
    Steve Holden, Apr 7, 2007
    #10
  11. Neal Becker

    Paul Rubin Guest

    (Alex Martelli) writes:
    > Thus the following example does not compile:
    > class Test {
    > public static void main(String[] args) {
    > int i;
    > for (int i = 0; i < 10; i++)


    I'm ok with this; at the minimum, I think such nesting should produce
    a warning message.
    Paul Rubin, Apr 7, 2007
    #11
  12. Steve Holden <> wrote:

    > What do you think the chances are of this being accepted for Python 3.0?
    > It is indeed about the most rational approach, though of course it does
    > cause problems with dynamic namespaces.


    What problems do you have in mind? The compiler already determines the
    set of names that are local variables for a function; all it needs to do
    is diagnose an error or warning if the set of names for a nested
    function overlaps with that of an outer one.

    I shamefully admit that I haven't followed Python 3.0 discussions much
    lately, so I don't really know what's planned on this issue.


    Alex
    Alex Martelli, Apr 8, 2007
    #12
  13. Paul Rubin <http://> wrote:

    > (Alex Martelli) writes:
    > > Thus the following example does not compile:
    > > class Test {
    > > public static void main(String[] args) {
    > > int i;
    > > for (int i = 0; i < 10; i++)

    >
    > I'm ok with this; at the minimum, I think such nesting should produce
    > a warning message.


    Yes, a warning could surely be a reasonable compromise.


    Alex
    Alex Martelli, Apr 8, 2007
    #13
  14. Neal Becker

    Aahz Guest

    In article <1hw7kzo.1hepj3c1who5zhN%>,
    Alex Martelli <> wrote:
    >Steve Holden <> wrote:
    >>
    >> What do you think the chances are of this being accepted for Python 3.0?
    >> It is indeed about the most rational approach, though of course it does
    >> cause problems with dynamic namespaces.

    >
    >What problems do you have in mind? The compiler already determines the
    >set of names that are local variables for a function; all it needs to do
    >is diagnose an error or warning if the set of names for a nested
    >function overlaps with that of an outer one.


    exec?
    --
    Aahz () <*> http://www.pythoncraft.com/

    Why is this newsgroup different from all other newsgroups?
    Aahz, Apr 8, 2007
    #14
  15. Neal Becker

    John Nagle Guest

    Paul Rubin wrote:
    > John Nagle <> writes:
    >
    >> In a language with few declarations, it's probably best not to
    >>have too many different nested scopes. Python has a reasonable
    >>compromise in this area. Functions and classes have a scope, but
    >>"if" and "for" do not. That works adequately.

    >
    >
    > I think Perl did this pretty good. If you say "my $i" that declares
    > $i to have block scope, and it's considered good practice to do this,
    > but it's not required. You can say "for (my $i=0; $i < 5; $i++) { ... }"
    > and that gives $i the same scope as the for loop. Come to think of it
    > you can do something similar in C++.


    Those languages have local declarations. "my" is a local
    declaration. If you have explicit declarations, explict block
    scope is no problem. Without that, there are problems. Consider

    def foo(s, sname) :
    if s is None :
    result = ""
    else :
    result = s
    msg = "Value of %s is %s" % (sname, result)
    return(msg)

    It's not that unusual in Python to initialize a variable on
    two converging paths. With block scope, you'd break
    code that did that.


    John Nagle
    John Nagle, Apr 8, 2007
    #15
  16. Aahz <> wrote:

    > In article <1hw7kzo.1hepj3c1who5zhN%>,
    > Alex Martelli <> wrote:
    > >Steve Holden <> wrote:
    > >>
    > >> What do you think the chances are of this being accepted for Python 3.0?
    > >> It is indeed about the most rational approach, though of course it does
    > >> cause problems with dynamic namespaces.

    > >
    > >What problems do you have in mind? The compiler already determines the
    > >set of names that are local variables for a function; all it needs to do
    > >is diagnose an error or warning if the set of names for a nested
    > >function overlaps with that of an outer one.

    >
    > exec?


    option 1: that just runs the compiler a bit later -- thus transforming
    ClashingVariableError into a runtime issue, exactly like it already does
    for SyntaxError.

    option 2: since a function containing any exec statement does not
    benefit from the normal optimization of local variables, let it also
    forgo the normal diagnosis of shadowed/clashing names.

    option 3: extend the already-existing prohibition of mixing exec with
    nested functions:

    >>> def outer():

    .... def inner(): return x
    .... exec('x=23')
    .... return inner()
    ....
    File "<stdin>", line 3
    SyntaxError: unqualified exec is not allowed in function 'outer' it
    contains a nested function with free variables

    to prohibit any mixing of exec and nested functions (not just those
    cases where the nested function has free variables).


    My personal favorite is option 3.


    Alex
    Alex Martelli, Apr 8, 2007
    #16
  17. Neal Becker

    Paul Rubin Guest

    (Alex Martelli) writes:
    > > exec?

    > option 1: that just runs the compiler a bit later ...


    Besides exec, there's also locals(), i.e.
    locals['x'] = 5
    can shadow a variable. Any bad results are probably deserved ;)
    Paul Rubin, Apr 8, 2007
    #17
  18. Neal Becker

    MRAB Guest

    On Apr 7, 8:50 am, James Stroud <> wrote:
    > Paul Rubin wrote:
    > > John Nagle <> writes:
    > >> In a language with few declarations, it's probably best not to
    > >> have too many different nested scopes. Python has a reasonable
    > >> compromise in this area. Functions and classes have a scope, but
    > >> "if" and "for" do not. That works adequately.

    >
    > > I think Perl did this pretty good. If you say "my $i" that declares
    > > $i to have block scope, and it's considered good practice to do this,
    > > but it's not required. You can say "for (my $i=0; $i < 5; $i++) { ... }"
    > > and that gives $i the same scope as the for loop. Come to think of it
    > > you can do something similar in C++.

    >
    > How then might one define a block? All lines at the same indent level
    > and the lines nested within those lines?
    >
    > i = 5
    > for my i in xrange(4):
    > if i: # skips first when i is 0
    > my i = 100
    > if i:
    > print i # of course 100
    > break
    > print i # i is between 0 & 3 here
    > print i # i is 5 here
    >
    > Doesn't leave a particularly bad taste in one's mouth, I guess (except
    > for the intended abuse).
    >

    How about something like this instead:

    i = 5
    block:
    for i in xrange(4):
    if i: # skips first when i is 0
    block:
    i = 100
    if i:
    print i # of course 100
    break
    print i # i is between 0 & 3 here
    print i # i is 5 here

    Any variable that's assigned to within a block would be local to that
    block, as it is in functions.
    MRAB, Apr 8, 2007
    #18
  19. Paul Rubin <http://> wrote:

    > (Alex Martelli) writes:
    > > > exec?

    > > option 1: that just runs the compiler a bit later ...

    >
    > Besides exec, there's also locals(), i.e.
    > locals['x'] = 5
    > can shadow a variable. Any bad results are probably deserved ;)


    >>> locals['x']=5

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    TypeError: 'builtin_function_or_method' object does not support item
    assignment

    I suspect you want to index the results of calling locals(), rather than
    the builtin function itself. However:

    >>> def f():

    .... locals()['x'] = 5
    .... return x
    ....
    >>> f()

    Traceback (most recent call last):
    File "<stdin>", line 1, in <module>
    File "<stdin>", line 3, in f
    NameError: global name 'x' is not defined

    No "shadowing", as you see: the compiler knows that x is NOT local,
    because it's not assigned to (the indexing of locals() does not count:
    the compiler's not expected to detect that), so it's going to look it up
    as a global variable (and not find it in this case).

    I think that ideally there should be a runtime error when assigning an
    item of locals() with a key that's not a local variable name (possibly
    excepting functions containing exec, which are kind of screwy anyway).


    Alex
    Alex Martelli, Apr 8, 2007
    #19
  20. Neal Becker

    Paul Rubin Guest

    (Alex Martelli) writes:
    > >>> locals['x']=5

    > Traceback (most recent call last):
    > File "<stdin>", line 1, in <module>
    > TypeError: 'builtin_function_or_method' object does not support item
    > assignment



    Whoops, yeah, meant "locals()['x'] = 5".

    > I think that ideally there should be a runtime error when assigning an
    > item of locals() with a key that's not a local variable name (possibly
    > excepting functions containing exec, which are kind of screwy anyway).


    I have no opinion of this, locals() has always seemed like a crazy
    part of the language to me and I never use it. I'd be happy to see it
    gone since it makes compiling a lot easier.
    Paul Rubin, Apr 8, 2007
    #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. Paul Opal
    Replies:
    12
    Views:
    931
    Paul Opal
    Oct 11, 2004
  2. ann
    Replies:
    13
    Views:
    651
    Patricia Shanahan
    Sep 13, 2005
  3. morrell
    Replies:
    1
    Views:
    936
    roy axenov
    Oct 10, 2006
  4. Steven T. Hatton
    Replies:
    9
    Views:
    459
  5. Steve V
    Replies:
    6
    Views:
    234
    Steve V
    Apr 20, 2005
Loading...

Share This Page