On Fri, May 29, 2020 at 10:51 PM Steven D'Aprano <st...@pearwood.info> wrote: > > On Thu, May 28, 2020 at 08:04:07PM +1000, Chris Angelico wrote: > > If it's a > > language feature, then the name 'x' must be in the state of "local > > variable without a value". > > Oh ho, I see what you are doing now :-) > > I'm going to stick with my argument that Python variables have two > states: bound or unbound. But you want to talk about the *meta-state* of > what scope they are in: > > LEGB = Local, Enclosing (nonlocal), Global, Builtin > > There's at least one other case not captured in that acronym, Class > scope. There may be other odd corner cases. > > In any case, if you want to distinguish between "unbound locals" and > "unbound globals" and even "unbound builtins", then I acknowledge that > these are genuine, and important, distinctions to make, with real > semantic differences in Python.
The reason locals are special is that you can't have a module-level name without a value, because it's exactly the same as simply not having one; but you CAN have a local name that must be exactly that local, and you can't look up a module or builtin name, but it still doesn't have a value. I believe local scope is the only one that behaves this way. > But I think that the scope of a variable is metadata (metastate), when > it comes to the state of any variable (whether LEGB or C) it can be > bound to a value or unbound and that's all. Sure. But "unbound" is a state. In theory, you could have an optional parameter which, if no value is given, has no value stored in it. > At this point I'm not sure what, if any, difference to the current > discusion it will make whether we label a variable's scope metastate or > state. Agreed, I don't care whether it's "state" or "metastate". I would just call it "state" - the name has no value associated with it, yet it is local - but if you want to consider it a metastate of "unbound" as distinct from its main state (which would be the value), then sure. > > This is a valid situation. There is no value, but this is the state of > > the variable. It's not "no state" any more than zero is a non-number > > or NULL is a non-pointer. > > Zero is definitely a number with a value. It's the additive identity. > > NULL being a pointer is, I think, a mere consequence of the impoverished > type systems of languages like C :-) > > The idea of NULL is that it should be just pointer-ish enough to satisfy > the compiler and allow you to assign it to pointer variables, but not > pointer-ish enough to fool the compiler into allowing you to dereference > it and crash the machine. > Exactly. All of them ARE states. A box containing nothing is validly containing zero things. A NULL pointer is an actual thing. And an unbound local name is a real situation that can be seen. ChrisA _______________________________________________ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/UVJUHUGSKBEA2J35ATP4UNEV6XL3VMHB/ Code of Conduct: http://python.org/psf/codeofconduct/
