Exploit custom codecs to write inline C in Python
github.com
github.com
By using a custom parser, people are able to add custom syntax in python (which is... undoubtedly unpythonic) with just a decorator(or a magic comment) on front. I can't wait to start abusing this... :-)
Edit: Looks like a pattern matching syntax that hooks in pampy would be my first hacking project :-)
# coding: patmatch
import patmatch
input = [1, 2, 3]
patmatch input:
case [1, 2, x]:
print(f"{x} is matched!") #=> 3 is matched!
def fibonacci(n):
patmatch n:
case 1: return 1
case 2: return 1
case _: return fibonacci(n - 1) + fibonacci(n - 2)Would you have any pointers (heh) given the discovery you made?
As far as parsing goes, if you want to stick with python I've had good success with pyparsing [1], otherwise I have a strong preference to do language-related things in OCaml with menhir [2]. I've toyed with wrapping the Python parser in an OCaml library with decent success [3]. But, of course, unless you're optimizing for fun, it's probably a good idea to stick with Python.
Another, weirder, approach is creating a language that happens to be able to be parsed by the same grammar as python, then using a decorator (or similar) to get the source code or the ast to reparse and transpile. As an example you could have something like `a <- b` be the syntax for an actor model message receive dsl (which is valid python).
[1] https://github.com/pyparsing/pyparsing [2] http://gallium.inria.fr/~fpottier/menhir/ [3] https://github.com/georgek42/pyparser
def parent_function():
output_function_a = lambda x,y: (x + 23) * y
def output_function_b(x, y):
return (x + 23) * y
return output_function_a, output_function_b def parent_function():
def output_function_b(x, y):
return (x + 23) * y
return lambda x,y: (x + 23) * y, output_function_bHissp, my Lisp-on-Python project, uses multiline lambdas to simplify its compilation target to a functional subset of Python: https://github.com/gilch/hissp
Hebigo is a skin built on Hissp with a more Python-like syntax and macros based on Drython. It's what Python would be like if its statements were composable like its expressions are: https://github.com/gilch/hebigo
Even before that, I had a "let" in Drython: https://github.com/gilch/drython/blob/master/drython/stateme...
In Haskell let and lambda have a subtle distinction due to the type system, but in Lisp and dynamically typed languages like Python, "let" can simply be lambda definition that is called immediately.
Though I have missed switch statements a few times in Python, when implementing state machines - for parsing or sensor/actuator logic. Though these tended to be quite simple and not performance-critical, so a if/elif sequence was just fine.
The reason you don't see it in python much is more a matter of culture: we don't like too much magic nor DSL.
With the new generation of coders incomming, it may change though.
Hope not, as most devs are terrible at designing magic or languages and equally terrible at admitting they are.
It took a decade for the trend of monkey patching things in ruby and js to disapear and I don't regret that time one bit. Bad habits die hard.
I bet if either of those two weren't true, you'd see a lot more of it.
It is dominant in data science but still some people use it for other things because the syntax is so simple (Scheme is a close second for me).
Simplicity, as in terms of specifying the grammar though? Python's grammar is exceedingly gnarly by now and I'm pretty sure Go, Lua, Prolog, Smalltalk and pretty much every Wirth language are massively simpler, syntactically.
I completely agree that Python is pretty hard to implement. Perhaps you have heard that simple doesn't mean easy ? I could easily implement a Forth (or assembly) interpreter. But it isn't that easy to understand a big complex Forth program (compared to Python). Simple languages like Forth and assembly are too unstructured for me.
From the top of my head, here's a list of things that were awesome in python's design:
1. Clean and concise syntax (whitespace, slices, rest and kwargs, multiline and raw strings, although both badly designed were ahead of the time)
2. good default builtin datatypes, with decent API (cf garbage like cons cells or STL)
3. in particular strings as immutable vector of bytes, no seperate character type (this got screwed up in python3 of course)
4. comparison on compound datatypes works out of the box
5. relative uniformity no value vs reference type; objects mostly just dicts, modules as well
6. repr and repl (both gimped, compared to lisp, but good enough to be super helpful in development), good tracebacks
7. anti-footgun conventions (notably: mutating functions return None convention; mutable -> no __hash__ convention; slicing copies convention)
Nothing in this list seems particularly hard on the implementor, but it's of course hardly exhaustive or unbiased. What things that you really like about python do you think are rather hard to implement?
I don't know about you but I would rather make hundreds of Scheme and Forth implementations then one Python interpreter. But I don't really see that as a downside. I mean who decides on a language based on how easy it is to implement ?
relies on https://www.python.org/dev/peps/pep-0263/ it seems (this is from 2001, maybe there's more recent)
encoding is a huge problem in py2
Yes...exactly! Good thing that it's dead now, every meaningful library has either been updated or replaced and nobody is using it anymore, right? Like Windows 7! /s
Seriously tho, what's keeping you from updating? Genuinely curious at this point...
My boss doesn't pay the upgrade bills. Only adding new features are billed. Sad.
And there are thousands of real-time users on the system and their task can not be interrupted, also if there is any py2 and py3 mismatch, the outcomes would be quite costy.
It's a cool technique, but quite a lot of effort and can break a bunch of tooling (getting my codec to work with black for example was... fun)
is a framework for creating custom Python syntax with the codec trick.