>to reduce clutter and expose your intentions. However, there is usual cost. This as any abstraction brings an additional layer of complexity on top of python. And python could be seen as a layer on top of c, and that as one above asm, and that
I took a look at the rest of funcy and it seems a great package, thanks! However, a python dev I'm expected to know how decorators work not how funcy makes decorators work. So unless this was part of the standard lib most devs who already know how decorators work would end up having to read another doc. I dont think its an issue of abstraction (the code is straight forward python: https://github.com/Suor/funcy/blob/master/funcy/decorators.p... ) but rather uniformity. I think coping with the standard library until something like this becomes part of it is the best strategy.
This is a matter of taste. I think certain standard abstractions in Python are pretty terrible, and really need to be upgraded. The standard way of doing function decoration isn't good. Neither is the standard way of accessing mysql. These, and a number of other things, really should have better abstractions built on them to amplify productivity and readability.
Sometimes there's a war between standard techniques and DRY principles. I've observed a lot of good coming from adhering to the idea of never copying code or doing boilerplate. But as you point out, sometimes it can lead to a bunch of nonstandard code. But I think any non-trivial codebase is going to have a chunk of abstractions it creates and builds upon to amplify its own expressiveness. When you can import some of those abstractions, that's arguably a win. There are lots of people that would (and have) disagreed with me on this point, but it is a subjective matter of taste.
That's a good point. A lot of the changes in python start off as alternate packages though, and as package== more popular--> more users --> more features--> included as a part of stdlib (e.g venv). And python's modular structure makes it quite transparent what outside stuff is being used
Usually, standard libraries tend to change only when a better way is demonstrated not just as abstractly doable, but becomes used in practice over what is currently in the standard library, because, otherwise, what's the reason to change what's established?
I took a look at the rest of funcy and it seems a great package, thanks! However, a python dev I'm expected to know how decorators work not how funcy makes decorators work. So unless this was part of the standard lib most devs who already know how decorators work would end up having to read another doc. I dont think its an issue of abstraction (the code is straight forward python: https://github.com/Suor/funcy/blob/master/funcy/decorators.p... ) but rather uniformity. I think coping with the standard library until something like this becomes part of it is the best strategy.