4 ms·

One of my biggest gripe is how python have a hidden non-declared agenda to have syntax as far from C as possible. its really not giving language any usage bene

One of my biggest gripe is how python have a hidden non-declared agenda to have syntax as far from C as possible. its really not giving language any usage benefits when you cannot use ternary expressions, ! as not, !=, increment operators. Also, PEP8 is very very presriptive, you are disallowed to do violate any rule, even when if you need to to make the code better. (I feel shunned by the community for not liking 80 chars line hard breaks) Python3 migration was not planned well - the lack of back and forward compatibility gave users a legit reason to stay with python 2 forever. I've seen some conference talks where end users/projects being shamed for not jumping on python3. GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware. This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library. Of course, all this does not mean python is not good. Builtin pip/venv, adrequate unicode in python3, some of fantastic libraries(numpy/scipy, bokeh) making it indispensable.

acdha 8y ago
> GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware. It's also a huge source of misattributed problems — I've seen more cases where a complaint about the GIL was really “my algorithm depended on a single locked data structure” or “I was calling a C library which isn't thread-safe” than where the GIL was actually the limiting factor. That's not to say that there aren't real problems for people who want to run pure-Python computational code (not e.g. libraries like Numpy or Pillow) but it also seems to be popular as the bogeyman to blame when someone doesn't want to run a profiler. > This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library. See https://docs.python.org/3/library/itertools.html https://docs.python.org/3/library/itertools.html and https://docs.python.org/3/library/random.html https://docs.python.org/3/library/random.html for the sample function. I believe the difference is mostly that the Ruby methods are on Array but the Python ones are seen as processors for iterables so they're in a separate part of the standard library.
Havoc 8y ago
IIt limits the ability of python to reap the benefits of better hardware GIL sucks conceptually but I don't think it's massively limiting in terms of future hardware. E. G. I just discovered you can throw a bit of python into colab and do ML on Google provided K80 GPUs for free. Two completely different things I know but to me that is a better indication of future proofness in a way.

acdha 8y ago

> GIL in python is something that was talked about 5 years ago and will still be talked in 5 years. It limits the ability of python to reap the benefits of better hardware. It's also a huge source of misattributed problems — I've seen more cases where a complaint about the GIL was really “my algorithm depended on a single locked data structure” or “I was calling a C library which isn't thread-safe” than where the GIL was actually the limiting factor. That's not to say that there aren't real problems for people who want to run pure-Python computational code (not e.g. libraries like Numpy or Pillow) but it also seems to be popular as the bogeyman to blame when someone doesn't want to run a profiler. > This may be minor, but I really missing ruby rich set of collection methods: take_while, group_by, sample. Yet I can see a point in extracting that to a external library. See https://docs.python.org/3/library/itertools.html https://docs.python.org/3/library/itertools.html and https://docs.python.org/3/library/random.html https://docs.python.org/3/library/random.html for the sample function. I believe the difference is mostly that the Ruby methods are on Array but the Python ones are seen as processors for iterables so they're in a separate part of the standard library.

Havoc 8y ago

IIt limits the ability of python to reap the benefits of better hardware GIL sucks conceptually but I don't think it's massively limiting in terms of future hardware. E. G. I just discovered you can throw a bit of python into colab and do ML on Google provided K80 GPUs for free. Two completely different things I know but to me that is a better indication of future proofness in a way.