[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