Chris Angelico <ros...@gmail.com> writes: > On Mon, Sep 14, 2015 at 9:17 AM, Akira Li <4kir4...@gmail.com> wrote: >> If you mean this quote from [1]: >> >> Although we commonly refer to "variables" even in Python (because it's >> common terminology), we really mean "names" or "identifiers". In >> Python, "variables" are nametags for values, not labelled boxes. >> >> then *name* is the term that is defined in the Python language >> reference. The word "variable" we can use in day-to-day programming >> _unless_ we are discussing issues that are specific to _naming and >> binding_. In that case, we should use the _exact_ >> terminology. Otherwise there is nothing wrong with using "variables" >> casually in Python. > > Since you're talking about precise terminology, I think it would be > better to say "name binding", rather than "naming and binding". When > you talk of naming something (or someone!), you generally mean that > it's possible to go from the thing to the (canonical) name. With > people, for instance, you can walk up to someone and say "Hi! What's > your name?", but with Python objects, you fundamentally can't.
"Naming and binding" is the title from the Python language reference https://docs.python.org/3/reference/executionmodel.html#naming-and-binding Otherwise, I agree with you ("name" is better here). >>> Everything you wrote here has the same issue: The "objects" you are >>> talking about do not physically exist, but are simply the result of >>> calling a method on the object. Therefore they do not *belong* on the >>> diagram, and the diagram not showing them does not mean the diagram is >>> not complete. >> >> "do not physically exist" does not make sense. Objects are *never* >> destroyed explicitly in Python (you can only make them >> *unreachable*). You can disable garbage collection completely and it is >> still will be Python. Immutable objects can be considered immortal e.g.: >> >> (1+1) -- question: does the object that represents int(2) exist before >> the expression is evaluated? >> >> The correct answer: it does not matter: int(2) can be created on the >> fly, a cached int(2) can be reused by a specific implementation -- >> Python doesn't care. >> >> I don't see why the model that can't describe range(1) in Python 3 >> pretends to be complete. > > "Physically" isn't really the right word for it, given that objects in > Python code aren't physical and therefore don't *ever* "physically > exist". My bad there. > > But the objects completely do not exist. Yes, with integers you can't > tell... but what about here? > > dependencies = collections.defaultdict(list) > for fn in files: > for dep in gather_deps(fn): > dependencies[dep].append(fn) > > Until the moment when dependencies[dep] is requested for some new > value of dep, the list *does not exist*. It is constructed anew. > Obviously the end result of this is a dict of lists, and since those > lists aren't accessible from anywhere else, it makes fine sense to > talk about those lists as being "contained within" the (default)dict; > but they clearly didn't exist until they were poked at. They're > Heisenburg's Lists, I guess... lists are _mutable_ in Python. -- https://mail.python.org/mailman/listinfo/python-list
