6 ms·

Show HN: Adding some syntactic sugar to Python

77 points by czheo 10y ago

jessedhillon 10y ago
This is a cool demonstration of how make some fundamental changes to Python by using operator overloading, but it feels fragile and very different from Python. At the end of the day, I'd think that if you want to program like this, you want a different language.
- czheo 10y ago
  Yes, it's very anti-pythonic. I collected some ideas and created this lib just as an experimental toy to demonstrate some possibility.
  - greglindahl 10y ago
    Leaves me wondering if I'd be shooting off my little toe or my whole foot! Might be fun to show pythonic equivalents for the ones that are relatively easy to make pythonic. You might discover some useful pythonic functions along the way.
waleedka 10y ago
The nice thing about Python is that it's intuitive and feels natural. To that end, this syntax for defining functions is nice, and I would love to see it implemented in native Python: f(x) = x^2 + 1 But most of the other ideas are less intuitive than their native counterparts. For example, I think that the native form: 3 in [1,2,3,4,5] is clearer than: [1,2,3,4,5] /contains/ 3
- greglindahl 10y ago
  Related to your first idea, Fortran had statement functions, and it didn't go very well in the end.
  - neuland 10y ago
    What went wrong with them in Fortran?
    - greglindahl 10y ago
      With the usual method of declaring a function, it was easy to understand that 'x' was local to the function. Adding a second, more concise way to express functions led to confusion about the scope of 'x'. Also, declaring types for the function and arguments (which is optional but has been strongly recommended since the Fortran '77 era) had to be done outside of the function, which again is unlike the usual syntax. The only code I've ever seen statement functions used in dated from the 1970s.
      - neuland 10y ago
        Interesting. It's clear to me. It looks a lot people who had some confusion with the scope of x in something like ... f(x) = x^2 + 1 would also have problems quickly seeing the scope of x in lambdas that are present in a bunch of modern programing languages like python. f = lambda x: x^2 + 1 It seems python lambdas also don't support type hinting like you mention was a problem in Fortran, too.
        greglindahl 10y ago
        I think the Fortran problem was that f(x) = x^2 + 1 looks a lot like a normal statement, with only a subtle clue on the left hand side ("Hey, f isn't an array!...") Whereas in python, having 'lambda' is a bigger clue. Hard to know without trying it out on some test subjects. I don't think anyone really studied why the Fortran thing was a problem, but of course lots of people (including me) have guesses. As for type hinting, Python 3 does support it: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html but I think the better lesson to learn is that it can be hard to future-proof alternative syntax or syntactic sugar. I looked at the 3.X docs, and PEP 484 and 526, no mention of how this typing can work with lambdas, and no comment that it doesn't (!)
- msravi 10y ago
  Julia has this kind of syntax (among others) for functions.
deleted 10y ago
[deleted]
gigatexal 10y ago
I like the threading / processes abstractions. I'll be watching this over time. Kudos.
czheo 10y ago
I feel so honored that this project was tweeted by Matz himself. https://twitter.com/yukihiro_matz/status/823386626424328192 https://twitter.com/yukihiro_matz/status/823386626424328192
- yomly 10y ago
  whoa - good job!
exDM69 10y ago
The naming is odd, because the syntax hasn't changed, only the semantics of some operators have changed. An example of syntactic sugar is list comprehensions. It's a new syntax for expressions using map, filter, etc. It's "new" syntax for something that can be described in terms of the "old" syntax without altering the semantics. Given the name, I was expecting some kind of macro system or hacks to the Python parser.
- czheo 10y ago
  Yes, I agree with you. Strictly speaking, I was creating new semantics of the operators which looks like "new" syntax, to mimic "syntactic sugar". But I have no idea how to name this in a more understandable way.
gregn610 10y ago
Sounds kinda like Pyp http://opensource.imageworks.com/?p=pyp http://opensource.imageworks.com/?p=pyp which I've been meaning to get more into, to replace shell foo.
- kbd 10y ago
  That was always an interesting project. Too bad it's not maintained.
dfox 10y ago
On a similar note I wrote this over few days last week: https://github.com/adh/py-clos https://github.com/adh/py-clos What it severely lacks is readme that clearly states what it does with some realistic examples and is understandable by people who have no idea what CLOS is, so: It allows you to do function overloading which is resolved dynamically based on actual types of passed values or even values themselves. With the included (trivial) C extension it's only about 50% slower than Python method call, so in all for expected usecase it's faster than Visitor pattern not to mention more DRY.
teilo 10y ago
It's like the ugly baby of Python and OCaml

77 points by czheo 10y ago

This is a cool demonstration of how make some fundamental changes to Python by using operator overloading, but it feels fragile and very different from Python. At the end of the day, I'd think that if you want to program like this, you want a different language.

czheo 10y ago
Yes, it's very anti-pythonic. I collected some ideas and created this lib just as an experimental toy to demonstrate some possibility.
- greglindahl 10y ago
  Leaves me wondering if I'd be shooting off my little toe or my whole foot! Might be fun to show pythonic equivalents for the ones that are relatively easy to make pythonic. You might discover some useful pythonic functions along the way.

waleedka 10y ago

The nice thing about Python is that it's intuitive and feels natural. To that end, this syntax for defining functions is nice, and I would love to see it implemented in native Python: f(x) = x^2 + 1 But most of the other ideas are less intuitive than their native counterparts. For example, I think that the native form: 3 in [1,2,3,4,5] is clearer than: [1,2,3,4,5] /contains/ 3

greglindahl 10y ago
Related to your first idea, Fortran had statement functions, and it didn't go very well in the end.
- neuland 10y ago
  What went wrong with them in Fortran?
  - greglindahl 10y ago
    With the usual method of declaring a function, it was easy to understand that 'x' was local to the function. Adding a second, more concise way to express functions led to confusion about the scope of 'x'. Also, declaring types for the function and arguments (which is optional but has been strongly recommended since the Fortran '77 era) had to be done outside of the function, which again is unlike the usual syntax. The only code I've ever seen statement functions used in dated from the 1970s.
    - neuland 10y ago
      Interesting. It's clear to me. It looks a lot people who had some confusion with the scope of x in something like ... f(x) = x^2 + 1 would also have problems quickly seeing the scope of x in lambdas that are present in a bunch of modern programing languages like python. f = lambda x: x^2 + 1 It seems python lambdas also don't support type hinting like you mention was a problem in Fortran, too.
      - greglindahl 10y ago
        I think the Fortran problem was that f(x) = x^2 + 1 looks a lot like a normal statement, with only a subtle clue on the left hand side ("Hey, f isn't an array!...") Whereas in python, having 'lambda' is a bigger clue. Hard to know without trying it out on some test subjects. I don't think anyone really studied why the Fortran thing was a problem, but of course lots of people (including me) have guesses. As for type hinting, Python 3 does support it: https://docs.python.org/3/library/typing.html https://docs.python.org/3/library/typing.html but I think the better lesson to learn is that it can be hard to future-proof alternative syntax or syntactic sugar. I looked at the 3.X docs, and PEP 484 and 526, no mention of how this typing can work with lambdas, and no comment that it doesn't (!)
msravi 10y ago
Julia has this kind of syntax (among others) for functions.

deleted 10y ago

[deleted]

gigatexal 10y ago

I like the threading / processes abstractions. I'll be watching this over time. Kudos.

czheo 10y ago

I feel so honored that this project was tweeted by Matz himself. https://twitter.com/yukihiro_matz/status/823386626424328192 https://twitter.com/yukihiro_matz/status/823386626424328192

yomly 10y ago
whoa - good job!

exDM69 10y ago

The naming is odd, because the syntax hasn't changed, only the semantics of some operators have changed. An example of syntactic sugar is list comprehensions. It's a new syntax for expressions using map, filter, etc. It's "new" syntax for something that can be described in terms of the "old" syntax without altering the semantics. Given the name, I was expecting some kind of macro system or hacks to the Python parser.

czheo 10y ago
Yes, I agree with you. Strictly speaking, I was creating new semantics of the operators which looks like "new" syntax, to mimic "syntactic sugar". But I have no idea how to name this in a more understandable way.

gregn610 10y ago

Sounds kinda like Pyp http://opensource.imageworks.com/?p=pyp http://opensource.imageworks.com/?p=pyp which I've been meaning to get more into, to replace shell foo.

kbd 10y ago
That was always an interesting project. Too bad it's not maintained.

dfox 10y ago

On a similar note I wrote this over few days last week: https://github.com/adh/py-clos https://github.com/adh/py-clos What it severely lacks is readme that clearly states what it does with some realistic examples and is understandable by people who have no idea what CLOS is, so: It allows you to do function overloading which is resolved dynamically based on actual types of passed values or even values themselves. With the included (trivial) C extension it's only about 50% slower than Python method call, so in all for expected usecase it's faster than Visitor pattern not to mention more DRY.

teilo 10y ago

It's like the ugly baby of Python and OCaml