Python is almost perfect.

At least it is closer to perfection than any other language.

If Python "forces" you to indent anywhere you wouldn't have indented anyway, you should probably just stop programming. By assuming the competency of programmer, Python effectively eliminates the need for braces and semi-colons. Too incompetent to understand? Have fun with Ruby.

Value syntactic simplicity from the interpreter's point of view over syntactic beauty and elegance from the programmer's point of view? Have fun with Lisp. Since my complex human brain is capable of quickly understanding more than two special characters in addition to a base-10 numerical system and 26-letter alphabet, Python does not confuse me. If you're more comfortable with globs of unstructured text surrounded by thousands of parentheses, then enjoy your toy language. That's why Python has been around a fraction of the time Lisp has, yet it has exponentially more practical application than Lisp does.

Python is for grown up programmers. Perl is for old men who didn't have Python in their time. Everything else is for children who want to put on big kids clothes and play grown up.

Go FIOC yourself.

almost perfect
almost
faggot

Python programmer here. You (>>1) are a cretin.

>>1
0/10 too retarded, not believable

Python programmers are this retarded.

Obviously this is a shallow attempt at flamebaiting, but I actually like THE FORCED INDENTATION OF CODE.

Combining syntax and legibility/good practice was a neat idea.

The funny thing is that you cite it's simple syntax as it's main advantage.... But of course you're right as everything else is a disadvantage.

It's more powerful than BASIC but that's about it.

Every language needs a way to break up statements. Lisps use parentheses, C-likes used braces and semicolons, Python uses indentation. Yet, all languages support indentation for legibility. Having the interpreter understand indentation is nothing short of brilliant. Consider the following simple functions.

(define (square x)
  (* x x))

function square(x) {
  return x * x;
}

def square(x):
  return x * x

The latter is clearly the most beautiful and intuitive.

>>9
I prefer the first and second.

>>9

why can't I do def square(x): return x * x

I prefer:
square = lambda x: x*x

>>11
Why would you want to?

(define (square x) (* x x))

function square(x) { return x * x; }

def square(x):
  return x * x

The third is still the most beautiful and intuitive.

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.

- Everything you write will be open source. No FASLs, DLLs or EXEs. 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. 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.
- Installation mentality, Python has inherited the idea that libraries should be installed, so it infact 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".
- Probably the biggest practical problem with Python is that there's no well-defined API that doesn't change. This make life easier for Guido and tough on everybody else. That's the real cause of Python's "version hell".
- 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 (like most 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 can definitely be 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?
- Python indulges messy horizontal code (> 80 chars per line), where in Lisp one would use "let" to break computaion into manageable pieces. Get used to things like self.convertId([(name, uidutil.getId(obj)) for name, obj in container.items() if IContainer.isInstance(obj)])
- 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. No continuations or even tail call optimization: "I don't like reading code that was written by someone trying to use tail recursion." --Guido
- Python has a faulty package system. Type time.sleep=4 instead of time.sleep(4) and you just destroyed the system-wide sleep function with a trivial typo. Now consider accidentally assigning some method to time.sleep, and you won't even get a runtime error - just very hard to trace behavior. And sleep is only one example, it's just as easy to override ANYTHING.
- Python's syntax, based on SETL language and mathematical Set Theory, is non-uniform, hard to understand and parse, compared to simpler languages, like Lisp, Smalltalk, Nial and Factor. Instead of usual "fold" and "map" functions, Python uses "set comprehension" syntax, which has overhelmingly large collection of underlying linguistic and notational conventions, each with it's own variable binding semantics. Using CLI and automatically generating Python code is hard due to the so called "off-side" indentation rule (aka Forced Indentation of Code), also taken from a math-intensive Haskell language. This, in effect, makes Python look like an overengineered toy for math geeks. 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]
- Python hides logical connectives in a pile of other symbols: try seeing "and" in  "if y > 0 or new_width > width and new_height > height or x < 0".
- Quite 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 can make you feel like OO was bolted on, even though it wasn't.
- 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. Why have both dictionaries and objects? Why have both types and duck-typing? Why is there ":" in the syntax if it almost always has a newline after it? 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'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.
- 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.
- Problems with arithmetic: no Numerical Tower (nor even rational/complex numbers), meaning 1/2 would produce 0, instead of 0.5, leading to subtle and dangerous errors.
- Poor UTF support and unicode string handling is somewhat awkward.
- 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.

>>13
square x = x * x

>>13
Third is ugly and non-uniform. It reminds me of animalistic natural languages, as opossed to perfect Lisp-machines. Only subhumans, like jews, love natural languages.

>>14
- Python hides logical connectives in a pile of other symbols: try seeing "and" in  "if y > 0 or new_width > width and new_height > height or x < 0".
I disagree. Even nano has the required syntax highlighting to make the logical connectives pop out. It's arguable whether "and/or" is any better or worse than "&&/||".

>>9
Every language needs a way to break up statements. Lisps use parentheses, C-likes used braces and semicolons, Python uses indentation. Yet, all languages support indentation for legibility.
Except Symta. Which uses arrows to pack everything into single line

morph T U -> O:U.Owner T:(T,str? |> UTs.'T :: T) -> T.Id=:U.Id
 -> T.Owner=:O     -> T.Color=:U.Color -> T.Act=:U.Act     -> T.Tile=:U.Tile
 -> T.Disp=:U.Disp -> T.Dir=:U.Dir     -> T.Frame=:U.Frame -> T.Anim=:U.Anim
 -> T.Hits=:U.Hits -> T.Kids=:U.Kids   -> U.Effects |> T.Effects=:It
 -> U.Fire |> T.Fire=:It -> U.Res |> T.Res=:It -> U.Mana |> T.Mana=:It
 -> skip1 U.Id !Owned,O.(U.Type) => @!Owned,O.(T.Type) T.Id -> T

>>17
I use notepad. Enjoy your retarded colored assclown code.

>>17
What about command line?

>>16
See:
Since my complex human brain is capable of quickly understanding more than two special characters in addition to a base-10 numerical system and 26-letter alphabet, Python does not confuse me.
Why not program in binary machine code if natural language is so hideous?

>>21
Your jewish brain is fucked up and crazy, it should be healed with hydrogen cyanide.

python gracefully handles unintended dedents


if (foo) {
    bar()
    baz()
plugh_my_anus()
}
hax_my_anus()

if foo:
    bar()
    baz()
plugh_my_anus()
hax_my_anus()

python is perfect. forced indentation is infallible. BEND OVER FOR THE TROUSER SNAKE

>>21
Why not program in binary machine code if natural language is so hideous?
I do.

(=0
)=1

>>24
Those are ASCII chars, the 40th and 41st to be precise. If you were programming in binary you would have no need to ASCII.

>>25
You would still need some convention to input binary.

i program in anii
(_*_) unhaxed anus
(_o_) haxed anus

>>26
How about a 1-bit character set?

>>28
()?

"filter(P, S) is almost always written clearer as [x for x in S if P(x)]"

- Guido van Rossum on his faggoty cult

Is it true that Guido has jewish descent through mother?

>>14

excellent list of python cons.

i think triple quoting is a decent variant on a "here document", though.

about set comprehension syntax... in most small cases it seems, to me, to be quite readable and intuitive. but many people disagree. is there a language that handles this kind of thing better (but with nearly the same terseness?)

>>32
LIST-PROCESSING

>>32
1. Haskell
2. Lisp

Pick either.

>>32
1. Forced typing of lambda calculus
2. Forced parenthesization of EVERYTHING!!!

Any other language is even worse shit. Pick your poison.

http://img264.imageshack.us/img264/1397/lispnd7.png

Indenting is for PIG DISGUSTING Python programmers.

I write code like

[code]
for(i = 0; i < max1; i++) {
for(j = 0; j < max2; j++) {
for(k = 0; k < max3; k++) {
f(i,j,k);
}
}
}

Anyone who does otherwise is a [b][i][o][u]PIG DISGUSTING[/u][/o][/i][/b] Python programmer.

>>36
Still not readable.

>>38
It must suck to be that retarded.

>>30
Why does it matter what Guido prefers? filter, map and friends are still there if you want them. I prefer the Python approach anyway because it produces a generator (which the square brackets convert to a list). I typically prefer the Pythonic way. Consider:


class Vector(tuple):
 
  def __add__(self, other):
    if isinstance(other, Vector) and self.dim() == other.dim():
      # python way
      return Vector(x + y for x, y in zip(self, other))
      # lambda way
      return Vector(map(lambda x, y: x + y, self, other))
    else:
      raise ValueError

  def __mul__(self, other):
    if isinstance(other, Vector):
      return self.dot(other)
    else:
      return self.scale(other)

    def scale(self, other):
      # python way
      return Vector(x * other for x in self)
      # lambda way
      return Vector(map(lambda x: x * other, self))

    def dot(self, other):
      if isinstance(other, Vector) and self.dim() == other.dim():
        # python way
        return sum(x * y for x, y in zip(self, other))
        # lambda way
        return sum(map(lambda x, y: x * y, self, other))
      else:
        raise ValueError

    def dim(self):
      return len(self)

The generators are easier to understand, IMO, and almost always faster. You can write generators in Lisp, but not nearly as elegantly as you can in Python.

>>40
not using SIMD for vector operations
ISHYGDDT

>>39
It must suck to be that autistic. If you mentally set yourself to ignore the parentheses, then you must remember the arity of every function you use (which will of course fail for variadic functions). Lisp simply does not provide the visual cues that almost every other language provides. I'll agree with you everyday that Lisp has beautiful semantics, but it's the worst piece of shit when it comes to syntax.

>>42
Lisp is too deep for you. You are like a kid, who havent learned to read, he looks in the book and sees only dirty pages.

welcome to Python, where zip doesn't take a lambda.

>>42

surely a function should either have obvious parameters and/or should take named parameters. this is doable in lisp, javascript, python, etc

showing function arity/parameter info seems more like an ide feature than a language one.

>>40
1) that's hideous
2) I don't understand the python shit. I understand lambda calculus. It's not some Python-specific bullshit. It's pure and beautiful.
3) in Lisp it would be prettier. For instance, (apply + (map * self other)). Since everything is a function, you don't need to spell out simple lambdas all the time and come up with tons of bullshit temp variable names like "x" and "y" nearly as much. (although a fold would be more efficient anyway)
4) god that's some bullshit. In Lisp you just use lists of numbers for vectors. None of this prancing around like a faggot with some bullshit "object model"

>>42
so parentheses act as a hint as to the arity, but most functions have extremely well understood arities. You know exactly how many subexpressions a let form is going to have, for instance.

>>47
"let" is alright. A "cpnd" nested four special forms in, I don't think so.

>>48
fuck I meant cond. it's really early in the morning :/

>>46
In Lisp:

(let ((M (list (list 1 2) (list 3 4))
      (v (list 5 6)))
     (multiply-matrix-by-vector M (multiply-vector-by-number v -1))

In Python:
M = Matrix([[1, 2], [3, 4]])
v = Vector([5, 6])
M * -v

Lisp is clearly the autist's choice.

But hey, look, you can code like a aspie in Python too.

M = [[1, 2], [3, 4]]
v = [5, 6]
multiply_matrix_by_vector(M, multiply_vector_by_number(v, -1))

In Lisp, you're stuck doing things a certain way so you convince yourself it's the correct way. If it were the correct way, we wouldn't have stopped doing it 50 years ago.

>>50
Nice try kid, but in about any Lisp today you can have generic functions. But of course you probably don't even know the term, because it has never been uttered by Guido. Enjoy your cult. And by that, I mean Guido's dick.

FORCE THE INDENTATION OF MY ANUS

>>50

there are levels and levels that you don't understand, son.
In Lisp you don't even write that function. It's obviously too similar to another function in your program.

lrn2abstract oh wait Python doesn't let you

>>53
You don't know what the fuck you're talking about. Have you even heard the word abstraction before starting the first chapter of SICP that you never finished? Just because I like Python better than Lisp doesn't mean I don't know Lisp better than you. Come talk to me when you pass CS III, kid.

Ooh I have an idea. What if we made the lisp autist and the anti-GC autist fight together?

python faggots should check out haskell's FOIC and STFU

>>50
calling list on a list of numbers instead of quoting
let binding things that are only referenced once
not using generic methods
no imperative AIDS explicit return statement in the Python code

OK.

>>57
let binding things that are only referenced once
Have you ever heard of ``readability?''

You must be a Lisper.

>>50,57-58(and others)
Stupid trolls.  Fact remains, Lisp is the ideal AST (the semantics are perfect) but it's a shitty language to directly write in because of the lack of visual fucking cues.

I just learned how to use the spoiler tag, and now I'm shitposting on pork!

>>58
ever heard of "designing your whitespace in custom ways to fit the readability of the problem at hand?"

You must be a Pythonfaggot.

>>58,61
You must both be morons.

can someone explain the explicit usage of self in Python?

Why can't it use this instead?

>>63
why can't it use closed over variables?

>>64
Because that would be unpythonic and ultimately convenient.

>>63
It can. It's merely social convention and Pythonic to use self.

>>64
because LOL CLOSURES just use classes, ``faggot''

>>67
no thanks. I'll just use a real high level language, like Lua.

>>67
What's the syntax for defining classes inline agaihbt

>>64
self comes from Smalltalk I believe, which was the first or one of the first object-oriented languages. Either way, it's not a keyword. You can call it ``dicks'' if you want to.

How Lua solves self redundancy:

-- before
function Person.setName(self, name)
  self.name = name
end

-- after
function Person:setName(name)
  self.name = name
end

I love how everyone is concerned with the totally trivial issue of the name of 'self' in >>64, but hardly a word about closures.

>>71
>set
imperative AIDS. Lua has object literals. You generally just write

Person{name = "Retarded JavaKid"}

>>71
setName
I hate you, your naming convention and everything it stands for.

>>72
Python has closures.

Happy?

>>75
pre-3.0, lol arrays of 1 thing. post-3.0, lolnonlocal
anonymous functions are limited to 1 expression

having a feature is the same as making it worth it to use the feature. Python doesn't have closures.

>>75
And Haskell has "REPL".

>>73,74
real men implement properties

>>78
real men use a design pattern rather than straightforward dynamically typed hash tables.

all my rage

>>79
some people like to implement x.x_absolute as a function returning self.x + self.parent.x_absolute, ``faggot''