At 10:05 AM 7/6/2006 -0500, [EMAIL PROTECTED] wrote: > jan-python> So.. are we only thinking about implementing this outer > jan-python> scope assignment because there's lots of talk about it on > jan-python> the list, ... > >:-) > > jan-python> ... or are there actually use cases that would become > jan-python> clearer if assigning to an outer scope variable was allowed? > >I think full lexical scoping will only be of use to people who use nested >scopes heavily. The more typical user will be happy to just refer to values >in outser scopes without modifying them and rely on classes to save changed >state across calls. I think it's almost a YAGNI, but I'm sure others will >disagree.
Here's the reason I think this keeps coming up, and why Guido's "just use a class" argument doesn't really address the actual problem that's taking place. When you are writing some function, and you find yourself using a nested function because it's the closest match for something you're doing, there occasionally comes a point at which you realize that, gosh, you need to mutate something in an outer scope. At that point, your choices are to either kludge it with a mutable, or to reorganize the whole thing. Both of these *feel* like warts because they're making you do less-than-optimal things. Your mental "flow" is disrupted because the language is forcing you to work around it, rather than having a way of working with it. This is a user experience issue, not a technical one. The fact that you can say, "you should've done it differently in the first place" doesn't do anything for your flow. In theory, you could design cars without any brakes, because people could just coast to a stop if they planned well enough in advance. ;-) In practice, you need the brakes because people often don't discover their need to stop until much later in the process. This is a flow issue that's specific to *incremental* development. What happens is that first you refactor the code in a function to include nested functions. The variable references don't change, you're just indenting some code. *Then*, it later comes up that you need to rebind a variable, and now you have to globally change the variable to make it work as a mutable instead, or else you have to refactor all the variables to be 'self.' references and put a class in somewhere. This destroys the flow of incrementally developing whatever it is you're developing, and makes you stop to do excise work. That's why being able to rebind a variable without redefining it is important. In short: in *theory*, a rebinding operator or "nonlocal" declaration is unnecessary. In *practice*, having one seems quite useful every time you wander down the path that leads to having to rewrite your code just because the language won't let you do that one tiny thing -- or so it feels like to the person who's experiencing it. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
