6 ms·

Wait... looking at this, doesn't this mean that by deliberately misusing the `codec` module, meta programming at compile-time (somewhat like Lisp macros) is pos

Wait... looking at this, doesn't this mean that by deliberately misusing the `codec` module, meta programming at compile-time (somewhat like Lisp macros) is possible in Python? 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)

loeg 7y ago
Someone can finally implement multiline lambdas!
- nrclark 7y ago
  You can actually just use a regular function declaration in the middle of arbitrary Python code if you want. Does that count as a multi-line lambda?
  - loeg 7y ago
    No.
    - nrclark 7y ago
      not trying to shitpost - I'm legit curious. What's the difference between the two? Like in this snippet, are the two resulting functions different from each other in some way that I haven't considered? 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
      - loeg 7y ago
        Python lambdas don't have names, and can be defined in expression context (as in, 'map(lambda foo: bar, baz)').
      - tome 7y ago
        The true comparison is def parent_function(): def output_function_b(x, y): return (x + 23) * y return lambda x,y: (x + 23) * y, output_function_b
- gilch 7y ago
  Python DOES have multiline lambdas! It's a common misconception that lambdas have to all be on one line. They don't. What lambda's can't have are statements. Lambdas are restricted to a single expression due to their implicit return statement, but that expression can have any number of line breaks in it. I still shake my head when I hear this complaint about Python, because when coding in the functional style (which is when you need lambdas), expressions are all you need! Haskell and friends don't even have statements, just expressions. My Drython experiment (though unpythonic) demonstrates just how far you can stretch Python's lambdas. Check out its readme for examples: https://github.com/gilch/drython https://github.com/gilch/drython Hissp, my Lisp-on-Python project, uses multiline lambdas to simplify its compilation target to a functional subset of Python: https://github.com/gilch/hissp 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 https://github.com/gilch/hebigo
  - tome 7y ago
    Is there some way of simulating expression-based "let" in Python? Without that lambdas are very weak.
    - gilch 7y ago
      Recall that Python has assignment expressions `:=` now: https://www.python.org/dev/peps/pep-0572/ https://www.python.org/dev/peps/pep-0572/ Even before that, I had a "let" in Drython: https://github.com/gilch/drython/blob/master/drython/statement.py#L810 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.
ssize_t 7y ago
Absolutely :) I "discovered" this when researching implementing a new language on top of python. The decorator is completely unnecessary, so you can have a complete language with custom features built entirely on top of the python interpreter.
- lapnitnelav 7y ago
  I've been toying with the idea of implementing some sort of DSL on top of python but wouldn't really know where to start. Would you have any pointers (heh) given the discovery you made?
  - ssize_t 7y ago
    I think the `#coding:` approach is promising. You have to fit your parsing/transpilation into a pretty small time budget (which is a fun challenge on its own) to keep the startup time hit negligible. The source code gets reparsed serval times in certain cases, e.g. when printing a stack trace, so its a good idea to have some sort of caching mechanism. 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 https://github.com/pyparsing/pyparsing [2] http://gallium.inria.fr/~fpottier/menhir/ http://gallium.inria.fr/~fpottier/menhir/ [3] https://github.com/georgek42/pyparser https://github.com/georgek42/pyparser
    - lapnitnelav 7y ago
      Thanks a mil for the tips.
  - j88439h84 7y ago
blondin 7y ago
i would give anything to have a modern switch statement added to python. the justification for not having one does not hold water anymore. we even have enums in the standard library but nobody uses them -- afaik -- because without a switch statement, enums are not really that useful...
- xapata 7y ago
  Why would switch be useful? The interpreter would still need to evaluate in order like if/elif/else.
  - adrianN 7y ago
    For similar reason why loops are useful even though we could just jump to addresses.
    - xapata 7y ago
      No, those aren't similar reasons. In this case you're just changing the word `elif` to `case`, with no semantic difference.
- jononor 7y ago
  A dispatch dictionary covers many of the typical usecases? https://alysivji.github.io/quick-hit-dictionary-dispatch.html https://alysivji.github.io/quick-hit-dictionary-dispatch.htm... 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.
BiteCode_dev 7y ago
Yes, and you can do it with import hooks as well. 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.
- patrec 7y ago
  Probably not so much a matter of culture, but more that the mechanism is a) garbage b) high effort. I bet if either of those two weren't true, you'd see a lot more of it.
  - VBprogrammer 7y ago
    I think you might be putting the cart before the horse so to speak. The culture of python doesn't value these things so the only mechanism is high effort garbage.
    - patrec 7y ago
      There is truth in that, but also a bit of "he who can't do what he wants must want what he can do". The only reason python still matters (more than ruby) is because of its dominance in ML/datascience. And this ecosystem is full of nasty syntactic hacks.
      - bibyte 7y ago
        I can't speak for other people but the only reason I still use Python is because of it's syntax (but the "one way to do it" is slowly changing). You get much better concurrency with Golang and even better parallelism with Julia. 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).

loeg 7y ago

Someone can finally implement multiline lambdas!

nrclark 7y ago
You can actually just use a regular function declaration in the middle of arbitrary Python code if you want. Does that count as a multi-line lambda?
- loeg 7y ago
  No.
  - nrclark 7y ago
    not trying to shitpost - I'm legit curious. What's the difference between the two? Like in this snippet, are the two resulting functions different from each other in some way that I haven't considered? 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
    - loeg 7y ago
      Python lambdas don't have names, and can be defined in expression context (as in, 'map(lambda foo: bar, baz)').
    - tome 7y ago
      The true comparison is def parent_function(): def output_function_b(x, y): return (x + 23) * y return lambda x,y: (x + 23) * y, output_function_b
gilch 7y ago
Python DOES have multiline lambdas! It's a common misconception that lambdas have to all be on one line. They don't. What lambda's can't have are statements. Lambdas are restricted to a single expression due to their implicit return statement, but that expression can have any number of line breaks in it. I still shake my head when I hear this complaint about Python, because when coding in the functional style (which is when you need lambdas), expressions are all you need! Haskell and friends don't even have statements, just expressions. My Drython experiment (though unpythonic) demonstrates just how far you can stretch Python's lambdas. Check out its readme for examples: https://github.com/gilch/drython https://github.com/gilch/drython Hissp, my Lisp-on-Python project, uses multiline lambdas to simplify its compilation target to a functional subset of Python: https://github.com/gilch/hissp 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 https://github.com/gilch/hebigo
- tome 7y ago
  Is there some way of simulating expression-based "let" in Python? Without that lambdas are very weak.
  - gilch 7y ago
    Recall that Python has assignment expressions `:=` now: https://www.python.org/dev/peps/pep-0572/ https://www.python.org/dev/peps/pep-0572/ Even before that, I had a "let" in Drython: https://github.com/gilch/drython/blob/master/drython/statement.py#L810 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.

ssize_t 7y ago

Absolutely :) I "discovered" this when researching implementing a new language on top of python. The decorator is completely unnecessary, so you can have a complete language with custom features built entirely on top of the python interpreter.

lapnitnelav 7y ago
I've been toying with the idea of implementing some sort of DSL on top of python but wouldn't really know where to start. Would you have any pointers (heh) given the discovery you made?
- ssize_t 7y ago
  I think the `#coding:` approach is promising. You have to fit your parsing/transpilation into a pretty small time budget (which is a fun challenge on its own) to keep the startup time hit negligible. The source code gets reparsed serval times in certain cases, e.g. when printing a stack trace, so its a good idea to have some sort of caching mechanism. 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 https://github.com/pyparsing/pyparsing [2] http://gallium.inria.fr/~fpottier/menhir/ http://gallium.inria.fr/~fpottier/menhir/ [3] https://github.com/georgek42/pyparser https://github.com/georgek42/pyparser
  - lapnitnelav 7y ago
    Thanks a mil for the tips.
- j88439h84 7y ago

blondin 7y ago

i would give anything to have a modern switch statement added to python. the justification for not having one does not hold water anymore. we even have enums in the standard library but nobody uses them -- afaik -- because without a switch statement, enums are not really that useful...

xapata 7y ago
Why would switch be useful? The interpreter would still need to evaluate in order like if/elif/else.
- adrianN 7y ago
  For similar reason why loops are useful even though we could just jump to addresses.
  - xapata 7y ago
    No, those aren't similar reasons. In this case you're just changing the word `elif` to `case`, with no semantic difference.
jononor 7y ago
A dispatch dictionary covers many of the typical usecases? https://alysivji.github.io/quick-hit-dictionary-dispatch.html https://alysivji.github.io/quick-hit-dictionary-dispatch.htm... 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.

BiteCode_dev 7y ago

Yes, and you can do it with import hooks as well. 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.

patrec 7y ago
Probably not so much a matter of culture, but more that the mechanism is a) garbage b) high effort. I bet if either of those two weren't true, you'd see a lot more of it.
- VBprogrammer 7y ago
  I think you might be putting the cart before the horse so to speak. The culture of python doesn't value these things so the only mechanism is high effort garbage.
  - patrec 7y ago
    There is truth in that, but also a bit of "he who can't do what he wants must want what he can do". The only reason python still matters (more than ruby) is because of its dominance in ML/datascience. And this ecosystem is full of nasty syntactic hacks.
    - bibyte 7y ago
      I can't speak for other people but the only reason I still use Python is because of it's syntax (but the "one way to do it" is slowly changing). You get much better concurrency with Golang and even better parallelism with Julia. 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).