31–40 of 55 posts
This is why moving away from higher order functions and towards list comprehensions is a mistake. Bad BDFL, bad!
Readability requires that the programmer conspires with both the language and the reader. Unreadable code can be written in any style, any paradigm and any language. Sometimes it doesn't even take effort, talent or skill.
> Does anyone have a suggestion on how to do it? Yes, provide more details so I don't have to spend twenty minutes figuring out what it does. (Going by my three-second-look gut feeling: It's the Sieve of Eratosthenes)
Looking at it a bit more, it's sort-of-obvious that that's what it is, if you've seen the Sieve before. However: > i for a[::i] in Mind blown. How does assigning to an array even work? I'm guessing this is way-undefined-speak for setting elements, and I am simultaneously dazzled by its brilliance and horrified by its stupidity.
Earlier quoted context omitted.
shells were specifically made to operate with external programs (the Unix way) while Python is a more general programming language, so naturally it will be more verbose for this kind of task. Of course the first syntax breaks when one of the arguments has a space or any other meta-character in it.
I'm fully aware of the reasons why things are as they are, and what the limitations of the different solutions are. My point still stands though, just because something is Python, written in the One True Way, does not guarantee readability. To be absolutely clear, I actually like Python. I just strongly disagree with the belief that Python magically ensures readability. Particularly because my impression is that peop…
Earlier quoted context omitted.
Python still has (even in 3.2) os.system, which is the equivalent of the backticks from perl/shell. The subprocess module is preferred because you have more control and options than simply deferring to the C library's system() call.
Python still has (even in 3.2) os.system, which is the equivalent of the backticks from perl/shell. Sorry, but you're wrong. The os.system call is the equivalent of Perl's system call. It runs an external command and gives you a return code, but does not give you the text generated by said system call. The officially recommended (as of Python 2.6) way to get said text is what I wrote. The deprecated but possibly stil…
os.popen() is still available in python3, and uses subprocess.Popen() internally.
bps = [map(int, bps.split('/')) if isinstance(bps, str) else bps for bps in bps if bps]
The clause "else bps for bps in bps if bps" made me incredibly incredibly happy.
Earlier quoted context omitted.
Looking at it a bit more, it's sort-of-obvious that that's what it is, if you've seen the Sieve before. However: > i for a[::i] in Mind blown. How does assigning to an array even work? I'm guessing this is way-undefined-speak for setting elements, and I am simultaneously dazzled by its brilliance and horrified by its stupidity.
yeah, i figured out what it did by playing in the repl, but i still can't find it documented anywhere.
Earlier quoted context omitted.
Good point. "Least readable Python code" is a distinction similar to "smallest market cap on the Fortune 50" or "fattest Olympic decathlete."
I disbelieve. Which would you prefer to read to get the output of a system call? `your system call and args` subprocess.Popen(['your', 'system', 'call', 'and', 'args'], stdout=subprocess.PIPE).communicate()[0] The former is the traditional syntax supported in various shells, Perl, and Ruby. The latter is what you need if you want your code to run in Python 2.6. And this is before we get into the fact that the minutia…
Earlier quoted context omitted.
yeah, i figured out what it did by playing in the repl, but i still can't find it documented anywhere.
I tried a bit in the REPL and couldn't replicate it completely, but I didn't try hard. It seems to only work because of the CPython internals, so it seems to be implementation-specific and undocumented.
Python 2.5.2 (79560, Nov 26 2010, 14:57:55)
[PyPy 1.4.0] on win32
>>> a = [1, 2 ,3]
>>> for a[:] in [[6, 7, 8]]:
... pass
>>> print(a)
[6, 7, 8]Earlier quoted context omitted.
I'm fully aware of the reasons why things are as they are, and what the limitations of the different solutions are. My point still stands though, just because something is Python, written in the One True Way, does not guarantee readability. To be absolutely clear, I actually like Python. I just strongly disagree with the belief that Python magically ensures readability. Particularly because my impression is that peop…
Of course Python doesn't automatically ensure good code. But the Python code in your example is readable -- pretty match as readable as it gets, considering the constraints I mentioned.
Therefore I can't agree that the Python that I presented is as good as is possible for a general purpose programming language.