learning python ...

Peter J. Holzer hjp-python at hjp.at
Thu May 27 15:16:05 EDT 2021


On 2021-05-27 20:59:47 +0200, hw wrote:
> On 5/25/21 3:09 PM, Greg Ewing wrote:
> > On 25/05/21 5:56 pm, Avi Gross wrote:
> > > Var = read in something from a file and make some structure like a
> > > data.frame
> > > Var = remove some columns from the above thing pointed to by Var
> > > Var = make some new calculated columns ditto
> > > Var = remove some rows ...
> > > Var = set some kind of grouping on the above or sort it and so on.
> > 
> > As long as all the values are of the same type, this isn't too bad,
> > although it might interfere with your ability to give the intermediate
> > results names that help the reader understand what they refer to.
> > 
> > A variable that refers to things of different *types* at different
> > times is considerably more confusing, both for a human reader and
> > for any type checking software you might want to use.
> 
> How would this matter when the variables are typeless?

It doesn't matter for Python. It does matter for some people -
especially those that think that variables have (or should have) a type.

Of course "type checking software" follows that paradigm.


> Often times, it's not very practical to figure out the type of a value
> before assigning it to a variable ...

In statically typed languages (like C, Java, Go, ...) you have to do
that. In dynamically typed languages like Python you don't and in
general can't.


> > > How can you write a recursive function without this kind of variable
> > > shadowing? Each invocation of a function places the internal
> > > namespace in front of the parent so the meaning of a variable name
> > > used within is always backed by  all the iterations before it.
> > 
> > Um, no. What you're describing is called "dynamic scoping", and
> > Python doesn't have it. Python is *lexically* scoped, meaning that
> > only scopes that textually enclose the function in the source are
> > searched for names. Frames on the call stack don't come into it.
> > 
> > > So what if you suggest we allow re-use of names but WARN you. ...
> > > The first 50 places may be in other instances of the recursive
> > > function and you have already been warned this way 49 times
> > 
> > If this were to be done, the shadowing would be detected at compile
> > time, so you would only be warned once.
> 
> Works fine in perl (and you can have it without warnings if you want to,
> though that's not recommended):
> 
> 
> perl -e 'use warnings; my $shadow; my $shadow; my $shadow';
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.
> "my" variable $shadow masks earlier declaration in same scope at -e line 1.

That's something different. Here you are redeclaring the same variable
in the same scope (Note that this cannot happen in Python because you
don't declare variables in Python). 

If you write something like this:

--------------------
#!/usr/bin/perl
use v5.12;
use warnings;

my $x = 5;
{
    my $x = 10; 
    say $x;
}
say $x;
--------------------

You won't get a warning, and the program will print 
--
10
5
--


But dynamic scope is something different. It's based on the call stack,
not syntax. In Perl, you get dynamically scoped variables with local.
This is quite deprecated and mostly used to temporarily shadow
predefined variables like $/ (although I've occasionally used it for
other purposes, too).

        hp

-- 
   _  | Peter J. Holzer    | Story must make more sense than reality.
|_|_) |                    |
| |   | hjp at hjp.at         |    -- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |       challenge!"
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://mail.python.org/pipermail/python-list/attachments/20210527/61c6ce06/attachment.sig>


More information about the Python-list mailing list