Show HN: Adding some syntactic sugar to Python
github.com
github.com
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/ 3Also, 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.
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.As for type hinting, Python 3 does support it: 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 (!)
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/#lambdaNot 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...
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.
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.
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.