Isn't the point of a list comprehension - comprehension?
(It's a paraphrase of something Feynman once said to Murray Gell-Mann.)
Nastiest Python list comprehension ever
21–30 of 55 posts
Re: Nastiest Python list comprehension ever
#22Can somebody from the Perl community please but this guy in the right place by supplying a one-liner Perl golf quadruple map call?
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]
And this is before we get into the fact that the minutia of syntax and layout is only a minor factor in the maintainability of large projects.
Re: Nastiest Python list comprehension ever
#23Earlier 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…
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.
Re: Nastiest Python list comprehension ever
#24Corrected version:
def mystery(n):
a = list(range(n))
return [[i for a[::i] in [([0]*n)[::i]]][0] for
i in a[2:] if a[i]]Re: Nastiest Python list comprehension ever
#25Earlier quoted context omitted.
You mean like this implementation of the Sieve of Eratosthenes? sub sieve3 { grep{@_[map$a*$_,$_..@_/($a=$_)]=0if$_[$_]>1}@_=0..pop } I shamelessly stole that from http://www.perlmonks.org/index.pl/?node_id=81769 . If you just want a short solution, but don't care about the algorithm, then the following works: sub sieve { sub p{$_[0],@_>1?p(grep$_%$_[0],@_):1}p 2..pop } See http://www.perlmonks.org/index.pl/?node_id=…
Wow... and I was happy with: sub mystery{for($t=3;$t*$t (Based on http://www.c2.com/cgi/wiki?SieveOfEratosthenesInManyProgramm... but with a fun push alternative and in function form)
Any time you see a three arg for loop in perl golf, it's probably Doing It Wrong.
Re: Nastiest Python list comprehension ever
#26Earlier 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…
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.
Re: Nastiest Python list comprehension ever
#27Earlier quoted context omitted.
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…
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 still working solution is to use os.popen. That is cleaner for this common use case, but I chose to stick to the the officially recommended solution instead.
Eventually the Python folks realized that the blessed One True Way to do it was actually pretty horrible, and so they added subprocess.check_output in 2.7.
Re: Nastiest Python list comprehension ever
#28Earlier 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…
You can pass shell=True if you want it too:
subprocess.check_output("ls -al", shell=True)
Note the possible resulting security vulnerabilities.
Re: Nastiest Python list comprehension ever
#29Earlier quoted context omitted.
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…
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 people who think that Python magic pixie dust automatically makes for good code are actually more likely to write bad code. (Because they have not thought deeply enough about what makes code good.)
Re: Nastiest Python list comprehension ever
#30Wow. I hadn't realized that syntax like "for a[::i] in" is valid Python. Attribute assignment (for x.foo in) seem to work too. I'm not sure if there will ever be any reason to use those in real code, but it's nice trivia to know for Python golfing.