[Python-ideas] Quick idea: defining variables from functions that take the variable name
cs at zip.com.au
cs at zip.com.au
Tue May 31 20:09:56 EDT 2016
On 31May2016 04:57, Joshua Morton <joshua.morton13 at gmail.com> wrote:
>I like the arrow idea, another option is a syntax more in line with the one
>being discussed for dict unpacking, something like adding a __define__
>dunder that returns a tuple of (name, value). So that say, Typevar's
>__define__ returns the tuple `(self.__name__, self)`. Which is then
>converted into an assignment. The downside of this being that its
>assignment overloading(which can be abused), but at least it can only be
>done when specifically asked for. The other downside is that the syntax
>
>define TypeVar('T') # and I assume we can also declare a list of them
>def ident(t: T) -> T:
> return t
[...]
>The upside is that it avoids the problem of Steven's implementation, since
>the name is decided internally by the callable.
Which to me is a downside. A big downside.
Ignoring "from blah import *", when I write a Python module I have complete
control over the local names:
from os.path import join
from os.path import join as joinpath
x = 3
def y():
All of these are only capable of defining names that I have typed literally
into my code.
If I understand Joshua's suggestion:
define TypeVar('T')
might define _any_ name, because the __define__ dunder can return any name.
Maybe I misunderstand, but otherwise I think this is like a little landmine.
Yes, code can monkey patch. But this feels more insidious.
Why not require the __dunder__ to always return __name__? And then perhaps
support both:
define TypeVar('T')
define TypeVar('T') as Not_T
so that providing the local name (which we're trying to avoid needing to do)
_is_ possible, as the special case as it is with import.
Cheers,
Cameron Simpson <cs at zip.com.au>
More information about the Python-ideas
mailing list