[Python-ideas] Object for accessing identifiers/names

[Koos Zevenhoven]

[This almost two-week-old draft email was apparently waiting for me to
hit 'send']

On Fri, Jun 3, 2016 at 9:22 AM, Steven D'Aprano <steve at pearwood.info> wrote:
> On Wed, Jun 01, 2016 at 10:22:39PM +0300, Koos Zevenhoven wrote:
>
>> Currently, there is no direct way to work with variable names from within
>> Python. Yes, you can fiddle with __dict__s and locals() and globals(),
>
> The usual way is to write the name as a string and operate on the
> namespace.
>
> That means that variables (names) are not themselves values: a name is
> bound to a value, but there is no value which is itself a name. Instead,
> we use a string as a form of indirection.
>

Indeed the point is to make it possible to, on demand, create a value
(object) representing a name.

>> but
>> there is no convenient general way. To solve this, there could be a way
>> (probably new syntax) for creating an object that
>> can examine and manipulate a name binding conveniently.
>
> Before getting too interested in the syntax for creating these, can you
> explain what you want to do with them? Most uses of names don't need to
> be values:
>
> spam = 23
> import spam
> del spam
>
> all work well on their own. Can you give some use-cases?
>

This is a variation of the 'given <name>' syntax that I proposed in
the matching syntax thread. So the truth value of the name object
would tell you whether the name is bound to a value or not, as I
explain in the OP of this thread too. But the __str__ of the name
object would give the name, so that would allow things like:

TypeVar(name_object)
sympy.Symbol(name_object)

and those constructors/callables would have access to the name in the
calling scope and would be able to bind the value to it without one
having to repeat oneself as in `alpha = sympy.Symbol('alpha')` etc.

This could also be used as instead of a callback that just needs to
assign to some variable in the calling scope (or the associated
closure).

You could potentially even `await` these things (until some other
thread or task sets the variable), although there is some overlap in
functionality with other awaitables of course.

I believe this might also help a little in the example that Michael
just posted in the other thread for matching and extracting values
within nested JSON-like structures.

I think there is more functionality that this could provide too.

[...]
>> Now this name_obj thing
>> could provide functionality like assigning to the name some_name, getting
>> the assigned object, and determining whether
>> something has been assigned to the name or not.
>
> Most of these things already work using strings:
>
> # bind a name to the global scope
> globals()[name_object] = 999
>
> # lookup a name in some module's namespace
> vars(module)[name_object]

But changing it does not work similarly. From the docs: """
Note
The contents of this dictionary should not be modified; changes may
not affect the values of local and free variables used by the
interpreter.
"""

> # check for existence
> name_object in vars(module)

Again from the docs: """
...however, other objects may have write restrictions on their
__dict__ attributes (for example, classes use a dictproxy to prevent
direct dictionary updates).
"""

>
> What functionality do you think is missing?
>

Well you need to understand locals(), globals(), vars() and __dict__
and their differences to be able to do these things. That's why these
existing functions are not very suitable for the uses I'm describing.
And they certainly don't do anything to help with TypeVar and
sympy.Symbol :-).

-- Koos


-- 
+ Koos Zevenhoven + http://twitter.com/k7hoven +