Multiple dispatch is also a great thing as well. You don’t realize you need it until you try implementing something unification algorithm.
Compose is nice for reducing the mental overhead of reading nested expressions. However, I do wish they took a line from lodash and implemented flow instead (like compose but reversed so the first argument is invoked first, then the output of that is fed into the second, and so on).
Syntactic sugar is not bad if it increases signal to noise when reading code or if it prevents erroneous usage.
It is not equivalent to PrePostMetaInit.
- https://toolz.readthedocs.io/en/latest/api.html#toolz.functo...
- https://toolz.readthedocs.io/en/latest/api.html#toolz.functo...
There’s a lot of value in deeply learning the internals of a language so you can write good code in the target language rather than developing some mashup of “features”.
Ironically the article begins with be premise of deeply learning python but never touches on the advanced features that were learned and applied to develop the library.
Sorry for the confusion. :)
Indeed, even though I learned a ton about python, I didn't feel like what I had to say made for an interesting blog article, and was a bit abstract. I was equally excited about the library from and end user's perspective and decided to blog about that instead.
Generally I prefer to use vanilla python as much as possible, but I think there is value in having libraries like this, which make things clearer and have less boilerplate without much cost. Most of what I see would be pretty easy to replace with regular python if you decided to move away from the library, there aren't lots of wierd layers being added to your code.
There are some good ideas in there though, like @dispatch which have potential to improve type checking.
I don't think this needs to be an either/or choice in these situations. You can have both if you make the make the conscious decision to not fight your tools. Yes, sometimes you have to be more verbose in one language than another, but the productivity hit in that case always pales in comparison to the hours, days, and in some cases I've seen, weeks, lost by someone fighting their language/tools.
My favorite example of this was a developer given a 2 week feature implementation that ballooned to two months. They had minimal experience C++, and they didn't like its looping syntax. Rather than accept that frustration and write the code in a syntax they disliked, they instead spent weeks writing a "re-usable library that abstracts away looping semantics".
But yea, not while you're trying to ship.
I wonder what the vision of Python's steering committee is.