5 ms·

It's succint, all right (well, sort of). But Python's major strength is readability, even more than coinciseness, or better, to provide both at the same time.

• ajross 14y ago
  I call shenanigans. That's true of simple scripts, I'm sure. But you can't seriously claim to me that you can understand decorator idioms, iterables or list comprehensions without a deep understanding of the language. What you say might have been true for Python c. 1998, it certainly isn't true today. Broadly: reading code is just hard. It's much harder than writing code. There are no non-trivial codebases that can be considered "easy to read" (if you think there are, then you're fooling yourself), and the choice of language makes only mild difference. (edit: I'm amused at the multiple people who had to jump in to explain "decorators aren't hard!" instead of responding to my core point. First, I know what a decorator is. Second, no one who isn't a reasonably proficient python programmer is going to have any clue what @classmethod does or why all the old code doesn't break without using it. It's non-standard, language-specific syntax in exactly the same way that an STL iterator is, and the only reason you think one is easy and not the other is because you know Python and not C++.)
  • TazeTSchnitzel 14y ago
    Decorators aren't difficult to understand. It tells you that the function is modified in some way. Iterables and list comprehensions are also easy to read, and I do not have a deep understanding of Python at all.
    • Symmetry 14y ago
      Right. I saw my first decorator before I knew what one was, and just from looking at it I knew enough to ask my friend "This thing looks like it's modifying the function somehow, what is it?".
  • Kurtz79 14y ago
    That is a given, I agree. But a complex program written in C++ (or using advanced C++ constructs) will scale much worse than a Python one, in my opinion.
    • netmare 14y ago
      I don't think that's necessarily true. In my opinion, both languages can be used by novices for simple scripts and by experts for complicated tasks. However, C++ seems to be getting easier for simple tasks (lambdas, initializers, auto, alias templates, etc.), while Python is getting more complex/powerful (metaclasses, exception tweaks, new I/O and function annotations — just to name a few).
    • halfcat 14y ago
      My experience has been the opposite in some cases, mainly due to C++ being statically typed, and having fewer implicit happenings. Yesterday I spent a chunk of my day debugging why my Python script reported that zero computers on the network were using DHCP. Apparently the Win32_NetworkAdapterConfiguration property DHCPEnabled returns 'True' or 'False' in Python (those are strings, not bools). In C++ that's a compile time error. The Microsoft documentation says DHCPEnabled is a bool. So between implicit functionality (evaluating strings as bools) and dynamic typing, this isn't screaming scalability to me. Yes, this is just one example, but it points to a whole class of errors that are lurking out there in production code. My guess would be, a complex C++ program written in the Lakos style would be more scalable than the equivalent Python program.
    • Evbn 14y ago
      RuntimeError: cannot add String and Integer
  • deleted 14y ago
    [deleted]
  • pcote 14y ago
    List comprehensions are not deep magic. If you use SQL as your frame of reference, it's actually pretty easy to pick up. They also add a hell of a lot to readability once you know what it does.
    • ajross 14y ago
      Your critical phrase phrase being "... once you know what it does.". I didn't say it was hard, I said it required learning and experience to use. The OP claimed that non-expert python programmers could read it without that experience. The same is true for virtually all of C++ too.
  • undershirt 14y ago
    Here's an example: A co-worker looked at a function I wrote that converts a table to a tree, and he said to me, "I thought Python was supposed to be readable, but I have no idea what this is doing." See for yourself: https://gist.github.com/3988350 https://gist.github.com/3988350
    • mattdeboard 14y ago
      I agree with your co-worker. The indirection is kind of annoying to follow to be completely honest, so if your co-worker isn't proficient in Python I can understand how this would seem impossible to sort out.
    • Peaker 14y ago
      Manually capturing free variables via: def __init__(self, x, y, ..): self.x = x self.y = y Is so tedious and DRY-violating.
      • lmm 14y ago
        This is true. I'd prefer scala-style constructor syntax - though I'm not sure how you could retain python's wonderful symmetry between constructors and methods, and the distinction between allocation and initialization.
        • Peaker 14y ago
          I don't know Scala, but the Erights language does something like (pseudo-syntax): def Circle(center, radius): circumference = 2 * pi * radius return object: to getCircumference(): return circumference to ... The "self" is the lexical scope. Simple and more effective than Python's method, IMO.
  • bugsbunnyak 14y ago
    Absolutely agreed: to me, Python is a local maximum rather early on the readability vs. complexity graph. I think as complexity increases, an explicitly-typed language becomes much more understandable because local type annotations require less context switching to reason about when compared to an implicit language.
  • snowfarthing 14y ago
    Ironically, I didn't understand Python's list comprehensions until I learned about Haskell's version (which is the original source of Python's), along with the explanation that Haskell's list comprehensions are taken straight from mathematics. Indeed, Haskell's version are almost ASCII-art mathematical set notations. Even now, I still like Haskell's [fn(x) | x <- myList, x < 5] over Python's equivalent [fn(x) for x in myList if x < 5] Of course, I'm a mathematician, so that probably explains everything about my convoluted path of understanding these things, and my preferences to this day. :-)
  • lmm 14y ago
    List comprehensions read like what they are (except for the stupid backwards order if you have multiple 'for's). Decorators are pretty opaque; idiomatic python makes minimal use of them, and uses them only for things that don't change the meaning of the method inside. I've never used @classmethod and hope to never have to. I don't think it's fair to compare to an STL iterator, which is something you're encouraged to use as much as possible. I don't know what you're talking about for iterables; aren't they obvious?
    • ajross 14y ago
      The iterable point was that the syntax is obvious but the behavior is not. They "look like plain data" sometimes, and some times they don't; and the only way to tell the difference is to know the characteristics of what you are iterating over. They're the same kind of too-clever-by-half design that C++ tends to confuse people with. People who know it love it, and people who don't think it's voodoo.
• reddit_clone 14y ago
  That is a strawman requirement. It is sufficient if the C++ code I write is reasonably readable to a fellow C++ programmer. I really don't care if it is not readable to a casual observer. It is nice that Python code is readable to even to non python people. But it is not a requirement for every language.
• redcircle 14y ago
  Python, like all dynamically typed languages, has no readability once you start using multiple modules. Static types are important for declaring interfaces between components. I have pretty much written off Python, particularly now that Go exists. I've wasted too many hours tracing down data types in complicated Python programs, usually resorting to printing out the types at runtime to decode them. The problem with Python: it is great for simple programs, where the effort to writing the simple program is much less than the comparable program in C/C++/Java; but simple programs often grow into complicated programs, and then the effort of maintaining Python far exceeds the effort to maintain C/C++/Java. Go, on the other hand, is pretty nice for writing a simple program, and can then scale into a complicated program.