nested scopes

[Martin von Loewis]

Geoffrey Gerrietts <geoff at homegain.com> writes:

> I think that part of your confusion might be based on your conception
> of what a module is for. The premise upon which you base your argument
> is that you will not be using the names you acquire in a dynamic way.

I think this is a fair assumption. You give a counter-example;
unfortunately, I cannot understand that example:

> For example, if I have a large file, or a large collection of files,
> all of which contain a large number of variable definitions, I can
> suck those up into a function and use dir() to grab the list and do
> things with them.

How do you exactly do this? If you have a list of module names, it
appears that you will need to do

def foo(module_names):
  for m in module_names:
    exec "from %s import *" % m
  return dir()

or something like that. That continues to work in the current CVS
Python, since the check for import is a static check, not a dynamic
one. Or did you have a different algorithm in mind which would stop
working?

In any case, it might be better to rewrite this function as

def foo(module_names):
  result = []
  module = {}
  for m in module_names:
    exec "from %s import *" % m in module
    result += dir(module[m])
  return result

Even better might be

def foo(module_names):
  result = {}
  for m in module_names:
    exec "from %s import *" % m in result
  return dir(x)

With that, you execute the import neither in local nor in global
namespace; you do so in a "fresh" namespace.

> While I can't say I don't find nested scopes interesting, I confess
> that I find them just as troublesome, and I'm really kinda sad to
> see dynamic features yanked from the language (even if they're
> unintentional features) just so we can have nested scoping.

I can't see any dynamic features being yanked - I can see that of the
many ways to do a certain dynamic thing, one way is removed.
There's Only One Way To Do It, anyway.

Regards,
Martin