
Show HN: Adding some syntactic sugar to Python - czheo
https://github.com/czheo/syntax_sugar_python
======
waleedka
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
Related to your first idea, Fortran had statement functions, and it didn't go
very well in the end.

~~~
neuland
What went wrong with them in Fortran?

~~~
greglindahl
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
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
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 (!)

~~~
neuland
Mis-seeing it as an array makes a lot of sense for the f(x) syntax. That's
probably even more true than it would be in a higher level language like
python, because you're doing more stuff like that.

But for Python3 lambda type hints, I'm reading a definitive comment in PEP
3107 that it isn't supported [0]. Anecdotally, that also jives with what I'm
seeing on the REPL.

    
    
        Python 3.6.0 (default, Jan 18 2017, 02:51:38)
        [GCC 4.9.2] on linux
        Type "help", "copyright", "credits" or "license" for more information.
        >>> import typing
        >>> f = lambda x: int: x * 6 
          File "<stdin>", line 1
            f = lambda x: int: x * 6 
                             ^   
        SyntaxError: invalid syntax
    

[0]
[https://www.python.org/dev/peps/pep-3107/#lambda](https://www.python.org/dev/peps/pep-3107/#lambda)

~~~
greglindahl
The docs pointed me to PEP 484 and 526, that's why I mentioned exactly what
I'd looked at. PEP 3107 is not mentioned in
[https://docs.python.org/3/library/typing.html](https://docs.python.org/3/library/typing.html)

Not trying to be pedantic here, just illustrating the point that this style of
function can collide with future language developments, and confuse users.

Here's someone complaining that PEP 484 doesn't mention the impact of the new
syntax on lambda: [https://mail.python.org/pipermail/python-
dev/2015-April/1397...](https://mail.python.org/pipermail/python-
dev/2015-April/139708.html)

------
jessedhillon
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
Yes, it's very anti-pythonic. I collected some ideas and created this lib just
as an experimental toy to demonstrate some possibility.

~~~
greglindahl
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.

------
czheo
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
whoa - good job!

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

------
exDM69
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
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.

------
dfox
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.

------
gregn610
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
That was always an interesting project. Too bad it's not maintained.

------
teilo
It's like the ugly baby of Python and OCaml

