Crazy Python literate programming + DSL idea
Was in the middle of writing a DSL for unit testing a somewhat complex piece of code and then thought of extending Python syntax with (noop) keywords such as just, even, only, but, again etc. This would allow one to write intention-oriented code:
expect_condition(some_param=3, other_param=4)
expect_condition(some_param=now 10, other_param=still 4)
expect_condition(some_param=again 3, other_param=still 4)
but not expect_condition(some_param=20, other_param=20)
and not even expect_condition(some_param=200, other_param=200)…or even some ad-hoc extensible syntax, which would allow to add such literate markers anywhere in the code.
—Should be easy to add to the (CPython or PyPy) parser.
The next level would be to do metaprogramming assertions… i.e. if you have other_param=4 and then other_param=still 5, a custom analyser would be able to detect the flaw; something called an Intention Mismatch Detector!
Could be a potential start to a magic but (arguably) Pythonic alternative to Ruby’s more uncontrolled DSL writing power.
Written by Erik Allik
Related protips
4 Responses
Can you explain how this is pythonic?
The BDFL was pretty clear, explicit is better than implicit. This seems like a lot of magic to me.
Can you explain how adding explicit intention markers to your code makes anything less explicit? Or did you implicitly shut off your brain when you saw the combination of "pythonic" and "enhanced language features", and immediately switched to the "be a good minion and aimlessly quote the BDFL" mode?
P.S. would you care to post a comment that actually discusses something about the ideas in the post and what use cases might have led to these ideas, instead of generically talking about what is Pythonic, how much magic something is and what the BDFL?
Errr ok, that was fairly hostile all things considered.
"Intention makers" and especially this implementation look to me like a massive afterthought. "The actual API wasn't hugely expressive, lets implement a shitton of keywords to clean it up".
Python is moving AWAY from keywords (print) as much as possible, because epic lexer abuse (http://entrian.com/goto/) aside, they are difficult to work around when you need to interact with them (like testing them, amusingly).
My point was mainly that adding more layers of abstraction around what is a totally mutable interface is nearly always a symptom of Doing It Wrong, why not just clean up the original interface and not require the language to implement a ton of keywords to make your test harness work?
Yes, that's a valid point. My hostile response was because your initial response was the same one I'd get from anywhere by anyone.
My main idea was actually for these "keywords" to be noops. You can think of it as super-inlined microcomments. Not sure if your criticism still applies then.
