Python for Perl programmers • Hacker News Board

Re: Python for Perl programmers

#21

Post by shanemhansen » Tue, Apr 03, 2012, 7:19 PM UTC

tocomment wrote: post #4

Can someone please make a Perl for Python programmers? It actually took me 30 minutes today to figure out how to do: text=open('file.txt').read() without creating 3-5 lines of code which seems excessive for a simple operation. There are apparently 20 ways to do it in Perl and they need their own CPAN library for it :-( [1] [1] http://search.cpan.org/~drolsky/File-Slurp-9999.13/extras/sl...

This is actually really simple in perl. The idiomatic way to do it would be:

  open(my $fh, ";

lines is now an array of lines, you can join them into a single string if you want.

Re: Python for Perl programmers

#22

Post by alexis-d » Tue, Apr 03, 2012, 7:35 PM UTC

js2 wrote: post #12

Python people tend to always compile their regular expressions; I guess they aren't used to writing throw-away scripts like in Perl This is so that the RE isn't compiled each time it's used. These days the RE module maintains an internal cache for compiled RE's, but that wasn't always the case. The 1.5.2 docs for compile() say "using compile() is more efficient when the expression will be used several times in a sing…

> RE patterns can be horribly ugly

It worth to be noted that the verbose flag (re.X or re.VERBOSE in Python) may help to get more readable/friendly regexes (by allowing whitespace and comments).

Re: Python for Perl programmers

#23

Post by crb » Tue, Apr 03, 2012, 7:55 PM UTC

Here is a good "cheat sheet" for how to do X in Y (where X and Y are in PHP, Perl, Python or Ruby): http://hyperpolyglot.org/scripting

It doesn't cover idioms like Tom's post, but helps me remember the basic syntax changes when jumping between these languages.

Re: Python for Perl programmers

#24

Post by mapgrep » Tue, Apr 03, 2012, 8:38 PM UTC

shanemhansen wrote: post #21

tocomment wrote: post #4

Can someone please make a Perl for Python programmers? It actually took me 30 minutes today to figure out how to do: text=open('file.txt').read() without creating 3-5 lines of code which seems excessive for a simple operation. There are apparently 20 ways to do it in Perl and they need their own CPAN library for it :-( [1] [1] http://search.cpan.org/~drolsky/File-Slurp-9999.13/extras/sl...

This is actually really simple in perl. The idiomatic way to do it would be: open(my $fh, " ; lines is now an array of lines, you can join them into a single string if you want.

Slightly more idiomatic would be with a useful die (and a semicolon terminating the first line):

  open(my $fh, ";

To slurp into a string rather than an array of lines:

  open(my $fh, ");

Re: Python for Perl programmers

#25

Post by mst » Tue, Apr 03, 2012, 8:52 PM UTC

tantalor wrote: post #3

Not mentioned is the common idiom of assigning regexp matches. In perl, > my ($a, $b) = '12' =~ /(\d)(\d)/; In python, > (a, b) = re.match('(\d)(\d)', '12').groups() Note the python code here will throw an AttributeError if the match fails, whereas the perl will just assign undef to the variables.

Actually, perl will return an empty list, which if then evaluated in scalar context will return 0, which is boolean false. So

  if (my ($x, $y) = '12' =~ /(\d)(\d)/) {
    
  }

is the normal idiom.

Re: Python for Perl programmers

#26

Post by mst » Tue, Apr 03, 2012, 8:56 PM UTC

bgilroy26 wrote: post #11

tocomment wrote: post #4

Can someone please make a Perl for Python programmers? It actually took me 30 minutes today to figure out how to do: text=open('file.txt').read() without creating 3-5 lines of code which seems excessive for a simple operation. There are apparently 20 ways to do it in Perl and they need their own CPAN library for it :-( [1] [1] http://search.cpan.org/~drolsky/File-Slurp-9999.13/extras/sl...

CPAN's ecosystem of packages are not really like Python's Libraries. There are packages for very small jobs such as doing IO or processing command line options (getopts) as well as packages that serve as whole ORMs or web frameworks, so it's considered easy to import File::Slurp even if you've never used it before, whereas it seems like the idea of using a library on the scale of Scipy for something like that would b…

Right. When looking at the core language, "There Is More Than One Way To Do It" becomes "More than one thing will compile to the same VM opcodes, so you can choose the one that best expresses your intent to the maintenance programmer."

When looking at libraries, "There Is More Than One Way To Do It" becomes "More than one library will solve your problem and you're welcome to select the one that makes the speed/size/complexity/feature trade-offs that best fit the project at hand."

This is, absolutely, initially more confusing than "there should be one obvious way to do it", but it has other advantages, especially in the long run.

Re: Python for Perl programmers

#27

Post by ajross » Tue, Apr 03, 2012, 9:08 PM UTC

js2 wrote: post #12

Python people tend to always compile their regular expressions; I guess they aren't used to writing throw-away scripts like in Perl This is so that the RE isn't compiled each time it's used. These days the RE module maintains an internal cache for compiled RE's, but that wasn't always the case. The 1.5.2 docs for compile() say "using compile() is more efficient when the expression will be used several times in a sing…

The point being, though, that perl regexes are compiled at parse time, with no extra syntax hanging around.

And no, I simply have to disagree that a separate object instantiation is "more readable" than the straightforward syntax describing the object itself. That this argument should appear in a discussion of a dynamically bound scripting language shows as well as anything why the python community is eating itself. A LISP or Ruby nut would never have made that claim.

The point to having code there is to read it. Hiding it doesn't make it more readable, it just fools you into thinking you understand it better than you do. You probably call your regexes stuff like "split_at_word_boundaries", right? And how many bugs have you had to deal with because the whitespace conventions aren't clear from your source?

Re: Python for Perl programmers

#28

Post by ajross » Tue, Apr 03, 2012, 9:09 PM UTC

jeremya wrote: post #9

However, most Python programmers tend to just read the entire file into one huge string and process it that way. I feel funny doing that. Having used machines with very limited amounts of RAM, I tend to try to keep my file processing to a single line at a time. However, that method is going the way of the dodo. contents = file('filename.txt').read() all_input = sys.stdin.read() This is not the correct way to do thing…

No doubt. It must be noted, though, that for a very-well-thought-of, modern language: python has a staggeringly large number of "incorrect" ways to do things.

Re: Python for Perl programmers

#29

Post by ajross » Tue, Apr 03, 2012, 9:12 PM UTC

shanemhansen wrote: post #21

tocomment wrote: post #4

Can someone please make a Perl for Python programmers? It actually took me 30 minutes today to figure out how to do: text=open('file.txt').read() without creating 3-5 lines of code which seems excessive for a simple operation. There are apparently 20 ways to do it in Perl and they need their own CPAN library for it :-( [1] [1] http://search.cpan.org/~drolsky/File-Slurp-9999.13/extras/sl...

This is actually really simple in perl. The idiomatic way to do it would be: open(my $fh, " ; lines is now an array of lines, you can join them into a single string if you want.

Or just:

  my $data = `cat $file`;

Some folks dislike the useful use of cat, but anyone who's ever read a shell script will recognize the idiom. And it's a trivial one-liner much simpler still than the python code .

Re: Python for Perl programmers

#30

Post by eblume » Tue, Apr 03, 2012, 9:17 PM UTC

jeremya wrote: post #9

However, most Python programmers tend to just read the entire file into one huge string and process it that way. I feel funny doing that. Having used machines with very limited amounts of RAM, I tend to try to keep my file processing to a single line at a time. However, that method is going the way of the dodo. contents = file('filename.txt').read() all_input = sys.stdin.read() This is not the correct way to do thing…

Though the results may have changed since, I once had to parse a very, very large file (about 5 GB) line-by-line. I tested a number of different methods, and ultimately discovered that reading the entire file using .readlines() was faster by a significant margin. I vaguely recall it was more than four times faster, actually - and that was a really big win when you're talking about a data set that large.

Granted, our machine had a perhaps-unusual design in that it had multiple RAID 6 data banks, a very powerful dedicated IO controller, and about 128 GB of RAM. So your mileage may vary.

Unfortunately I don't have access to that machine any more so I can't perform the same benchmark, but I have a nagging feeling that if I ran the tests again with Python 3.2 I'd get different results.