[Python-Dev] LOAD_NAME & classes

Scott Gilbert xscottg@yahoo.com
Thu, 25 Apr 2002 01:30:27 -0700 (PDT)


--- Tim Peters <tim.one@comcast.net> wrote:
> 
> instead (the expression
> 
>     count([2, 3, 4]) | "oops!"
> 
> becomes
> 
>     10([2, 3, 4]) | "oops!"
> 
> because the once-local "count" in f is suddenly global, and retains its
> value of 10; then 10([2, 3, 4]) fails, and the alternative "oops!" is
> tried
> and succeeds).
> 

Yep that's ugly.  I never wrote any programs in Icon larger than a couple
thousand lines, and I never used Icon in a team setting, so I didn't get
bit by things like this.


> 
> I prefer Python distinguishing between None and unbound too; e.g., I'd
> much
> rather have
> 
>     x := y
> 
> blow up at once if y hasn't been bound than to silently propagate &null
>

I have mixed feelings on this one.  I remember using the / and \ operators
all over the place to work around it, so in that regard I guess I didn't
like it.  On the other hand it nicely parallels how tables would return
&null (or other default) for keys that weren't already in there, and that I
liked.

In Python, I use the d.get('key', default) construct quite a bit.  Probably
because I learned to like getting a default value from Icon.  I could use a
DefaultDict class derived from dict, but that's less convenient and doesn't
help me with **kwds arguments.  Plus it's a hindrance to someone reading my
code who knows what Pythonic behavior is supposed to be.

No one says that key lookup in dicts/tables and variable lookup in the
namespace have to follow the same rules though.  It just seems that they do
in both Icon and Python.  Each with a different choice for rules.

>
> (very few things in
> Icon raise errors, as the 10([2, 3, 4]) example should have suggested to
> onlookers <wink>).
> 

I took two Icon courses from Ralph, and several times while sitting in
class, I got the impression that he regretted a lot of things like this. 
Having integers usable in the place of functions was odd and rarely useful.
 He also didn't seem to have much respect for co-expressions.  He was
really excited about the graphics features though.

Now *strings* as functions, that I used.  :-)

I think part of the charm of Icon was* that it felt like an experiment to
see what cool new concepts come out of letting anything do everything. 
When it comes time to teach it or use it in a large project, having the
language force a little more bondage is probably a good thing.


* - I should say "charm of Icon is".  It looks like it's still got
something of a pulse in academia...  In fact the latest version just built
under Cygwin without major headaches.

> 
> Unfortunately, -u doesn't complain about the "10 oops!" example above: 
> as
>

Yeah, a  -U-and-I-really-mean-it  flag would fix this.  :-)

Maybe if procedures were "const" the problem would go away.  (While
probably creating some new problem that I'm not thinking of...)


Trying to draw this back as relevant to Python and this thread:

I think Icon has an easier time with scoping rules than Python because
execution starts in "procedure main()", not the beginning of the file. 
Since code isn't floating out there at the topmost level, one can't create
variables there without an explicit global declaration.  There really are
only two scopes for global and local.  (And some builtins of course...)

Following this thread and reading some of the examples, I don't think I
have a deep grasp of what the rules are in Python.  I just have a set of
conventions that I follow which seem to keep me out of trouble.

Your example of:

    x = 2
    def f():
        print x
        #x = 3     ### uncomment to go BOOM

kind of surprised me.  I presented it to another co-worker who wasn't very
Python savvy.  It caught me off guard that he expected the exception at the
print statement, but he didn't realize it only occurs when you have the
"local declaration" later.

> 
> Like an implicit "import *" in Python -- we're well aware of the dangers
> of *that* around here <wink>.
> 

Yep, and I litter my libraries with underscores to protect from it.  A
number of users at my company gripe about having to use parens and commas
for function calls, especially in interactive mode, so convincing them to
use module.function(arg, arg, arg) is going to be a really tough sell... 
(Someone suggested the LazyPython hack as a sort of solution to the first
problem, but they would prefer "import module" defaulted to the bad
behavior)

The underscores also make it easy to see when something is global or not,
avoiding the BOOM in your example above.


> > So it really wasn't so error prone.  (Icon's not even close to
> > Perl in this regard.  :-)
> 
> Not for scope rules alone, no, although Perl sticking to explicit "my"
> everywhere isn't much worse than Icon sticking to explicit "local"
> everywhere.
> 

My nostalgia for Icon makes me forget about any of the bad things.  I don't
have much nostalgia for Perl, so it's faults I remember.


Cheers,
    -Scott



__________________________________________________
Do You Yahoo!?
Yahoo! Games - play chess, backgammon, pool and more
http://games.yahoo.com/