Re: [MLUG] guess what

[Jonathan King <EMAIL:PROTECTED>]

On Thu, 1 Apr 2004, Mark Rages wrote:

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

No.  There is no value outside *some* block.  Look at my perl code 
again; the variable is inside a block that surrounds the function 
definition (which has its own block).  The function can see the 
variable because it is defined in the surrounding block.  It keeps 
on seeing the variable because perl is lexically scoped.
 
> 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()

That looks right.  As you might guess, closures can be (and are in 
many languages) used to implement objects with persistent state.
  
> > > 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.  

I'd call that "implicit" block demarcation (or at least not as 
explicit as a set of curly braces or <block> </block> syntax).

> This would result in abiguity if Perl's 'lexical scoping' were
> used.  Am I following you correctly?

Actually, I'm not sure why python couldn't have lexical scoping.  I 
mean:

    block:
    i = 1
	def counter():
            i = i + 1
j = 2 // or something

would seem to be unambiguous, if you're right about the block rule 
(I just made up "block:", but that's no problem in theory).  Again, 
it's not a great benefit to replace object-like stuff, but defining 
call-backs in user-interfaces is much nicer this way.

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

The whole langugage is statement based.  This is why you *can't* 
just break up a statement onto multiple lines:

    if a == 3 or
       b == 5 or
       c == 6:
         //something here

can't work without special casing or something since the carriage 
return is the statement delimiter.
 
> 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.

Right; assignment inside of if is a problem.  But the problem there
isn't that C is statement based, rather it's that C doesn't know
what truth is. :-)  Seriously, the condition of an if or for should
explicitly a boolean, not just some numeric thingy.
 
> 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?

Making just assignments into expressions is not that useful, other
than for consistency. But making everything be an expression is what 
makes the code-layout of C or perl or what have you so free and 
easy.  And it makes some idioms like error-checking a lot more 
pleasant:

    open(AFILE, "somefile.txt") or die("can't open file: $!);

which does just what you think if you know that booleans
short-circuit.  (OK; so I should "use English;" instead of $!, but I
forget whether it's $ERRSTR or what.)  That again works because
open() is an expression whose return value tells you whether you won
or not.  I could go on, but I won't.

jking


_______________________________________________
members mailing list
EMAIL:PROTECTED
http://mlug.missouri.edu/mailman/listinfo/members