h1. [ No Python ] h1. Preable bq. <tuomov> but python FAILS <tuomov> fucking idiots <tuomov> typical foss crap.. <tuomov> it's shit <tuomov> it's pure shit _Tuomo Valkonen on Python_ *Disclaimer:* I do not code in Python. Why would I want to code in such a broken language? If you think if this page contains errors, or you do know about even more severe pitfalls of subj. you are welcome to send [[Voker57/contact|me]] mail about those. h1. Python brokenness from user's point of view. Have you ever tried to use Python app? For example, Gajim, lastmp, debtorrent, deluge, aldrin, wicd? If you didn't notice that these programs are sluggish and consume much memory, -you're blind- even now you can still be healed. Lastmp, for example, crashes "wherever it encounters broken Unicode":http://bitcheese.net/vlog/post/580. Solving this problem requires -surrounding unicode loadings with try..catch- calling unicode(data, 'ignore') instead of unicode(data). Note the string option used where saner language would use enum, flags or other method. h1. Python brokenness from developer's point of view. h2. Python's broken syntax h3. Learning Python Ok, let's start with tutorial, the 'official' one. It says: bq. The interpreter acts as a simple calculator: you can type an expression at it and it will write the value That's wrong; @python@ can't be used as a simple calculator. Let's prove it: bc. >>> 2.3 - 3.4 -1.1000000000000001 -1.1000000000000001 ?! It's just -1.1, the others are FPU intimate problems and shouldn't trouble the user. Imagine you come to shop and seller, whose cash machine's software is in python, gives you .00000000001 cent as change. That's not a simple calculator. You can work around the problem by using @print 2.3 - 3.4@ instead. But that's definetely not simple. h3. Indentation Indenting code properly is good. But why make it part of syntax? To understand codemonkeys' code? They can write in one line anyway, and while you can convert this to proper indentation, you cannot do that vice-versa if indentation is wrong, and compiler wouldn't even complain. h3. @__fuck__(self, brain)@ Python treats objects as hashes (dictionaries), but this approach is flawed. You still need those 'blessed' methods, and python surrounds them with double underscores as distinction measure. Hell yeah! When in future even more kludges will be required for Python OOP not to fall apart, coders will learn to tell apart three and four underscores with normal font. Every object method is passed with *self* as first argument. Omg why? So you could call it wtfmycoolvarname and ruin the code understandability? So much for indentation and shit. Anyway, official python book says it's strictly discouraged, so type (self), monkeys. Hell, you don't get so deep in shit even when coding C++. Speaking of unnecessary chars, you need those parentheses everywhere. If you omit them, you get "Invalid syntax" from python. Gee, that really helps, my syntax is incorrect. Would be even more awesome if no position in code is reported. So let's count chars. Here goes class initializer definition in python: bc. def __init__(self) return None Same in ruby: bc. def initialize 0 36 chars against 18. And this code isn't doing anything worthly anyway. h3. @List. list? __list? the_list? thelist...@ Python uses and/or encourages no naming convention with classes/functions. list <- what is that? A local variable? A class? A *typeclass*? Who knows. Python's only promoted and used naming convention is 'your_shift_is_for_underscopes', which is totally lame. Also, __more___underscores_____means_more____________coolness_______________. Speaking of inconsistency, Python does not follow 'the least surprise' principle. What is xrange? Why it's 'x'? Why not name it zfoobar? h2. Too slow to fly, too low-level to ride. Python is considered to be 'glue-language'. Despite this claim, it gets used in maths and high-loaded stuff. When the snake people discover the suckiness of their language, they augment it with C code and even make forks, incompatible with reference implementations. So you have to kludge your code to make it work a bit better. The only any reliable implementation effectively disables thread concurrency, thanks to "GIL":http://en.wikipedia.org/wiki/Global_Interpreter_Lock. On the other hand, you have all the good-known stuff from C like parentheses all over the place and segfaults. Do you see segfaults often in dynamic languages? Well in python you do. Also, its libraries require *compilation*. What a nonsense. No pattern matching. And even no switches — actually even PHP has it. Some people recommend to use "if - else if" constructions instead... Python has no static type system. It makes impossible to apply "correct by construction" principle in python. h2. Objects. I mean, hashes of methods Python appears to be an object-oriented language, but OOP system is just a syntactic sugar for dictionaries, and you have to fall back to direct intervention to do serious business. It doesn't even have private members. Some people say that it's Python vision of OOP, but then they might as well say that raising horrible kludges in C to obtain something that remotely resembles OOP is C vision of OOP. Ruby shares the similar niche, but features brilliant OOP with conceptions borrowed from Smalltalk. h2. Pythoogle Many people praise Python because Google uses it. Well, it's "used":http://panela.blog-city.com/python_at_google_greg_stein__sdforum.htm for non-critical tasks mostly, and they use ancient 2.2, because of API breakage between minor releases. The only web services done in python are code.google.com (which doesn't support any decent VCS) and google groups. h1. Conclusion Python is totally broken. Please don't write crappy apps with it or use other people's ones. If you still think it's a really good language, ask yourself: # Haven't I been using C++ for ages and now is blinded with metaprogramming & PR? # Did I try other dynamic languages? such as Ruby or LISP? h2. Links Read a [[nopython-story|success story]] (Russian) from one of our former patients.