12 ms·

Drawbacks of Python

97 points by iflywithbook 7y ago

mikece 7y ago
"No language is perfect" is the perfect reply to asking about the drawbacks. The ability to get things done in a language is what allows someone to deliver VALUE to a client (or for their own projects). A workable solution now trumps a perfect solution that will take too long to implement.
- collyw 7y ago
  JavaScript is a pretty bad language in my opinion, but does have the universal deployment problem solved a lot better than any other.
  - noobiemcfoob 7y ago
    JavaScript is the perfect example of give hackers a bit and they'll take a damned terabyte.
    - SketchySeaBeast 7y ago
      JavaScript is like Buckley's cold medicine - It's awful, but it works.
      - neural_thing 7y ago
        Unrelated to this comment, based on your earlier comment - check this out: http://www.classicshell.net/ http://www.classicshell.net/ This transforms the start menu on Windows into any version of it you like.
metalliqaz 7y ago
From the article: > Strings were just a sequence of bytes in Python 2, but now are Unicode by default. Much better. whelp, not trusting this guy's judgement anymore
- SketchySeaBeast 7y ago
  While the sentence is a bit weird, along the lines of "That word is made up." "All words are made up." strings ARE potentially harder to deal with in 2 than 3.
  - metalliqaz 7y ago
    in my experience, most people want bytestrings most of the time, and the main effect of changing the str type has been to drive a lot of traffic to SO when they have encoding errors trying to deal with strings that used to "just work" in 2.7
    - beagle3 7y ago
      The thing about "just works" in 2.7 is that it does ... until it doesn't, and when it doesn't, it's often way harder to resolve. If you're only using the original ASCII (ordinals 0-127), all is well, and the py3 distinction between strings and bytes seems to get in the way. But as soon as you have a single character in your input or data which is not ASCII, a lot of things stop working and it isn't even clear why, or how to fix it -- often, the error comes from a library-within-a-library-within-a-library, which did some manipulation that (wrongly) assumed some encoding or its properties.
      - metalliqaz 7y ago
        Maybe you're right. Maybe there are applications where this really matters. All I can say is that I have never once had that problem since I started using Python (circa version 2.4). It has always been fine. For example, when dealing with .csv files created with MS Excel, you get strange characters because Excel uses CP1252 encoding, not ASCII. They never tripped up my app in python 2.7. It happily passed them along. Even regular expressions worked. Python3 died repeatedly until I went through and forced everything to be bytestrings.
        SketchySeaBeast 7y ago
roland35 7y ago
I agree with the response that there are a few "gotchas" with python, like with any language! I have gotten caught up with a few type problems when dealing with sending raw binary data over serial and things like that - but luckily python has great unit testing frameworks to help with this. My main beef with python is that it is harder to deploy projects to other people, without them setting up a virtual environment or things like that. I know that there are some tools to help compile but they aren't easy to use. Also, it is hard to create GUI applications vs languages like C#! Other than that I love using python and I think it is a great tool to use in embedded development along with c/c++.
- metalliqaz 7y ago
  I also run up against the deploying problem quite a bit. For the most part, only Windows has been a real issue for me. Lately I've use Cython and found that adds an even tougher layer of difficulty to the problem.
- WilliamEdward 7y ago
  All true, but I don't think python's really supposed to be perfect for making desktop apps, its lack of static typing means a large scale app would end up becoming a pain to maintain. That's why it is best used in small teams for data science and scripting; run once and never look back. Most complaints about python IMO fail to appreciate its design philosophy.
  - jofer 7y ago
    Just my $0.02: I've maintained and/or written more than a few large desktop apps in both python and C++. The python ones are a hell of a lot easier to maintain, i.m.o. Python _is_ strongly typed unlike JS, and I don't feel like the dynamic typing aspects have ever really bit me from a maintenance perspective. At least in my experience, I've seen a lot of either verbose/repetitive or highly cryptic C++ written to in situations that dynamic typing makes straightforward and i.m.o easier to maintain. To be fair, though, I have a pretty accurate mental model of what python's doing under the hood, and I still regularly find myself mystified by certain C++ language features and what the compiler actually does in slightly ambiguous situations. I've nominally been using C++ longer, but I've used python a lot more frequently. (I'm primarily in scientific computing.) As a whole, I've always found python to be a nice language from a maintenance perspective, though I'll grant that people have more room to do bizarre things in some circumstances. I've definitely seen some unmaintainable and unreadable python, but I've seen that every bit as frequently in static-typed languages. I feel that python is quite well-suited to desktop application development. Part of this boils down to Qt being a nice library regardless of whether you're working in C++ or python. However, python codebases tend to be more succinct and readable. In the end, I've consistently found that to be a larger advantage in maintenance than static typing.
PythonicAlpha 7y ago
I actually expected some elaborate work about the imperfection of Python. What I got was a list that started with at least three points that are already obsolete, because only valid for Python 2, which is already declared obsolete. Every language with some history has its humble start and is evolving. To carry the errors of the past is just not fair. You could of course drag along the first Java version and conclude that Java is bad -- but you would really invalidate your own opinion.
psv1 7y ago
So this just links to someone's opinion on Python 2 vs 3 instead of an actual discussion on the drawbacks of Python, right?
- misterdoubt 7y ago
  To be fair, it also highlights a benefit of Python 2.2 over 2.1. (I.e., improvements made in the language eighteen years ago.)
rjmunro 7y ago
The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.
- beagle3 7y ago
  conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).
  - fitech 7y ago
    how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?
    - athorax 7y ago
      With your conda environment activated, you can run pip install requirements.txt. You don't have to use any of the conda commands outside of creating the environment.
  - athorax 7y ago
    conda / miniconda has definitely solved most of my grievances with deploying python applications
  - physicsguy 7y ago
    If you want to add your own project to Conda, you need to use conda forge, because Anaconda itself is a curated distribution. Maintaining a conda forge package has been, for us, a complete nightmare. If you depend on another conda-forge package you can have the issue that the library is configured to suit whoever first wrote the conda-forge package - i.e. by disabling parallelism or providing only shared/static libraries, and have that maintainer be completely unresponsive or unwilling to change it.
canada_dry 7y ago
Quora click bait. A dull and benighted article that adds nothing to the discussion.
dragonsh 7y ago
I like Python because of zen of python [1]. This fits my brain and had been very helpful. Indeed in 2004 I chose Django instead of Ruby On Rails just because explicit is better than implicit. Overall Python is productive and good. Yes it has some warts and corner case, but than its evident. Among programming language python has a humble community and very approachable. Also most programmer in Python will not hesitate to use low level language and interface with Python when necessary. It's not considered bad. >>>import this "Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!" [1] https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/
- smt88 7y ago
  I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.
  - dragonsh 7y ago
    May be different people have different experience with Python. After c and Perl had been using it for over 15 years and among the languages I have seen Python code is one of the most readable one so far, again subjective as I like sparse and empty spaces in architecture with minimalist design. For me whitespace is same in Python code. Whitespaces forces programmer to make code readable. Obviously today with tools like gofmt, rustfmt it seems easy and those are inspired by Python. Python PEP process has been adopted by many programming language. Try JCP process and see what I am talking about.
skrause 7y ago
I have to deploy web applications written in Python on Windows... no uWSGI, no Gunicorn and no easy multiprocessing because no fork(). It's painful quite often and it makes me loathe the GIL, but I still enjoy writing Python code.
- kerkeslager 7y ago
  I'm curious what what your approach to this is. Relying heavily on Twisted seems to be the obvious choice?
brbrodude 7y ago
Dunno if Ruby locked my mind into a certain mode, but I've never felt good doing anything with python :( 2 different projects I tried participating with a lot of years in between, still felt the same. Granted, I can't say I've really studied it properly.
m4r35n357 7y ago
Python is the simplest language I know of that does operator oveloading. If I had to write my pet maths project in c++ I would not even have got started. Sometimes abstract "drawbacks" are irrelevant!
kyllo 7y ago
These are minor annoyances to me. The major annoyance I have with Python is that most Python code makes such heavy use of classes, even when it only needs lists, tuples, and dicts. Why do I really need a class, when: - Instance fields can be added and removed at runtime - Private fields and methods are not actually private ("we're all consenting adults here") - No pattern matching on types and `if isinstance(foo, Bar):` is an anti-pattern because it's a duck-typed language - Interfaces are neither available nor necessary due to late binding. Abstract Base Classes are the closest thing to an interface, but they're also unnecessary because again, it's duck-typed. - Inheritance is widely considered to be a mistake ("Prefer composition over inheritance" etc) - Classes tend to complicate testing I can use classes to write custom data structures, I guess, but in a language as high-level as Python, I can just model trees and graphs with dicts. If I need a more performant data structure, I'm not writing it in Python in the first place. I've seen some very experienced Pythonistas recommend using namedtuple instead of classes for most use cases, and I tend to agree with them. That gets you immutability as well as dot notation for accessing fields. Clojure programmers seem perfectly happy with just lists and maps, and after experiencing that, classes feel like a bolted-on misfeature in Python.
- Scarblac 7y ago
  You can even subclass namedtuples to get immutable value objects with helpful methods. I like classes over dictionaries because I can look at the class definition to see what the variables my function gets are, and what functions (methods) exist to work with them. I used to work with a code base that passed dictionaries around, and there were a lot of hacks where people had some data somewhere that they needed somewhere else, and the dict was available both places, so why not add it to that... Different pieces of code added different things and you were never quite sure which version of the data was passed this time for the "layers" parameter. Somehow it doesn't happen as much with classes. It was like duck typing to the extreme. I call it smurf typing, if it smurfs like a smurf, smurfs like a smurf and smurfs like a smurf, nobody knows what's going on anymore. Immutable value classes, those are good.
- j88439h84 7y ago
  My solution to this is http://attrs.org http://attrs.org or dataclasses. They make a huge difference in readability and type safety.
kerkeslager 7y ago
Almost every discussion of programming languages falls into bike-shedding[1] and this is no exception. The only thing he mentions worth talking about is the GIL. Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. If whitespace and using the division operator are big problems for you, significant software development probably isn't within your abilities. In addition to the GIL, other problems I'd point out with Python: 1. At one point, Python was "batteries included". This is largely no longer the case any more--most projects are largely dependent on PyPI, and there's been a growing sentiment in the last few years that "the standard library is where modules go to die". PyPI libraries are of inconsistent quality and have a high turnover rate; the "standard" for what to use changes fairly rapidly. And if you manage to make good choices of mature libraries and not have to change them every year or so, you still have to manage dependencies, which complicates deployments. 2. Fracturing community: there are now a bunch of different non-standard ways to install Python and Python dependencies, which conflict with each other, and none of which fit all use cases, so you have to use all of them and deal with conflicts. This exacerbates issues with 1. 3. Increasing dependency on non-pure-Python dependencies which don't build trivially. There are reasons for this: Python often isn't performant enough for certain tasks, and other languages have some very good tools. However, this means you can't just `pip install` a library and expect it to work--even very common libraries like Pillow don't without fiddling. Again, this exacerbates problems with 1. 4. Lack of a good desktop UI framework. It's apparent that not as many people are using Python for native UIs any more. tk is cludgy and doesn't result in pretty UIs, and despite being part of the standard library, it doesn't work out of the box on MacOS. wxWidgets doesn't build on MacOS without significant work, and documentation is for the C++ version of the library. This is sort of the intersection of 1, 2, and 3, but in desktop UIs they combine to form a perfect storm. If you're developing a desktop UI, there are better languages, but I'm not going to post them here because I'd rather keep this as a constructive criticism of Python than a language competition. 5. Introspection being used to change language syntax without solving the problems the language syntax solves. I'm really looking at Django here, but they're not the only guilty ones. When you call a function, i.e. route_on_http_method(GET=get_handler, POST=post_handler), functions can fairly easily check arguments and throw an exception from a logical spot--i.e. route_on_http_method(GIT=get_handler) throws an exception immediately. But when you have `class MyView(GenericView): def git(self, request): ...` you get no exception until you try to call the view, in which case you get a wonderful cornucopia of meaningless line numbers in a useless stack trace. Sure, Django code looks nicer and more organized, but as I said, syntax isn't that important. Debugging IS important. Using the bikeshedding example, this is breaking the nuclear power plant to fix a problem with the bike shed. And this is a generous example: it's fairly simple and Django is one of the libraries that does a better job of this. If you really want configuration-oriented programming, you'd be better off parsing in JSON files and doing explicit error checking when you parse them in, rather than introspecting out a syntax that's not really code and not really configuration. Introspection hasn't played out well as a Python feature. You'll note that all these problems are CULTURAL problems, rather than problems with the language itself. And that's my point, because those are the problems you can't easily work around, and it's the problems you can't easily work around that make or break the language. I say all this because I love Python. I've worked in Python for the last 6ish years, and don't see that changing any time soon. [1] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding
zeveb 7y ago
Back when I wrote a lot of Python, something I disliked was how one could easily reload a module, but existing instances of classes wouldn't get updated. You could implement the machinery to do so for your own stuff, but of course that could be arbitrarily flaky. Performance was definitely an issue, but for the sort of programming we were doing it normally wasn't a big issue. Duck typing could definitely be an issue — one had little confidence that code would run as desired. Overall, I really liked Python, but these days I'd sooner use Go or Lisp.
abakus 7y ago
Simple is better than complex. There should be one-- and preferably only one --obvious way to do it. https://xkcd.com/1987/ https://xkcd.com/1987/
- yen223 7y ago
  Also, here are 4 different ways to do string formatting
makz 7y ago
I love python and it is my main language for almost everything. However, yesterday I was playing with python’s async/await and I came to the conclusion that it is a bit... useless. Not a big deal, because i can use other stuff to accomplish the same I was trying to do. Or maybe I was doing it wrong.
anm89 7y ago
Maybe I'm naive, but in my mind besides their ecosystems and superficial syntax differences there isn't that much functionally different between Python and Ruby, with the major to exception of blocks in Ruby. In which case the decision between the two seems to be between a thing and a slightly better version of itself. I totally respect that many people see this differently and probably exactly opposite but to me it always feels really hard to justify using python for this reason. Just for fairness sake I'm not trying to trash python. I think it's a great language.
partizanos 7y ago
Sorry but it just seemed odd I didn't see a mention for GIL (global interpreter lock). Because of this mechanism that ensures concurrency safety Python does not support parallel execution of threads. I am wondering if the rest of the HN community finds it as a major disadvantage.

97 points by iflywithbook 7y ago

"No language is perfect" is the perfect reply to asking about the drawbacks. The ability to get things done in a language is what allows someone to deliver VALUE to a client (or for their own projects). A workable solution now trumps a perfect solution that will take too long to implement.

collyw 7y ago
JavaScript is a pretty bad language in my opinion, but does have the universal deployment problem solved a lot better than any other.
- noobiemcfoob 7y ago
  JavaScript is the perfect example of give hackers a bit and they'll take a damned terabyte.
  - SketchySeaBeast 7y ago
    JavaScript is like Buckley's cold medicine - It's awful, but it works.
    - neural_thing 7y ago
      Unrelated to this comment, based on your earlier comment - check this out: http://www.classicshell.net/ http://www.classicshell.net/ This transforms the start menu on Windows into any version of it you like.

metalliqaz 7y ago

From the article: > Strings were just a sequence of bytes in Python 2, but now are Unicode by default. Much better. whelp, not trusting this guy's judgement anymore

SketchySeaBeast 7y ago
While the sentence is a bit weird, along the lines of "That word is made up." "All words are made up." strings ARE potentially harder to deal with in 2 than 3.
- metalliqaz 7y ago
  in my experience, most people want bytestrings most of the time, and the main effect of changing the str type has been to drive a lot of traffic to SO when they have encoding errors trying to deal with strings that used to "just work" in 2.7
  - beagle3 7y ago
    The thing about "just works" in 2.7 is that it does ... until it doesn't, and when it doesn't, it's often way harder to resolve. If you're only using the original ASCII (ordinals 0-127), all is well, and the py3 distinction between strings and bytes seems to get in the way. But as soon as you have a single character in your input or data which is not ASCII, a lot of things stop working and it isn't even clear why, or how to fix it -- often, the error comes from a library-within-a-library-within-a-library, which did some manipulation that (wrongly) assumed some encoding or its properties.
    - metalliqaz 7y ago
      Maybe you're right. Maybe there are applications where this really matters. All I can say is that I have never once had that problem since I started using Python (circa version 2.4). It has always been fine. For example, when dealing with .csv files created with MS Excel, you get strange characters because Excel uses CP1252 encoding, not ASCII. They never tripped up my app in python 2.7. It happily passed them along. Even regular expressions worked. Python3 died repeatedly until I went through and forced everything to be bytestrings.
      - SketchySeaBeast 7y ago

roland35 7y ago

I agree with the response that there are a few "gotchas" with python, like with any language! I have gotten caught up with a few type problems when dealing with sending raw binary data over serial and things like that - but luckily python has great unit testing frameworks to help with this. My main beef with python is that it is harder to deploy projects to other people, without them setting up a virtual environment or things like that. I know that there are some tools to help compile but they aren't easy to use. Also, it is hard to create GUI applications vs languages like C#! Other than that I love using python and I think it is a great tool to use in embedded development along with c/c++.

metalliqaz 7y ago
I also run up against the deploying problem quite a bit. For the most part, only Windows has been a real issue for me. Lately I've use Cython and found that adds an even tougher layer of difficulty to the problem.
WilliamEdward 7y ago
All true, but I don't think python's really supposed to be perfect for making desktop apps, its lack of static typing means a large scale app would end up becoming a pain to maintain. That's why it is best used in small teams for data science and scripting; run once and never look back. Most complaints about python IMO fail to appreciate its design philosophy.
- jofer 7y ago
  Just my $0.02: I've maintained and/or written more than a few large desktop apps in both python and C++. The python ones are a hell of a lot easier to maintain, i.m.o. Python _is_ strongly typed unlike JS, and I don't feel like the dynamic typing aspects have ever really bit me from a maintenance perspective. At least in my experience, I've seen a lot of either verbose/repetitive or highly cryptic C++ written to in situations that dynamic typing makes straightforward and i.m.o easier to maintain. To be fair, though, I have a pretty accurate mental model of what python's doing under the hood, and I still regularly find myself mystified by certain C++ language features and what the compiler actually does in slightly ambiguous situations. I've nominally been using C++ longer, but I've used python a lot more frequently. (I'm primarily in scientific computing.) As a whole, I've always found python to be a nice language from a maintenance perspective, though I'll grant that people have more room to do bizarre things in some circumstances. I've definitely seen some unmaintainable and unreadable python, but I've seen that every bit as frequently in static-typed languages. I feel that python is quite well-suited to desktop application development. Part of this boils down to Qt being a nice library regardless of whether you're working in C++ or python. However, python codebases tend to be more succinct and readable. In the end, I've consistently found that to be a larger advantage in maintenance than static typing.

PythonicAlpha 7y ago

I actually expected some elaborate work about the imperfection of Python. What I got was a list that started with at least three points that are already obsolete, because only valid for Python 2, which is already declared obsolete. Every language with some history has its humble start and is evolving. To carry the errors of the past is just not fair. You could of course drag along the first Java version and conclude that Java is bad -- but you would really invalidate your own opinion.

psv1 7y ago

So this just links to someone's opinion on Python 2 vs 3 instead of an actual discussion on the drawbacks of Python, right?

misterdoubt 7y ago
To be fair, it also highlights a benefit of Python 2.2 over 2.1. (I.e., improvements made in the language eighteen years ago.)

rjmunro 7y ago

The main drawback of python for me, compared to NodeJS is the whole sharing projects onto different machines with virtualenv or whatever. package.json and node_modules just works by default in so much cleaner a way. You can use npm or yarn or just a zip of the node_modules to share the environment with a colleague or to deploy.

beagle3 7y ago
conda solves that for python at least as well as npm/yarn does. I don't understand while it is not in wider use (except for lack of PR).
- fitech 7y ago
  how does conda solve this? Will conda fallback to pip if the conda repository doesn't contain one of your dependencies?
  - athorax 7y ago
    With your conda environment activated, you can run pip install requirements.txt. You don't have to use any of the conda commands outside of creating the environment.
- athorax 7y ago
  conda / miniconda has definitely solved most of my grievances with deploying python applications
- physicsguy 7y ago
  If you want to add your own project to Conda, you need to use conda forge, because Anaconda itself is a curated distribution. Maintaining a conda forge package has been, for us, a complete nightmare. If you depend on another conda-forge package you can have the issue that the library is configured to suit whoever first wrote the conda-forge package - i.e. by disabling parallelism or providing only shared/static libraries, and have that maintainer be completely unresponsive or unwilling to change it.

canada_dry 7y ago

Quora click bait. A dull and benighted article that adds nothing to the discussion.

dragonsh 7y ago

I like Python because of zen of python [1]. This fits my brain and had been very helpful. Indeed in 2004 I chose Django instead of Ruby On Rails just because explicit is better than implicit. Overall Python is productive and good. Yes it has some warts and corner case, but than its evident. Among programming language python has a humble community and very approachable. Also most programmer in Python will not hesitate to use low level language and interface with Python when necessary. It's not considered bad. >>>import this "Beautiful is better than ugly. Explicit is better than implicit. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Special cases aren't special enough to break the rules. Although practicality beats purity. Errors should never pass silently. Unless explicitly silenced. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than right now. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Namespaces are one honking great idea -- let's do more of those!" [1] https://www.python.org/dev/peps/pep-0020/ https://www.python.org/dev/peps/pep-0020/

smt88 7y ago
I agree with a lot of these things, but actually disagree that Python is good at exemplifying some of them. For example, semantic whitespace is arguably implicit, hard to read, invites density (compared to an extra line for braces), and (again arguably) is ugly. Yes, some of these things are subjective, but it's hard for me to confidently recommend Python to someone with these values.
- dragonsh 7y ago
  May be different people have different experience with Python. After c and Perl had been using it for over 15 years and among the languages I have seen Python code is one of the most readable one so far, again subjective as I like sparse and empty spaces in architecture with minimalist design. For me whitespace is same in Python code. Whitespaces forces programmer to make code readable. Obviously today with tools like gofmt, rustfmt it seems easy and those are inspired by Python. Python PEP process has been adopted by many programming language. Try JCP process and see what I am talking about.

skrause 7y ago

I have to deploy web applications written in Python on Windows... no uWSGI, no Gunicorn and no easy multiprocessing because no fork(). It's painful quite often and it makes me loathe the GIL, but I still enjoy writing Python code.

kerkeslager 7y ago
I'm curious what what your approach to this is. Relying heavily on Twisted seems to be the obvious choice?

brbrodude 7y ago

Dunno if Ruby locked my mind into a certain mode, but I've never felt good doing anything with python :( 2 different projects I tried participating with a lot of years in between, still felt the same. Granted, I can't say I've really studied it properly.

m4r35n357 7y ago

Python is the simplest language I know of that does operator oveloading. If I had to write my pet maths project in c++ I would not even have got started. Sometimes abstract "drawbacks" are irrelevant!

kyllo 7y ago

These are minor annoyances to me. The major annoyance I have with Python is that most Python code makes such heavy use of classes, even when it only needs lists, tuples, and dicts. Why do I really need a class, when: - Instance fields can be added and removed at runtime - Private fields and methods are not actually private ("we're all consenting adults here") - No pattern matching on types and `if isinstance(foo, Bar):` is an anti-pattern because it's a duck-typed language - Interfaces are neither available nor necessary due to late binding. Abstract Base Classes are the closest thing to an interface, but they're also unnecessary because again, it's duck-typed. - Inheritance is widely considered to be a mistake ("Prefer composition over inheritance" etc) - Classes tend to complicate testing I can use classes to write custom data structures, I guess, but in a language as high-level as Python, I can just model trees and graphs with dicts. If I need a more performant data structure, I'm not writing it in Python in the first place. I've seen some very experienced Pythonistas recommend using namedtuple instead of classes for most use cases, and I tend to agree with them. That gets you immutability as well as dot notation for accessing fields. Clojure programmers seem perfectly happy with just lists and maps, and after experiencing that, classes feel like a bolted-on misfeature in Python.

Scarblac 7y ago
You can even subclass namedtuples to get immutable value objects with helpful methods. I like classes over dictionaries because I can look at the class definition to see what the variables my function gets are, and what functions (methods) exist to work with them. I used to work with a code base that passed dictionaries around, and there were a lot of hacks where people had some data somewhere that they needed somewhere else, and the dict was available both places, so why not add it to that... Different pieces of code added different things and you were never quite sure which version of the data was passed this time for the "layers" parameter. Somehow it doesn't happen as much with classes. It was like duck typing to the extreme. I call it smurf typing, if it smurfs like a smurf, smurfs like a smurf and smurfs like a smurf, nobody knows what's going on anymore. Immutable value classes, those are good.
j88439h84 7y ago
My solution to this is http://attrs.org http://attrs.org or dataclasses. They make a huge difference in readability and type safety.

kerkeslager 7y ago

Almost every discussion of programming languages falls into bike-shedding[1] and this is no exception. The only thing he mentions worth talking about is the GIL. Syntax and small API gotchas can be learned by a beginner programmer in a matter of days of using the language, and are fairly irrelevant to your overall experience. If whitespace and using the division operator are big problems for you, significant software development probably isn't within your abilities. In addition to the GIL, other problems I'd point out with Python: 1. At one point, Python was "batteries included". This is largely no longer the case any more--most projects are largely dependent on PyPI, and there's been a growing sentiment in the last few years that "the standard library is where modules go to die". PyPI libraries are of inconsistent quality and have a high turnover rate; the "standard" for what to use changes fairly rapidly. And if you manage to make good choices of mature libraries and not have to change them every year or so, you still have to manage dependencies, which complicates deployments. 2. Fracturing community: there are now a bunch of different non-standard ways to install Python and Python dependencies, which conflict with each other, and none of which fit all use cases, so you have to use all of them and deal with conflicts. This exacerbates issues with 1. 3. Increasing dependency on non-pure-Python dependencies which don't build trivially. There are reasons for this: Python often isn't performant enough for certain tasks, and other languages have some very good tools. However, this means you can't just `pip install` a library and expect it to work--even very common libraries like Pillow don't without fiddling. Again, this exacerbates problems with 1. 4. Lack of a good desktop UI framework. It's apparent that not as many people are using Python for native UIs any more. tk is cludgy and doesn't result in pretty UIs, and despite being part of the standard library, it doesn't work out of the box on MacOS. wxWidgets doesn't build on MacOS without significant work, and documentation is for the C++ version of the library. This is sort of the intersection of 1, 2, and 3, but in desktop UIs they combine to form a perfect storm. If you're developing a desktop UI, there are better languages, but I'm not going to post them here because I'd rather keep this as a constructive criticism of Python than a language competition. 5. Introspection being used to change language syntax without solving the problems the language syntax solves. I'm really looking at Django here, but they're not the only guilty ones. When you call a function, i.e. route_on_http_method(GET=get_handler, POST=post_handler), functions can fairly easily check arguments and throw an exception from a logical spot--i.e. route_on_http_method(GIT=get_handler) throws an exception immediately. But when you have `class MyView(GenericView): def git(self, request): ...` you get no exception until you try to call the view, in which case you get a wonderful cornucopia of meaningless line numbers in a useless stack trace. Sure, Django code looks nicer and more organized, but as I said, syntax isn't that important. Debugging IS important. Using the bikeshedding example, this is breaking the nuclear power plant to fix a problem with the bike shed. And this is a generous example: it's fairly simple and Django is one of the libraries that does a better job of this. If you really want configuration-oriented programming, you'd be better off parsing in JSON files and doing explicit error checking when you parse them in, rather than introspecting out a syntax that's not really code and not really configuration. Introspection hasn't played out well as a Python feature. You'll note that all these problems are CULTURAL problems, rather than problems with the language itself. And that's my point, because those are the problems you can't easily work around, and it's the problems you can't easily work around that make or break the language. I say all this because I love Python. I've worked in Python for the last 6ish years, and don't see that changing any time soon. [1] https://en.wiktionary.org/wiki/bikeshedding https://en.wiktionary.org/wiki/bikeshedding

zeveb 7y ago

Back when I wrote a lot of Python, something I disliked was how one could easily reload a module, but existing instances of classes wouldn't get updated. You could implement the machinery to do so for your own stuff, but of course that could be arbitrarily flaky. Performance was definitely an issue, but for the sort of programming we were doing it normally wasn't a big issue. Duck typing could definitely be an issue — one had little confidence that code would run as desired. Overall, I really liked Python, but these days I'd sooner use Go or Lisp.

abakus 7y ago

Simple is better than complex. There should be one-- and preferably only one --obvious way to do it. https://xkcd.com/1987/ https://xkcd.com/1987/

yen223 7y ago
Also, here are 4 different ways to do string formatting

makz 7y ago

I love python and it is my main language for almost everything. However, yesterday I was playing with python’s async/await and I came to the conclusion that it is a bit... useless. Not a big deal, because i can use other stuff to accomplish the same I was trying to do. Or maybe I was doing it wrong.

anm89 7y ago

Maybe I'm naive, but in my mind besides their ecosystems and superficial syntax differences there isn't that much functionally different between Python and Ruby, with the major to exception of blocks in Ruby. In which case the decision between the two seems to be between a thing and a slightly better version of itself. I totally respect that many people see this differently and probably exactly opposite but to me it always feels really hard to justify using python for this reason. Just for fairness sake I'm not trying to trash python. I think it's a great language.

partizanos 7y ago

Sorry but it just seemed odd I didn't see a mention for GIL (global interpreter lock). Because of this mechanism that ensures concurrency safety Python does not support parallel execution of threads. I am wondering if the rest of the HN community finds it as a major disadvantage.