how do you get the name of a dictionary?

[Fredrik Lundh]

And what im saying is that isnt it silly that we need pass an entire
namespace

namespaces are objects too, you know. passing "an entire namespace" is
no harder than passing any other object.

</F>

 

[Fredrik Lundh]

Right. Plus it's fun to imagine the effbot hitting itself as hard as
some people would obviously have liked to hit it in the past

you mean the guy who's spent the last six months downrating every single
post I've made on this list over at googlegroups ? I'd say it's safe to
ignore him; he's a certified nutcase.

</F>

 

[Steven D'Aprano]

Steven D'Aprano enlightened us with:

That's simply a very bad example.

No, it is a *simplified* example. There's a difference between simplified
and bad. Would you have preferred me to post five pages of complex
function calls demonstrating the same point, namely that you can bind an
object to a name in one place, then pass it to a function where any
tracebacks will refer to the name in the local namespace rather than the
name in the traceback where the invalid data first existed?

If you use a real-world function,
you notice that the current error messages are just fine:

def update(title):
assert len(title)> 10, "Title too short"

update("hello")

would display: "AssertionError: Title too short". Seems fine to me.

Sure, in this case you back-track one level, and see that you passed a
string literal. Easy.

And in other cases, you don't pass a literal, you pass a name (say,
"windowtitle"), and now instead of looking for the name title you're
looking for the name windowtitle. Where did it come from? What's
it's value?

And in some cases, windowtitle wasn't bound to a literal either, it was
bound to (say) filename.upper(), so now you're no longer looking for
either title or windowtitle, but filename. Where did it get its value
from?

 

[Steven D'Aprano]

for some reason, your example gives a different error on my machine:

StrawManError: Attempt to construct Reductio ad absurdum argument failed

Sheesh Fredrik, what's eating you? I'm trying to have a civil discussion,
and you're being deliberately obtuse.

If I'm factually wrong, if I've made an error of fact or logic, and
somebody points out where the error lies, I will accept that. I am always
willing to learn. But making fatuous, and false, accusations of strawman
and reductio ad absurdum fallacies doesn't invalidate my point that there
are occasions where the traceback refers to a object with one name, but
the object was created in a different scope with a different name. I'm not
making an extraordinary claim here -- what I said should be so obvious it
verges on the banal. The traceback reports the name of the object in the
scope the error occurred in. The line of code responsible for putting the
wrong data into that object can occur in a different scope, with a
different name. Is that really so hard to grasp?

I don't know what more I can do to get through to you that I *don't*
expect Python's object model to change to fix this one single issue. I've
said it AT LEAST twice times so far: such a change would be a lot of cost
for very minimal benefit. But after the undeserved roasting that Jojoba
received, it is only right to that we recognise that there are valid cases
for objects to know their own name -- even if, in the majority of cases,
those valid uses aren't worth the cost of implementing them.

 

[Duncan Booth]

Sheesh Fredrik, what's eating you? I'm trying to have a civil
discussion, and you're being deliberately obtuse.

I think you've missed the point that with the code you posted you raise the
ValueError unconditionally, so x isn't *any* of a, b, c, or d.

Perhaps, if you had produced a code sample where you tested some values for
being in a suitable range and it wasn't obvious from the traceback which
value was affected, you might have managed to make your point? Or perhaps
you would have found it harder to obfuscate the code than you think it is.

With the code you posted though, I'm afraid Frederik's observation was spot
on.

 

[Giles Brown]

Does anyone know how to find the name of a python data type.
Conside a dictionary:
Banana = {}

Then, how do i ask python for a string representing the name of the
above dictionary (i.e. 'Banana')?

As many people have already said this question doesn't really make
sense, but
I thought I'd add my explanation of why in the hope that it might
help...

Think of python objects as being like mobile phones. They only really
have a number.
Asking what their name is like asking for the name of a mobile phone
(bluetooth excepted).
A particular mobile phone only has a name when entered into the address
book (aka
namespace) of another mobile (or whatever) and the choice of name is
down to the owner of the address book.

Now I'm going to eat my cake.

Giles

 

[Steve Holden]

Steve Holden wrote:




you mean the guy who's spent the last six months downrating every single
post I've made on this list over at googlegroups ? I'd say it's safe to
ignore him; he's a certified nutcase.

Yeah, right. Doesn't seem to like what I have to say very much either,
but then the Google "rating" system is so lame that anyone who uses it
can probably safely be ignored for one reason or another.

regards
Steve

 

[Antoon Pardon]

please note: in my above comment, i was completely disregarding any
notions of added costs that would be incurred to have such a feature,
and that in fact, such costs might actually nullify any other benefits
from having such a feature. Purely a what-if idea from a nascent python
programmer.

Even from such a point of view, the concept isn't clearly enough defined.
What name would be assigned to the dict below?

l = [1,2,3]
a = "some_str"
l[0] = {'foo': 'bar'}

Some immutable objects, such as small integers, exist only once. Would you
assign names to them? They're likely to be completely meaningless.

When a name goes out of scope, but the object continues to live (e.g.
because it's returned by some function), the name is void.

I'm not so sure about that. Local functions can be returned and they
keep their name. Of course it depends on what you mean with the
name of an object. Do you mean the variable name or do you mean
the __name__ attribute?

 

[Georg Brandl]

And what im saying is that isnt it silly that we need pass an entire
namespace, when a much simpler notion would be to have each object know
its own name(s) (even if that name doesnt exist).


please note: in my above comment, i was completely disregarding any
notions of added costs that would be incurred to have such a feature,
and that in fact, such costs might actually nullify any other benefits
from having such a feature. Purely a what-if idea from a nascent python
programmer.

Even from such a point of view, the concept isn't clearly enough defined.
What name would be assigned to the dict below?

l = [1,2,3]
a = "some_str"
l[0] = {'foo': 'bar'}

Some immutable objects, such as small integers, exist only once. Would you
assign names to them? They're likely to be completely meaningless.

When a name goes out of scope, but the object continues to live (e.g.
because it's returned by some function), the name is void.

I'm not so sure about that. Local functions can be returned and they
keep their name.

Yes, but they cannot be refered to by that name any longer.

Of course it depends on what you mean with the
name of an object. Do you mean the variable name or do you mean
the __name__ attribute?

If you assign the variable name to an object, as proposed, both.

Georg

 

[MonkeeSage]

It's not inconcevable that Python could behave that way, it's just
that it would impose an overhead on the 99.999% of Python users who
would have no use for the feature. It's a price not worth paying.

I guess I don't get the problem with the OP's request, either. There is
already a name<->identifier mapping in place for objects. You can type
the object name and python magically gives you the object by matching
the name to the identifier. It would probably be pretty simple to
expose the name or names associated with the identifier, if any, via
built-in function or method. There would be no extra overhead. There
would be no speed hit if you didn't call the function/method. There
would be very little implementation expense (I would imagine), as the
code that is already in place to do look-ups from the parser to the
object map could probably be reused or hooked into. But seeing as it
isn't a general-purpose feature, and Steven's function would be
sufficient for most cases, I'm not saying it should be a core feature;
I'm just saying that I don't see what the big huff is about.

 

[Simon Brunning]

I guess I don't get the problem with the OP's request, either. There is
already a name<->identifier mapping in place for objects.

Do you mean a name<->object mapping?

This, I think, isn't true. There is a name->object mapping, but to
make that a name<->object mapping *would* carry an overhead. It might
(or might not) be a *small* overhead, but since every single Python
program would suffer the consequences, it's just not worth it.
Especially, as others have pointed out, that it wouldn't really be
very useful at all.

 

[Steve Holden]

I guess I don't get the problem with the OP's request, either. There is
already a name<->identifier mapping in place for objects. You can type
the object name and python magically gives you the object by matching
the name to the identifier. It would probably be pretty simple to
expose the name or names associated with the identifier, if any, via

Probably? Based on what assumptions (or knowledge of interpreter internals)?

built-in function or method. There would be no extra overhead. There
would be no speed hit if you didn't call the function/method. There
would be very little implementation expense (I would imagine), as the

Which demonstrates that imagination is a wonderful thing ...

code that is already in place to do look-ups from the parser to the
object map could probably be reused or hooked into. But seeing as it
isn't a general-purpose feature, and Steven's function would be
sufficient for most cases, I'm not saying it should be a core feature;
I'm just saying that I don't see what the big huff is about.

I don't think there's any big huff. It's just that Python has achieved
its current popularity largely by avoiding bloat and feature creep. As
you observe (or seem to), there isn't a one-to-one mapping between names
and objects anyway.

Put more simply, objects don't *have* names -- names are bound to
objects. So modifying the interpreter in the ways you suggest would add
unnecessary code to the compiler purely to meet a bogus requirement.

regards
Steve

 

[MonkeeSage]

Do you mean a name<->object mapping?

This, I think, isn't true. There is a name->object mapping, but to
make that a name<->object mapping *would* carry an overhead. It might
(or might not) be a *small* overhead, but since every single Python
program would suffer the consequences, it's just not worth it.
Especially, as others have pointed out, that it wouldn't really be
very useful at all.

I'm new here, and I've only been using python for about 6 months; so I
don't claim any deep knowledge of the inner workings of the interpreter
or anything.

Seemingly (and I realize that one or more of my premises may be wrong),
by simple deduction, there must be a two-way name (label) to identifier
mapping. I'm assuming that every object is accessed in the symbol table
by a unique identifier (exposed through id()), and that every name is
mapped to an identifier (some sort of heirarchy would seem to be
involved in the mapping, allowing for recursive objects, multiple names
for single ids, &c). Given this, some sort of look-up strategy would
seem to be in place for resolving objects from identifiers, and
identifiers from names. So if every name is mapped to an identifier,
and every identifier is mapped to an object; given any object, one
should be able to determine its identifier and all of the names
associated with that identifier (if any).

Obviously, that's based on several assumptions. Mabye I'm dead wrong on
some points. Anyhow, I don't think it's a feature that needs to be
there, or would even be useful in most cases; I just don't think it
would be a big issue if it were. If I'm correct, (lack of) usefulness
would be what militates against it being implemented as a core feature,
not the introduction of a size or speed overhead on objects.

Regards,
Jordan

 

[Dennis Lee Bieber]

Seemingly (and I realize that one or more of my premises may be wrong),
by simple deduction, there must be a two-way name (label) to identifier
mapping. I'm assuming that every object is accessed in the symbol table
by a unique identifier (exposed through id()), and that every name is
mapped to an identifier (some sort of heirarchy would seem to be

id() returns, in C based Python, the memory address at which an
object is stored. That is all... Names in Python are mapped to the
object -- essentially they are mapped to the address of the object.
There is NO intermediate hidden identifier.

involved in the mapping, allowing for recursive objects, multiple names
for single ids, &c). Given this, some sort of look-up strategy would

The recursion, and all, is basically handled by nested dictionary
structures.

{ "name" : address-of-object1, "name2" : address-of-object2,
"name3" : address-of-object1 }

Object 1 has two names bound to it. But the only way to find out what
those names are requires first having some other reference bound to the
object, and then asking each name if the id() (the address) matches the
id() of the reference in question.

{my apologies, that is a very badly phrased sentence}

The names refer to objects, but objects have nothing that refers
back to the names.
--
Wulfraed Dennis Lee Bieber KD6MOG
(e-mail address removed) (e-mail address removed)
HTTP://wlfraed.home.netcom.com/
(Bestiaria Support Staff: (e-mail address removed))
HTTP://www.bestiaria.com/

 

[MonkeeSage]

id() returns, in C based Python, the memory address at which an
object is stored. That is all... Names in Python are mapped to the
object -- essentially they are mapped to the address of the object.
There is NO intermediate hidden identifier.

[snip]

Object 1 has two names bound to it. But the only way to find out what
those names are requires first having some other reference bound to the
object, and then asking each name if the id() (the address) matches the
id() of the reference in question.

Ahh! I see. That makes sense. Thanks for taking the time to explain it
to a noob.

Regards,
Jordan