On Jul 12, 2010, at 15:55 , Alf P. Steinbach /Usenet wrote: > * Rami Chowdhury, on 13.07.2010 00:14: >> Perhaps I'm misunderstanding, but ... >> >> On Jul 12, 2010, at 13:57 , Alf P. Steinbach /Usenet wrote: >>> >>> Existence of a variable means, among other things, that >>> >>> * You can use the value, with guaranteed effect (either unassigned >>> exception >>> or you get a proper value) >> >> Surely by that definition any variable in any Python program "exists" -- you >> are guaranteed to get one of NameError, UnboundLocalError, or a value. That >> seems to argue away the meaning of the word entirely, and renders it not >> particularly useful. > > No, you're conflating non-existence (NameError) with accessing the value of > an existing but unassigned variable (UnboundLocalError). It is like arguing > that vacuum is the same as cement because sticking your head into it for ten > minutes or so yields an effect -- you're dead -- that in many ways is > just about the same.
Right -- but you're playing with the definition of "existence" there, and since you're not using it quite consistently, I wasn't sure what you meant. Your discussion of the language reference below helps clear it up. > >>> How the Python implementation implements that is an implementation detail. >>> >>> In short, how CPython does things is completely irrelevant to the language's >> semantics, so you're conflating things here. >>> >> >> As I'd understood the previous discussion, it is the CPython implementation >> that reserves local names and produces UnboundLocalErrors. The language >> semantics don't call for it, and another implementation might choose to >> handle >> function locals the same way as globals, through a namespace dictionary -- in >> which case the variable *wouldn't* exist in any way, shape, or form until it >> was assigned to. >> >> What am I getting wrong here? > > The bit about the language semantics not specifying the effect. > > From the 3.1.1 language reference ยง4.1: > > "When a name is not found at all, a NameError exception is raised. If the > name refers to a local variable that has not been bound, a UnboundLocalError > exception is raised. UnboundLocalError is a subclass of NameError." > > And it goes on to elaborate on that, a little later: > > "If a name binding operation occurs anywhere within a code block, all uses of > the name within the block are treated as references to the current block. > This can lead to errors when a name is used within a block before it is > bound. This rule is subtle. Python lacks declarations and allows name binding > operations to occur anywhere within a code block. The local variables of a > code block can be determined by scanning the entire text of the block for > name binding operations." Ah, interesting. Thank you for pointing that out -- I didn't know that. I notice the same paragraph is in the 2.7 reference, so it presumably holds for 2.x implementations as well. > This is the usual reaction of the religious when exposed to reality. > > Cheers & hth. It does, thank you. Although the repeated references to the "religious" and their "refusal to accept reality" are less than helpful. > > -- > blog at <url: http://alfps.wordpress.com> > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
