Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > block scope?

Reply
Thread Tools

block scope?

 
 
Neal Becker
Guest
Posts: n/a
 
      04-06-2007
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?

 
Reply With Quote
 
 
 
 
James Stroud
Guest
Posts: n/a
 
      04-07-2007
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
 
Reply With Quote
 
 
 
 
Paul Rubin
Guest
Posts: n/a
 
      04-07-2007
James Stroud <(E-Mail Removed)> 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.
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      04-07-2007
Paul Rubin wrote:
> James Stroud <(E-Mail Removed)> 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
 
Reply With Quote
 
Paul Rubin
Guest
Posts: n/a
 
      04-07-2007
John Nagle <(E-Mail Removed)> 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++.
 
Reply With Quote
 
James Stroud
Guest
Posts: n/a
 
      04-07-2007
Paul Rubin wrote:
> John Nagle <(E-Mail Removed)> 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
 
Reply With Quote
 
Neal Becker
Guest
Posts: n/a
 
      04-07-2007
James Stroud wrote:

> Paul Rubin wrote:
>> John Nagle <(E-Mail Removed)> 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.


 
Reply With Quote
 
irstas@gmail.com
Guest
Posts: n/a
 
      04-07-2007
On Apr 7, 6:48 am, James Stroud <(E-Mail Removed)> 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.

 
Reply With Quote
 
Alex Martelli
Guest
Posts: n/a
 
      04-07-2007
Neal Becker <(E-Mail Removed)> 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
 
Reply With Quote
 
Steve Holden
Guest
Posts: n/a
 
      04-07-2007
Alex Martelli wrote:
> Neal Becker <(E-Mail Removed)> 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

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Fo:Block can you check to see if a block contains any text by using the block id? morrell XML 1 10-10-2006 07:18 PM
Problem with enterprise application block - data block Showjumper ASP .Net 1 03-19-2005 03:48 PM
Block DIV within a block DIV? Noozer HTML 3 01-06-2005 10:24 PM
XML schema validation of one xml block based on values from another xml block Andy XML 0 11-18-2004 11:04 PM



Advertisments