If you are proposing to add "<-" and "->" to the fundamental Python grammar, then it could work as PEP465 does. But if you are proposing that classes can define new lexical operators, it would have to work very very differently. You started with "operators as first class citizens," but I don't know what you mean by that.

It is my bad to mix this two topics together ... I am not strongly proposing for now to have python to support arbitrary operator definitions, I can live with the arrow propose if it makes sense. I see also even the term "first class citizen" makes a confusion here ... by which python do have certain extent of support for the existing operators. What I should have emphasized more is the dynamic nature of creating new operators. Which scala seems does a better job in this area for now.

When Python compiles a file, it does not read the imported files at all. That doesn't happen until run time. So how will Python know what "<-" means in circuit.py? It's never seen this token before, so it can't know what special method it should map onto. It can't even know what the token is. What if it encounters "x ~++<-+ y"? What are the tokens in that source?

I see your point now. Scala does this by simply looking up a method on the object named as "<-" e.g. x <- y is equivalent to "x.<-(y)". If "x ~++<-+ y" is encountered scala will interpret it to "x.~++<-+(y)" most likely (haven't tried), they had also a precedence rule regarding user defined operators. So if we want to change python to support arbitrary operators, the operator itself probably need to be loaded by a VM instruction, and then finding that operator on the object being operated. This sounds like a lot of overhead with probably even a string comparison needed? I think in the short term this is going to be difficult to justify and I have not looked into the performance implications. But anyway in this case the importing seems not necessary, as the operator should have *NOT* being implemented in hdl.py, but is part of the object used in circuit.py.