jojoba wrote:
> However, does it not seem reasonable to ask python:
>
> Given a dicitionary, Banana = {}
> return one or more strings,
> where each string is the name(s) of the reference(s) to Banana.
No, it doesn't. It'd be like having an open file descriptor in C and
then asking what filename(s) that file has, something that new
programmers also ask about but doesn't make much sense when you stop
and think about it.
The way name-binding works in python, names can exist in certain
scopes. They can be global to a module, local to a certain
class/function, etc. A name can refer to many different objects over
time. An object can have many different names in different scopes.
Suppose you have:
class a(object):
def __init__(self, something):
self.widget = something
class b(object):
def __init__(self, something):
self.gadget = something
def printStuff(self):
PrintPythonNames(self.gadget)
mything = dict()
aList = [ a(mything) ]
B = b(mything)
B.printStuff()
Does it really make sense to you to have names in class a's scope
available from inside B? What if it were a.__widget? Further, what
sense would it make? What if other threads had names referencing the
dict object that were changing during the b.printStuff() call? Are you
going to try to lock the entire namespace while you look to see what
things in every scope could hold references to the object you're trying
a reverse lookup on?
Going from a name to an object is inherently a one-way operation, and
trying to manufacture a reverse lookup just doesn't make sense in
general.
--
http://mail.python.org/mailman/listinfo/python-list
