Paul Moore writes:
On 31 May 2016 at 04:08, Steven D'Aprano <steve@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.