Re: [MLUG] guess what

[Mark Rages <EMAIL:PROTECTED>]

On Thu, Apr 01, 2004 at 03:23:36PM -0600, Jonathan King wrote:
> 
> On Thu, 1 Apr 2004, Mark Rages wrote:
> > 
> > In Python, you would do this:
> > 
> > i=1
> > def f():
> >    global i
> >    print "i=",i
> >    i = i + 1
> > 
> > Is this what you thought I meant?
> 
> But that just means that f() alters the globally visible i, right?
> In other words, if you print i outside of f(), you see the side 
> effect.  That's NOT what happens with a closed-over variable.
> 

So a closed-over variable would create a copy of the value outside the 
block? 

> In a language with true lexical scoping, a function that is defined
> within the lexical scope of a variable (i.e., you can see it in the
> program text in the block that contains the function) can use that
> variable.  More strikingly, that variable persists between function
> calls (since it was defined in a scope that still exists and is
> reacable via the function), and no other function that wasn't
> defined in the same scope can see or use it. So what I wrote was:
> 
> > > {
> > >     $i = 1;
> > > 
> > >     sub counter {
> > > 	$i++;
> > >     }
> > > }
> 
> this makes counter() into a function that increments (and returns) 
> the value of i.  If I'd done (for example) this:
> 
> > #!/usr/bin/perl -n 
> >
> > {
> >     my $i=1;
> >         sub count {
> >              $i++
> >         }
> > }
> >
> > print count();
> 
> ...then I'd have a counter that incremented each time I hit carriage
> return (yeah, useless here and not brilliant code, but...).  
> There's much fancier things you can do with these than simulate
> non-global static variables (it makes callbacks are much nicer), but
> this is the idea.

OK, so the "one way" to do that in Python is to make a full class of it 
in typical verbose Python style:

class Counter:
    def __init__(self):
        self.i=1
    def count(self):
        print "i=",self.i
        self.i = self.i + 1

c=Counter()
c.count()
 
> > Python has blocks; they're just denoted by whitespace.  Like English.
> 
> And it's a great thing that English never has any ambiguities caused 
> by this, right? :-)  Blocks are good, and good enough to be visible.  
> I stand by that statement.

Well, I appreciate blocks too. :)  After looking at your example, I 
can see that Python *does* have explicit block demarcation: A block 
begins after any language construct ending in a colon, and continues 
until a smaller level of indentation is encountered.   This would result 
in abiguity if Perl's 'lexical scoping' were used.  Am I following you 
correctly?

> > > Statement delimiters are (wait for it again...) what give you
> > > statements.  Python would be just as good (actually, much BETTER if
> > > it made these things explicit.  It's been awhile, but when I found
> > > that you often had to use line continuation devices in Python, I
> > > thought "How quaint."  It turns out that Python (at least then) 
> > > wasn't expression oriented but *statement* oriented.  I guess you 
> > > could say "to each his own" but there were reasons why he hashed 
> > > this stuff out in the 70s and decided that expressions and blocks 
> > > were Good Things.  This is NOT leading edge kind of stuff.
> > 
> > If you break the lines in places like after a , or + then you don't need 
> > explicit line continuation.  (You can use ; to separate expressions if 
> > you so desire)
> 
> And that is...a hack.  If Python were expression-based, you'd never
> have that special rule.  And you're not separating expressions;  
> you're separating statements, I believe.  In Perl, "$foo = 7" is an
> expression which returns the new value of $foo.  Put a semi-colon
> after it, and you've made it a statement that can be followed by
> other statements in the block.

Python assignments are statements, true. (you can use ';' between 
them: a=1; b=2; c=3 for example. ) Not that it's a great idea.

Having assignents as expressions allows very compact expression (I'm 
thinking of the K&R book on C) , but I don't think this was ever really 
a design goal of Python.  And I *like* getting an error message when I 
say:

if uid=0: print "access granted"

because I always make that kind of stupid mistake.

Besides compact expression, like stuffing a loop's body into its for() 
statement, what advantages does making assignment an expression rather 
than a statement have?

Regards,
Mark
EMAIL:PROTECTED
-- 
To invent, you need a good imagination and a pile of junk. -Thomas Edison
_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members