The new `@const` will be added as a hook to the PEG parser. if the PEG parser finds a `@const`, it will invoke the miniparser of `mykeywords` module inherent to `@const`. In this case, it will simply transform `@const a = 1` in `const PyObject* a = PyLong_FromSsize_t((Py_ssize_t) 1)`

Now that is a simple reason why your proposal, while cool and all, is not realistic :

Python just doesn't work that way. Your python source code, when interpreted, is *never* turned back to pure C, so you just can't make a keyword translating to C (or Java, or whatever) stuff.

The point is, Python's interpreter needs to know every token that can possibly be passed to him (that's not a problem, thanks to the "@", it can recognize custom keywords) *and* know what to do out of it — and all that at the time you compile the Python interpreter. That makes it really hard to add keywords outside the regular Python development cycle, if even possible. You'd need to make a C API for keywords developers, and modify most of the parser to use and allow the use of such and API. Then developing the keyword would need crafting a bit of parser — in C. I can tell you, parsers can get really complicated, especially at the scale of Python, so I don't think many would have the associated knowledge required to do it. In fact, you never propose a keyword alone: you propose a syntax to use it. (think of `as` : `from math import sqrt as root` vs `with open("filename") as file` vs `try...except Exception as e`). How do you tell what happens when the keyword opens a code block, for example ?

TL;DR : it would need rewriting Python from scratch, for a feature too complex to be widely used.

If you want custom keywords, you can look at ANTLR, or flex/bison, that's what they're for ! (They're generic parsers, allowing you to craft an interpreter for any language you might like.) You will see that these tools, while dead useful, are much too broad for Python.

Now on to use cases : I can see two broad use cases to this tool.

The first one is including alien (C-, Java-) features in Python. To see why it wouldn't be possible, read above + This is Python we're talking about, if you need some Java-specific features, code in Java !

The second one is replacing a macro, or a function call (I believe it's the same in Python ^^). It's been discussed here already, especially with the case of `print` : `print "foo"` vs `print "foo"`. It could be generalized to any function call... If you want to support that proposal, I'll let you look in the thread archive for the times it was discussed already, and then — why not ? That's easier to implement, as it's just translating to a function call, we wouldn't even need the special "@", and it may add to readability.

Regards,

Alexis