LOL@PYTHON

they removed fold/reduce from python. lol @ noob imperative programmers c:

http://www.artima.com/forums/flat.jsp?forum=106&thread=98196

So now reduce(). This is actually the one I've always hated most, because, apart from a few examples involving + or *, almost every time I see a reduce() call with a non-trivial function argument, I need to grab pen and paper to diagram what's actually being fed into that function before I understand what the reduce() is supposed to do. So in my mind, the applicability of reduce() is pretty much limited to associative operators, and in all other cases it's better to write out the accumulation loop explicitly.
Why would you use a language written by a toilet scrubber?

Perl 7 4evar

>>2
The guido is right on this one.  Due to the fact that python has no useful lambdas built into the language and no TCO in the most popular interpreter (and in most/all less popular ones) you have to be very anal to think in a functional paradigm while programming python.  It is a 100% imperative language that makes functional programs more clumsy and hard to express and understand.

So yeah, not having reduce in Python is like not having reduce in Assembly.  It just does not make much sense syntactically and computationally.

>>2
Haha, stupid uneducated kike, like all of them.

>>5
You would know.

I thought Python was all about there being one (presumably right) way to do things. Yet here these goyim are bickering about the myriad of ugly things you should do instead of using lambda. It's like ``guys, hammers are too academic. I propose we drive nails with this rock.'' ``I agree, the hammer has do go, here's another rock we can use.'' ``Rocks rock, guys, but what about this pipe I found in the alley? It's pretty sturdy.''

Lambda is G-d's way, goyim. Just use it.

The proponents of Python cite 'indentation' as the worst problem, this is a strawman argument 'this is the worst problem and its not really a problem'. This argument has been voted up presumably by people who like the language, because it is certainly not a good reason not to use Python. I am far from an expert at Python, but I have done a couple of semi-serious projects in the language and will try to recall specifically what I didn't like.
- Broken scoping: Python, like many other scripting languages, does not require variables to be declared, as let (x 123) in Lisp or int x = 123 in C/C++. This means that Python can't even detect a trivial typo - it will produce a program, which will continue working for hours until it reaches the typo - THEN go boom and you lost all unsaved data. Local and global scopes are unintuitive. Having variables leak after a for-loop is confusing. Worse, binding of loop indices can be very confusing; e.g. "for a in list: result.append(lambda: fcn(a))" probably won't do what you think it would. Why nonlocal/global/auto-local scope nonsense? Such shortsighted scoping design leads to Python's faulty package system, which exposes everything, so that, for example, typing time.sleep=4 instead of time.sleep(4) would break the system-wide sleep function, while accidentally assigning some method to time.sleep, and you won't even give a runtime error - just a hard to trace bug. Moreover, dynamic scoping impedes encapsulation and compilation, so everything you write will be open source: no FASLs, DLLs or EXEs, while developer may want to have control over the level of access to prevent exposure of internal implementation, as it may contain proprietary code or because strict interface/implementation decomposition is required.
- Inconvenient syntax: FIOC or Forced Indentation of Code (aka "off-side" rule) impedes using CLI, automatically generating Python code and moving around large code blocks. Editing Python code requires special editors (forget about Word/Notepad), that expand tabs into spaces, while transmitting python code through a web post or email breaks indentation. Absence of block-terminator is so utterly confusing, that you'll find yourself ending blocks with #endif anyway. It's painful to deal with other things that need indenting, such as large SQL queries, or HTML when you're using things like mod_python. And why is there ":" when code almost always has a newline after it? Python's whitespace indentation indulges messy horizontal code (> 80 chars per line), where in Lisp one would use "let" to break computaion into manageable pieces: get used to stuff like self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)]), while logical connectives being lost in a pile of other symbols, like "and" in "if y > 0 or new_width > width and new_height > height or x < 0". Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has a large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics: good luck discerning [f(z) for y in x for z in gen(y) if pred(z)] from [f(z) if pred(z) for z in gen(y) for y in x]. In addition, you will enjoy cryptic expressions like z(*z(*m.i())[::-1]).
- Crippled support for functional programming. Python's lambda is limited to a single expression and doesn't allow conditionals. Python makes a distinction between expressions and statements, and does not automatically return the last expressions, thus crippling lambdas even more. Assignments are not expressions. Most useful high-order functions were deprecated in Python 3.0 and have to be imported from functools. Creating an object just to call a function, like ''.join(map(str, r)), is just annoying sign of bad language design. No continuations or even tail call optimization: "I don't like reading code that was written by someone trying to use tail recursion." --Guido
- Inconsistent type system: no Numerical Tower, meaning 1/2 would produce 0, instead of 0.5, leading to subtle and dangerous errors. Arithmetics on strings is surprising at best: "2" * 3 is "222", "2"+"3" is "23", while "2" * "3" and "2"+3 are type errors. Multiple false values: "", [], (), False, 0, 0.0 - all auto-coerce to false, but 0==False and 1==True, while ""!=False and ()!=False; worser, True/False auto-coerce to integers, so ['no', 'yes'][False] won't give an error, although ['no', 'yes'][0.0] does give an error. Why have both dictionaries and objects? Why have both types and duck-typing? The Python language reference devotes a whole sub-chapter to "Emulating container types", "Emulating callable Objects", "Emulating numeric types", "Emulating sequences" etc. -- only because arrays, sequences etc. are "special" in Python. Subtle data types (list and tuple, bytes and bytearray) will make you wonder "Do I need the mutable type here?", while Clojure and Haskell manage to do with only immutable data.
- Python has too many confusing non-orthogonal features: references can't be used as hash keys; expressions in default arguments are calculated when the function is defined, not when it’s called. Patterns and anti-patterns are signs of deficiencies inherent in the language. In Python, concatenating strings in a loop is considered an anti-pattern merely because the popular implementation is incapable of producing good code in such a case. The intractability or impossibility of static analysis in Python makes such optimizations difficult or impossible. Quirky triple-quoted strings seem like a syntax-decision from a David Lynch movie, and double-underscores, like __init__, seem appropriate in C, but not in a language that provides list comprehensions. There are better ways to mark certain features as internal or special than just calling it __feature__. self everywhere shows that OOP was bolted on. Poor UTF support and unicode string handling is somewhat awkward.
- Poor performance: Python's GC uses naive reference counting, which is slow and doesn't handle circular references, meaning you have to expect subtle memory leaks and can't easily use arbitrary graphs as your data. In effect Python complicates even simple tasks, like keeping directory tree with symlinks. Global Interpreter Lock (GIL) is a significant barrier to concurrency. Due to signaling with a CPU-bound thread, it can cause a slowdown even on single processor. Reason for employing GIL in Python is to easy the integration of C/C++ libraries. Additionally, CPython interpreter code is not thread-safe, so the only way other threads can do useful work is if they are in some C/C++ routine, which must be thread-safe.
- Python has no well-defined and stable API, making life easier for Guido and tough on everybody else - that's the real cause of Python's "version hell". Python has inherited the installation mentality idea that libraries should be installed, so it in fact is designed to work inside unix package management, which basically contains a fair amount of baggage (library version issues) and reduced portability. Of course it must be possible to package libraries with your application, but its not conventional and can be hard to deploy as a desktop app due to cross platform issues, language version, etc. Open Source projects generally don't care about Windows, most open source developers use Linux because "Windows sucks". Python third-party library licensing is overly complex: licenses like MIT allow you to create derived works as long as you maintain attrubution; GNU GPL, or other 'viral' licenses don't allow derived works without inheriting the same license. To inherit the benefits of an open source culture you also inherit the complexities of the licensing hell.
- No outstanding feature, that makes the language, like the brevity of APL or macros of Lisp. Python doesn’t really give us anything that wasn’t there long ago in Lisp and Smalltalk. "This is a hobby project and I neede my time for other things…" --Guido van Rossum (http://1997.webhistory.org/www.lists/www-talk.1993q1/0060.html)
- Author of Python, Guido van Rossum, is Jewish, so if you dislike Jewish omnipresence and dominance, boycott Python.

>>1
Symta: S any > 42
Python: any(x > 42 for x in S)

PYTHONM@STER

Rossum is a fucking kike. Can't even implement `+` consistently:

>>> 'foo'+'bar'
'foobar'
>>> sum(['foo', 'bar'])
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unsupported operand type(s) for +: 'int' and 'str'
>>>

>>11
What the fuck makes 'foo' and 'bar' an int and a string?

Seriously, Guido?

>>8
Post the Ruby, PHP, Java and Javashit ones, ``please''.

>>12
His language is reducing with 0 as the base value, rather than the identity for whatever the type is under +.

Not that unreasonable, if you think about it, but isn't FIOC supposed to be all about the duck typing?

Ducks are Touring complete. They move across a (theoretically) infinite river in either direction. They have memory. In each step, they can catch fish, take a dump, or quack.

>>15
Dicks are Touring complete. They move across a (theoretically) infinite river in either direction. They have memory. In each step, they can catch fish, take a dump, or quack.

then someome asks if his dick quacks and that thread from a few days ago repeats

>>11
Use sum(['foo', 'bar'], []), but yeah, it's retarded.

>>11
If only there was a way to say (reduce + "" '("foo" "bar"))

>>19
"" '
What kind of shit syntax is that?

>>20
Go back to /g/ if you can't stop being so new.