[Python-ideas] Quick idea: defining variables from functions that take the variable name

Stephen J. Turnbull stephen at xemacs.org
Tue May 31 04:56:11 EDT 2016


Paul Moore writes:
 > On 31 May 2016 at 04:08, Steven D'Aprano <steve at pearwood.info> wrote:
 > > How do you feel about an arrow operator?
 > >
 > > T -> TypeVar()
 > > x -> Symbol()
 > > T -> type(bases, ns)
 > > Record -> namedtuple(fields)
 > 
 > I like this.

Well, it's cuter than Hello Kitty, what's not to like?  But ...

It give me no clue what it's supposed to mean.  In math the forward
arrow is often used to name a function type (including the domain
preceding the arrow and the codomain following it in the name),
although what the parentheses and their contents mean, I don't know.
The codomain type is the value of TypeVar()?  What's that?  In Pascal
and R, the reverse arrow

    T <- TypeVar()

is used to mean assignment (which you could read as "T receives
TypeVar()", but the implicit argument on the RHS is a double-take for
me in both syntaxes -- the argument to TypeVar is not optional!

IIRC, we have two syntaxes in Python itself that take the name of an
identifier and reify it as a string (ie, inject it into a namespace):
def and class.  I know you don't think a keyword works for you, but
either the recently reraised "def <name> = <type-expr>" or perhaps
"type <name>: <type-expr>" make more sense to me right out of the box.

Another problem is that none of these syntaxes (including the keyword-
based ones) provides a clue as to whether the type is a distinct type
or a type alias.

It's not that one couldn't learn, but it doesn't seem very Pythonic to
me: not conformant to EIBTI and creating ambiguity that forces the
programmer to guess (or even more painful, read the doc!)

I'm +1 for stopping the bikeshedding until we've all got a lot of
stubfile reading under our belts.



More information about the Python-ideas mailing list