3 ms·
Those are all valid gripes, but for most use-cases (where performance isn't critical), I haven't found anything better than Python yet. Ruby is an aesthetically
by meowface 8y ago
Those are all valid gripes, but for most use-cases (where performance isn't critical), I haven't found anything better than Python yet. Ruby is an aesthetically nicer language and doesn't have those issues you mentioned in the first paragraph, but the Python ecosystem is amazing and better than Ruby's IMO. And compared to most other languages Python still feels very clean, terse, and pretty to me.
>multi-threading
Most interpreted languages have a GIL, sadly. But yes, this is annoying.
>dependencies management
Annoying, but resolved in part with new projects like pipenv, and also still a big issue for other popular languages.
>deployment
Also helped by pipenv, and Facebook's xar (https://github.com/facebookincubator/xar https://github.com/facebookincubator/xar) is new but looks promising.
>no refactoring/static checking
It's a dynamic language. But this is now possible to some extent with type hints.
>python 2 vs 3
They did screw this up, yeah. Python 3 fixes a ton of issues and is a better language, but the backwards incompatibility created way too many problems.
>50 different kinds of strings
There are 2 kinds: bytes and unicode.
>APIs full of abbreviations which probably meant something to their creators 20 years ago
Can you give some examples? This is an issue in a few of the old standard libraries, but even then it's not too common. This is way, way more prevalent in PHP and C than in Python.
- cm2187 8y ago> There are 2 kinds: bytes and unicode. No I mean single quote, double quote, triple double quotes, r prefix, u prefix, f prefix, combinations, etc > Can you give some examples The one I have in mind is the os library, which I use a lot (like why st_mtime?).
- meowface 8y ago>No I mean single quote, double quote, triple double quotes, r prefix, u prefix, f prefix, combinations, etc These are all extremely helpful, though. All of those quote combinations are equivalent, and can be used to prevent having to escape quotes within the string. The u prefix is gone from Python 3, r is a raw string (which many other languages have, like C#'s @ prefix), and f is a new feature which generated a lot of debate but basically allows interpolation similar to Ruby and ES6. >The one I have in mind is the os library, which I use a lot (like why st_mtime?). That's the one I thought you were going to bring up. I agree the naming conventions in the os module have a lot of warts. The function names could use a refresh.
- eesmith 8y agoYou wrote "These are all extremely helpful". I disagree, in that I think they are only somewhat helpful. If we only had double-quoted strings, and not single-quoted strings, then I think there would be little difference to the language or its quality of use. Going back to the question of "why st_mtime?" - that's because os.stat() is a wrapper around the POSIX stat(2) system call. My FreeBSD man page defines it as: st_mtim Time when file data last modified. Changed by the mkdir(2), mkfifo(2), mknod(2), utimes(2), write(2) and writev(2) sys- tem calls. The Python implementation of stat for MS Windows is basically doing its own emulation layer for POSIX compatibility.