"Of course, Python couldn't have told me 'request' [from Bottle] didn't have a member 'content_type' and ended the matter right then and there. No, it had to string me along, doing anything except let me know something was wrong."
In this ideal world of yours, the developer needs to mark if a property is mutable or immutable, yes?
Python API developers already have the ability to produce immutable attributes.
In fact, as you can see from the link I gave, the attribute is currently defined as a read-only property. According the version control log, it looks like it was added on "Tue Jun 26 12:14:42 2012 +0200". This essay was written only a few months later, on 2012-10-17.
So while there are many reasons to not like Python-the-language, this specific complaint is 1) incorrect, in that content_type is an attribute of the request, and 2) a library API issue which has since been fixed, so is not intrinsic in the language.
There is still the valid complaint that most Python API developers do not mark attributes as immutable. This is part of the Python worldview that we are all "consenting adults". However, the essayist did not voice that complaint.
The author spends so much time complaining about every little thing that happens that I can't tell if this is serious or meant to be satire. How is this any different than someone switching Windows => OSX and complaining about how the keyboard shortcuts are different (b/c obviously there is One True Way)?
>Holy hell, my content type is a fucking day and Python happily spits out the resulting gibberish.
I think this is one of those cases where the 'we are all consenting adults' mantra applies. I have a really hard time imagining a scenario in which anyone I know would write that line of code deliberately, and an even harder time imagining one where a date gets passed as content type accidentally.
If only it was one complaint. It's an endless stream of whining from somebody who doesn't understand dynamic typing, and thinks that profanity is a form of punctuation (or maybe it's supposed to be humoristic? I can't tell).
Apparently the author cannot be bothered to learn about the Python ecosystem or read docs on the functionality he is using. It's probably true that dynamic typing is a very bad match to those characteristics, but... I could give you the same rant about lots of aspects of Java's toolchain. The reality is that you have to learn the tools before there is much point in passing judgement.
Gosh, and all I'm upset about is the need to put colons after statements when they're clearly not needed.
More seriously, when I work with Python, I constantly have this vague feeling of mild frustration. I think it's because of all the oddball library stuff, issues with autocomplete in my IDE (I know I should find something better), idiomatic Python ways that seem to short circuit my brain's parser, I'm pretty much googling for almost every line I write.
But then, after a few minutes, I look at what I've made and this weird wave of productivity washes most of it away and I'm surprised at what I just created.
Recently I tried to rewrite a personal Java project in Python. I had hacked away at the Java project in my spare time for weeks. The Python version took me about 10 hours over two days, that included hunting down and installing all the libraries.
I do agree that cross-platform support isn't what it should be, and there's a surprising number of times where the Python library is just a wrapper around a command-line executable (which of course only builds on Linux or Windows or whatever).
There's also an alarming number of old libraries which have long since been deprecated, but the internet is awash in the former library's popularity and it's much harder to find information on the supposed replacement. More importantly, nobody really bothers to tell you "don't use the old and busted one, use the new hotness". You just sort of have to figure it out because pip doesn't have it or something.
I'd also love a Python version of Perl's -c which sort of pseudo-compile-time checks your code without running it.
The author doesn't even try to figure out which deficiencies are Flask's, Python's, pip's, or his own. But he sure is angry, and that's the only thing that matters when writing a blogpost with the title "Why I hate Python".
Well, the "PHB" was right for once. Requesting the use of mainstream languages like PHP or Python prevented the use of exotics like the author mentioned he would have used. They might be good but their limited user base makes it very difficult to maintain the code in the future.
The choice seems to be very limited though, there would have been more options in the market. But using Python or PHP has worked for businesses of seemingly sizes and the blog author could have come up with reasons to his boss why they don't fit.
From the elegance of the article's writing and the insightfulness presented the "PHB" seems to have done the author a benefit though to select reasonably simple systems.
Not only the author writes like a 16 year old, but also thinks he's funny. A very bad combination.
In any case, the core of TFA is: "I'm trying random stuff randomly for the first time and not everything plays along fine" and "dynamic typing doesn't prevent erroneous dynamic attribute assignment".
tl;dr Python doesn't magically make a bad programmer better.
Many of the author's complaints have little or nothing to do with Python. Instead they're about packaging, HTML protocol, bad documentation, frameworks, and so on. Most of those problems would still exist in any other language. If the OP had been a comment here, it would have (rightly!) been voted into the grey for gratuitous negativity.
I have been using python for several year and I (have grown) love it. Coming from C++ at first I was quite taken aback by several perceived flaws (which for the most part are not flaws).
Clearly the author would need a Python mentor, or start with a project with a less demanding learning curve. Python is not like PHP were a beginner can just bang out some copy/pasted code and voila!
A lot of the complaints I read seem to have to do with a)Important project needs to move along b) Using a language for the first time, and learning it's quirks and ecosystem
I would gladly help the author if need be, and allow him to appreciates the language a bit more ..
21 comments
[ 2.1 ms ] story [ 66.6 ms ] threadUmm, but the request object does have a content_type. See http://bottlepy.org/docs/dev/_modules/bottle.html#BaseReques... .
Python API developers already have the ability to produce immutable attributes.
In fact, as you can see from the link I gave, the attribute is currently defined as a read-only property. According the version control log, it looks like it was added on "Tue Jun 26 12:14:42 2012 +0200". This essay was written only a few months later, on 2012-10-17.
So while there are many reasons to not like Python-the-language, this specific complaint is 1) incorrect, in that content_type is an attribute of the request, and 2) a library API issue which has since been fixed, so is not intrinsic in the language.
There is still the valid complaint that most Python API developers do not mark attributes as immutable. This is part of the Python worldview that we are all "consenting adults". However, the essayist did not voice that complaint.
I think this is one of those cases where the 'we are all consenting adults' mantra applies. I have a really hard time imagining a scenario in which anyone I know would write that line of code deliberately, and an even harder time imagining one where a date gets passed as content type accidentally.
You can still check your data in python methods and reject it if it doesn't respond to your expected methods. Duck typing, anybody?
More seriously, when I work with Python, I constantly have this vague feeling of mild frustration. I think it's because of all the oddball library stuff, issues with autocomplete in my IDE (I know I should find something better), idiomatic Python ways that seem to short circuit my brain's parser, I'm pretty much googling for almost every line I write.
But then, after a few minutes, I look at what I've made and this weird wave of productivity washes most of it away and I'm surprised at what I just created.
Recently I tried to rewrite a personal Java project in Python. I had hacked away at the Java project in my spare time for weeks. The Python version took me about 10 hours over two days, that included hunting down and installing all the libraries.
I do agree that cross-platform support isn't what it should be, and there's a surprising number of times where the Python library is just a wrapper around a command-line executable (which of course only builds on Linux or Windows or whatever).
There's also an alarming number of old libraries which have long since been deprecated, but the internet is awash in the former library's popularity and it's much harder to find information on the supposed replacement. More importantly, nobody really bothers to tell you "don't use the old and busted one, use the new hotness". You just sort of have to figure it out because pip doesn't have it or something.
I'd also love a Python version of Perl's -c which sort of pseudo-compile-time checks your code without running it.
Try flake8: https://flake8.readthedocs.org/en/2.3.0/
It's more of a linter, but it will catch syntax errors while it's at it.
The choice seems to be very limited though, there would have been more options in the market. But using Python or PHP has worked for businesses of seemingly sizes and the blog author could have come up with reasons to his boss why they don't fit.
From the elegance of the article's writing and the insightfulness presented the "PHB" seems to have done the author a benefit though to select reasonably simple systems.
In any case, the core of TFA is: "I'm trying random stuff randomly for the first time and not everything plays along fine" and "dynamic typing doesn't prevent erroneous dynamic attribute assignment".
Many of the author's complaints have little or nothing to do with Python. Instead they're about packaging, HTML protocol, bad documentation, frameworks, and so on. Most of those problems would still exist in any other language. If the OP had been a comment here, it would have (rightly!) been voted into the grey for gratuitous negativity.
There's a term for programmers who don't make dumb mistakes: Goddamned LIARS.