A class question

[Donn Ingle]

Hello,

Is there a way I can, for debugging, access the instance variable name from
within a class?
E.g:
Class X:
def debug(self):
print "My instance var is %s" % (some magic Python stuff)

So that:

>>>x = X()
x.debug()
My Instance var is x

( Without passing the name in like: x=X(name="x") )

Thx.
\d

[Bruno Desthuilliers]

Donn Ingle a écrit :

Hello,

Is there a way I can, for debugging, access the instance variable name from
within a class?
E.g:
Class X:
def debug(self):
print "My instance var is %s" % (some magic Python stuff)

So that:

>>>x = X()
x.debug()
My Instance var is x

( Without passing the name in like: x=X(name="x") )

What should be the "variable name" in the following situations ?

a = b = c = X()
X().debug()

[Carl Banks]

On Oct 28, 6:01 am, Donn Ingle <donn.in...@gma il.comwrote:

Hello,

Is there a way I can, for debugging, access the instance variable name from
within a class?
E.g:
Class X:
def debug(self):
print "My instance var is %s" % (some magic Python stuff)

So that:

>>x = X()
x.debug()
My Instance var is x

( Without passing the name in like: x=X(name="x") )

You could search the global and local namespaces of the caller for a
symbol that's bound to the same object as self. For instance, to find
a such a symbol in the caller's global namespace, this might work:

def debug(self):
for sym,value in sys._getframe(1 ).f_globals:
if value is self:
print "My instance var is %s" % sym

Improving the example left as an exercise. There's probably quite a
few recipes to do stuff like this in the Python Cookbook (quod
googla).

Also, note that some objects are not bound to any symbols but instead
are referenced by lists or other containers.
Carl Banks

[Bruno Desthuilliers]

Hrvoje Niksic a écrit :

Donn Ingle <do********@gma il.comwrites:

>Is there a way I can, for debugging, access the instance variable name from
within a class?
E.g:
Class X:
def debug(self):
print "My instance var is %s" % (some magic Python stuff)

As others have answered, an instance can live in many variables,

"be bound to many names" would be more accurate IMHO. Python's
"variables" are name=>object bindings.

[Martin Marcher]

2007/10/29, Hrvoje Niksic <hn*****@xemacs .org>:

Sbe unpx inyhr, urer vf n cbffvoyr vzcyrzragngvba:
...

was that on purpose?

martin

--
http://noneisyours.marcher.name
http://feeds.feedburner.com/NoneIsYours

[Hrvoje Niksic]

Bruno Desthuilliers <br************ ********@wtf.we bsiteburo.oops. com>
writes:

>As others have answered, an instance can live in many variables,

"be bound to many names" would be more accurate IMHO.

Technically more accurate maybe (but see below), but I was responding
to a beginner's post, so I was striving for ease of understanding.

Python's "variables" are name=>object bindings.

No reason to use quotes. Variable is just as acceptable a term, one
used by Python itself, as witnessed by the "vars" builtin, but also in
PEP 8, in the language reference, and elsewhere in the docs. Even the
quite technical language reference uses both terms, such as in this
paragraph under "Naming and binding":

If a name is bound in a block, it is a local variable of that
block. If a name is bound at the module level, it is a global
variable. (The variables of the module code block are local and
global.) If a variable is used in a code block but not defined
there, it is a free variable.

I disagree with the idea that the terms "name" and "binding" are the
only correct terminology. Python is not the first language to offer
pass-by-object-reference assignment semantics. It shares it with
Lisp, Java, and many others, none of which have problems with the term
"variable".

[emorfo]

On Oct 29, 12:46 pm, "Martin Marcher" <mar...@marcher .namewrote:

2007/10/29, Hrvoje Niksic <hnik...@xemacs .org>:

Sbe unpx inyhr, urer vf n cbffvoyr vzcyrzragngvba:
...

was that on purpose?

martin

--http://noneisyours.mar cher.namehttp://feeds.feedburne r.com/NoneIsYours

for humans:
For hack value, here is a possible implementation:
import inspect
def _find(frame, obj):
for name, value in frame.f_locals. iteritems():
if value is obj:
return name
for name, value in frame.f_globals .iteritems():
if value is obj:
return name
raise KeyError("Objec t not found in frame globals or locals")
class X:
def debug(self):
print ("Caller stores me in %s (among other possible places)"
% _find(inspect.c urrentframe(1), self))

>>xyzzy = X()
xyzzy.debug ()

Caller stores me in xyzzy (among other possible places)

>>a = b = X()
a.debug()

Caller stores me in a (among other possible places)

>>b.debug()

Caller stores me in a (among other possible places)

>>X().debug()

Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 4, in debug
File "<stdin>", line 8, in _find
KeyError: 'Object not found in frame globals or locals'

[Bruno Desthuilliers]

Hrvoje Niksic a écrit :

Bruno Desthuilliers <br************ ********@wtf.we bsiteburo.oops. com>
writes:

>>As others have answered, an instance can live in many variables,

"be bound to many names" would be more accurate IMHO.

Technically more accurate maybe (but see below), but I was responding
to a beginner's post, so I was striving for ease of understanding.

The problem is that your formulation implies (to me at least) that the
variable is actually a kind of container for the object. And I'm not
sure being inaccurate really helps (OTHO, I often tend to get too
technical, so who knows which approach is the best here... At least, the
OP will now have both !-)

>Python's "variables" are name=>object bindings.

No reason to use quotes.

Yes, there's one : to mark the difference between Python-like
name=>object bindings and C-like labels-on-memory-address variables -
the latter model being the most commonly known to beginners.

Variable is just as acceptable a term,

Indeed - no need to refer to chapter and verse here, I've read the book
too !-)

(snip)

I disagree with the idea that the terms "name" and "binding" are the
only correct terminology.

Which is not what I meant here.

[Hrvoje Niksic]

Bruno Desthuilliers <br************ ********@wtf.we bsiteburo.oops. com>
writes:

The problem is that your formulation implies (to me at least) that the
variable is actually a kind of container for the object.

I really didn't expect it to be read that way, especially since the
sentence claims that the same instance can reside in several
variables. If the term variable implied containment, that would not
be possible because different variables would imply different objects.

To be fair, the OP probably *did* confuse variables with containment,
and I rot13'ed my hack to avoid unnecessarily prolonging that
confusion. However, I don't think his confusion is a consequence of
inaccurate terminology, but of an inaccurate mental model of Python
objects. When the mental model is correct, the term "variable" works
as well as any other; when it's incorrect, using different words for
the same thing is of little help.

>>Python's "variables" are name=>object bindings.

No reason to use quotes.

Yes, there's one : to mark the difference between Python-like
name=>object bindings and C-like labels-on-memory-address variables
the latter model being the most commonly known to beginners.

Are you sure about the last part? It seems to me that in recent times
more Python beginners come from a Java background than from a C one.
In any case, "variable" is a sufficiently general concept not to be
tied to a specific implementation. That the concept of variable
differs among programming languages is for me not reason enough to
eschew it.

[Bruno Desthuilliers]

Hrvoje Niksic a écrit :

Bruno Desthuilliers <br************ ********@wtf.we bsiteburo.oops. com>
writes:

>The problem is that your formulation implies (to me at least) that the
variable is actually a kind of container for the object.

I really didn't expect it to be read that way, especially since the
sentence claims that the same instance can reside in several
variables. If the term variable implied containment, that would not
be possible because different variables would imply different objects.

To be fair, the OP probably *did* confuse variables with containment,
and I rot13'ed my hack to avoid unnecessarily prolonging that
confusion. However, I don't think his confusion is a consequence of
inaccurate terminology, but of an inaccurate mental model of Python
objects.

I'd think it has more to do with an inaccurate mental model of Python's
variables - hence my (perhaps useless) corrections.

When the mental model is correct, the term "variable" works
as well as any other; when it's incorrect, using different words for
the same thing is of little help.

This is where our POV differ. IMHO, wording and mental model have a
strong relationship - IOW, incorrect wording leads to incorrect
representation.

>>>Python's "variables" are name=>object bindings.
No reason to use quotes.

Yes, there's one : to mark the difference between Python-like
name=>object bindings and C-like labels-on-memory-address variables
the latter model being the most commonly known to beginners.

Are you sure about the last part?

Ok, I would not bet my hand on it !-) But the (non appliable) "pass by
value"/"pass by reference" question is still asked often enough here to
be an indication.

It seems to me that in recent times
more Python beginners come from a Java background than from a C one.

Java does have "container" variables for primitive types, and even for
"references ", Java's variables are more than names - they do hold type
informations too. Now I don't pretend to know how this is really
implemented, but AFAICT, and at least from a cognitive POV, Java's
variables model looks very close to the C/C++ model.

FWIW, I came to Python with a VB/C/Java/Pascal background, and Python
was the first language for which I needed to revise my mental model of
the "variable" concept.

In any case, "variable" is a sufficiently general concept not to be
tied to a specific implementation.

I'd say it's like the "type" concept : it's a general concept, but it's
not totally implementation-independant. "Type" doesn't mean exactly the
same thing in static or dynamic languages...

That the concept of variable
differs among programming languages is for me not reason enough to
eschew it.

I didn't mean to imply "variable" was an inappropriate term - just that
it may have a somewhat different meaning wrt/ some others more
mainstream languages. My humble experience is that rewording the whole
concept in terms of name=>object bindings did sometime help in the past.