On Mon, 18 Aug 2003, Benjamin Goldberg wrote:
> > Hmm. Do you mean
> >
> > if for stmt in block:
> > if stmt.type == undef:
> > flag_as_going_to_delet(stmt.varname)
> >
> > So I can create a new pad when it's assigned?
>
> Right. You'd create a new pad just before the "for", and put "stmt"
> into it. After the for loop ends, you pop off that pad.
> > It can't be a simple pop though, can it?
>
> Why not?
Because in my examples, I don't see how you know
it's the topmost lexical pad.
> These are dynamic variables here; could you give an example of what
> you're trying to do with lexicals (my variables)?
Sure.
It does the exact same thing if you put "my" in front of each variable:
#!/usr/bin/perl
my $x = "cat";
my $y = "pop $x?";
undef $x;
print "x = $x \n";
print "y = $y \n";
> And remember, undef doesn't get rid of a variable; it merely stores
> an undef value into it.
But it has the same effect as getting rid of the variable,
since a variable that doesn't exist also returns undef. :)
> I mean, consider:
>
> #!/usr/bin/perl
> use strict;
> { my $x = "cat";
> { my $y = "pop $x";
> # $x and $y are both in scope.
> undef $x;
> # $x and $y are still both in scope.
> $x = 2; # no error here!
> } # $y goes out of scope.
> $x = 42; # ok.
> $y = 6*9; # but this is an error.
> } # $x goes out of scope now.
> $x = 13; # this is an error.
> __END__
>
> There's no way, in this program, for $x to be out of scope while $y is
> in scope.
Yes, but this is just normal lexical scoping behavior.
I'm already doing the same thing for python.
You say that in perl, undef $x means $x = PerlUndef, which
is fine. But in python, that's not the case. "del x" gets
rid of the variable, so that the next find_lex should throw
a NameError. I don't see the point in creating an extra
lexical scope for every variable that gets deleted.
And that's not what you're telling me anyway.
In your innermost block, you're telling me that on the
python equivalent of the "undef $x" line i should be
popping off a lexical pad in python. I'm saying
that's not the case. I should be removing x from the
lexical pad. If perl does the same thing, then you
get the same behavior as undef x, because an unfound
lexical in perl just returns PerlUndef anyway.
> > x = 1
> > del x
> > x
> >
> > So the easiest thing to me is just to translate
> > del x as "remove this from the current pad".
>
> Maybe. But, what happens with:
>
> x = 1
> y = lambda: x
> del x
> z = y()
>
> Does/should this also throw a NameError?
Looks like it:
>>> x = 1
>>> y = lambda : x
>>> del x
>>> z = y()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "<stdin>", line 1, in <lambda>
NameError: global name 'x' is not defined
Anyway, the short answer is I'm happy with the
solution I've got now. It's easy and it does
what I expect. But I'll happily change it if
you send me a patch. :)
Sincerely,
Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: [EMAIL PROTECTED]
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------
