MonkeeSage wrote: > Simon Brunning wrote: > >>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
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 -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden -- http://mail.python.org/mailman/listinfo/python-list
