Fact is, I just can't follow discussions of mechanism without reference
to _some_ more-or-less concrete problem they're intended to solve, and I
had no problem with Python's current scope rules before a feature was
introduced (namely lambdas) whose use in practice often requires a bit
more than Python now allows.
One of the first good papers to seriously question the value of classical
nested scopes is Dave Hanson's "Is Block Structure Necessary?" (Software
Practice & Experience, Vol 11, pp 853-866, 1981). He argues that CSNS
creates at least as many problems as it solves, that simple non-nested
modules solve the same problems without CSNS's drawbacks, and illustrates
with non-trivial programs written idiomatically in both styles.
Agree with him or not-- and I mostly do --at least you can figure out
what he's talking about <grin>. So the next time a scoping extension is
proposed here, would the proposer please illustrate with a semi-realistic
example of a problem whose solution, in Python, would be "better"
(cleaner, more understandable, safer, more maintainable, whatever ...)?
That's not just for my sake -- especially if you're a newcomer to Python,
you may discover there's a better way to do it already! Python is clear,
but it's not self-evident ...
> [steve]
> ...
> Since some of the desire for anonymous functions and/or nested function
> definition were due to wanting to try to avoid cluttering up the
> exported name space with local function, perhaps a module statement
> could help manage namespace by making it easy to create
> sub-name-spaces:
>
> module xxx:
> prompt = "Hello, sailor!"
> def yyy():
> ...
>
> I don't think THAT part of the scheme should be very controversial,
It might be if you spelled out all the rules <wink>. E.g., is "prompt"
visible inside "yyy" short of spelling it "xxx.prompt"? And if the
thrust really is to avoid cluttering the exported namespace, perhaps a
by-now-classical "export" statement (limiting external visibility, when
present, to an explicit list of module-global names) would be more to the
point?
> but adding other functions to manipulate environments ( like real
> versions of my bind() and merge(), etc. ) might be, and I haven't
> thought out the implications myself.
So let's try to solve a real problem with them -- implications live in
the trenches. What do you imagine doing with them?
It's at least interesting that Guido's default-argument idea, when
(ab?)used to sneak values into the function's local NS, effectively
creates a partial closure (the function, + a fixed-for-all-time binding
for each of the default-valued arguments).
> [guido]
> I have also thought of somehow unifying modules and classes ...
The only difference I see between Steve's
module xxx:
prompt = "Hello, sailor!"
def yyy():
and
class XXX:
prompt = "Hello, sailor!"
def yyy():
is that XXX.yyy() yields a "unbound method must be called with class
instance argument" TypeError, while xxx.yyy() presumably wouldn't.
Wonder what multiple inheritance for a _module_ might mean <grin?>.
> ...
> I still think there is not enough need for CSNS to warrant this kind of
> construct, which can easily confuse the human reader when there are
> more than two or three scopes involved and some are textually far apart
Well, I don't see any need for CSNS (assuming something simpler can be
done about lambda), but want to emphasize that CSNS _in Python_ would be
3x more confusing than in Pascal/Ada/whatever. As Steve implied, the
lack of declarations means a user has to study the entire text of every
enclosing function to figure out where a non-local might get resolved.
The pain is much less in Pascal/Ada/whatever, because in those you only
have to look "up", and only at declaration statements.
security-thru-obscurity-ly y'rs - tim
Tim Peters tim@ksr.com
not speaking for Kendall Square Research Corp