Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python for Perl programmers

everythingsysadmin.com

Post reply on HN
Print view View original

31–40 of 40 posts

Re: Python for Perl programmers

#31

Post by ajross »

alexis-d wrote: post #22
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).

I'm desperately fighting the urge to snark: but another very effective treatment for dealing with unreadable regex syntax is to learn regex syntax. In my experience probably 90% of people who complain about regular expressions simply don't know them very well.

It's a declarative language without symbols or recursion: that means that it's just not well-suited to being "broken down and simplified". You just have to bite the bullet and learn it. With a little practice, the basic features (e.g. beginning/end of line markers, character classes and captures, maybe non-capturing parentheses too) should be readable without trouble.

Re: Python for Perl programmers

#32

Post by pdehaan »

ajross wrote: post #29
shanemhansen wrote: post #21

Earlier quoted context omitted.

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 .

This isn't exactly idiomatic Perl and fails completely in environments that don't have cat (Windows).

For one-time uses there's not a problem. However, if you find yourself writing what amount to shell scripts in Perl, you might be better off just writing shell scripts.

Re: Python for Perl programmers

#33

Post by ajross »

pdehaan wrote: post #32
ajross wrote: post #29

Earlier quoted context omitted.

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 .

This isn't exactly idiomatic Perl and fails completely in environments that don't have cat (Windows). For one-time uses there's not a problem. However, if you find yourself writing what amount to shell scripts in Perl, you might be better off just writing shell scripts.

Excuse me? Who are you to determine what is and isn't "idiomatic"? And that you would try this kind of thing about perl of all languages is just shocking. What's saddest is that it's the lack of this kind of absurdist pursuit of robustness and purity is one of the things that has always best defined the perl community.

Broadly, your argument seems to be that spawning processes in the external environment[1] (which, admittedly, is inherently nonportable) is a Bad Thing in perl, and that we shouldn't do it. When I rephrase it like that, does it sound as poo-flinging crazy to you as it does to me?

[1] Let's be honest: a working "cat" is pretty much the single most portable thing you can put between the backticks. If you won't allow this, what will you permit?

Re: Python for Perl programmers

#34

Post by alexis-d »

ajross wrote: post #31
alexis-d wrote: post #22

Earlier quoted context omitted.

> 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).

I'm desperately fighting the urge to snark: but another very effective treatment for dealing with unreadable regex syntax is to learn regex syntax . In my experience probably 90% of people who complain about regular expressions simply don't know them very well. It's a declarative language without symbols or recursion: that means that it's just not well-suited to being "broken down and simplified". You just have to bi…

I think you missed my point.

I agree that for trivial regex it's useless. For instance (directly taken from Python doc) in this case:

  a = re.compile(r"""\d +  # the integral part
                     \.    # the decimal point
                     \d *  # some fractional digits""", re.X)
  b = re.compile(r"\d+\.\d*")
that's useless. But for more complex problems it may be useful (e.g. http://www.doughellmann.com/PyMOTW/re/ I know email matching regexes are not really complex or even a good example of use of regexes but that's the first example I found).

Another point is that even if I can read/write (that's the case) regexes other people may have to deal with my code and it's a well known fact that many people doesn't understand/like regex, so splitting them in small "chunks" may help them.

Re: Python for Perl programmers

#35

Post by ajross »

alexis-d wrote: post #34
ajross wrote: post #31

Earlier quoted context omitted.

I'm desperately fighting the urge to snark: but another very effective treatment for dealing with unreadable regex syntax is to learn regex syntax . In my experience probably 90% of people who complain about regular expressions simply don't know them very well. It's a declarative language without symbols or recursion: that means that it's just not well-suited to being "broken down and simplified". You just have to bi…

I think you missed my point. I agree that for trivial regex it's useless. For instance (directly taken from Python doc) in this case: a = re.compile(r"""\d + # the integral part \. # the decimal point \d * # some fractional digits""", re.X) b = re.compile(r"\d+\.\d*") that's useless. But for more complex problems it may be useful (e.g. http://www.doughellmann.com/PyMOTW/re/ I know email matching regexes are not reall…

To be fair: my argument wasn't against the use of the /x suffix to a regex. I'm sure that there are circumstances in the wild (though quite honestly I can't recall seeing any in production code, and I've written and read a truckload of regexes over the years) where it's used productively to document a really hairy expression.

I'm just saying that 90% of the time when users complain about not being able to read a regex, the solution should be "hit the books" not "rewrite the expression".

Re: Python for Perl programmers

#36

Post by celer »

ajross wrote: post #28
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.

Python has a design ethic that most other languages don't have. There are very few, if any, good synonyms for 'Pythonic.'

Re: Python for Perl programmers

#37

Post by pdehaan »

ajross wrote: post #33
pdehaan wrote: post #32

Earlier quoted context omitted.

This isn't exactly idiomatic Perl and fails completely in environments that don't have cat (Windows). For one-time uses there's not a problem. However, if you find yourself writing what amount to shell scripts in Perl, you might be better off just writing shell scripts.

Excuse me? Who are you to determine what is and isn't "idiomatic"? And that you would try this kind of thing about perl of all languages is just shocking. What's saddest is that it's the lack of this kind of absurdist pursuit of robustness and purity is one of the things that has always best defined the perl community. Broadly, your argument seems to be that spawning processes in the external environment[1] (which, a…

First off, apologies if I was coming off as rude, I wasn't trying to be.

My point was more that slurping a file without spawning another process is already quite easy in perl. That method of slurping contradicts common patterns like "while ()". I'm not saying it's strictly wrong or even bad, just not necassarily the best option.

Re: Python for Perl programmers

#38

Post by kamaal »

Sorry can't use Python instead of Perl. Basically because Python is not Perl.

Now if you want to just change a language for the sake of changing it, its Ok. But Python and Perl have opposite philosophies. And the actual problem while changing from Python to Perl occurs there.

To me Python looked like Java with a haircut and french beard. That fact simply keeps hovering over me, even in this tutorial all those variable = something.somethingElse.someMethod() thing gives a strong Java vibe .When I used it for the first time, It looked like a language for people who were frustrated with Java but at the same couldn't learn Perl either. It looked like a language designed for such people.

Parsing a program visually hurts my eyes. Especially for large code blocks. Inability to provide easy ways of writing throwaway command line hacks is just not acceptable at all on Unix machine. That's precisely where Perl won over sysadmins during its early days.

Having to bury each statement you suspect under piles of try/catch statements doesn't feel like a scripting language. No multi line lambdas is a major turn off.

Regular expression support looks totally alien and its no way closer to Perl's way $line =~ // and not just that, Matching is just one part. Extraction, substitution et all all part of regular expression operations. Now regexes combined with map/grep functions make parsing a whole lot easier in Perl.

Scoping sucks big time in Python. There is nothing remotely comparable to CPAN.

I don't know which versions to Program in, 2.x or 3.x? There is nothing like Moose and other associated modern perl packages in Python.

Lastly I never needed another C based language for scripting. What I needed was a more extensible language(like Perl6).

Python doesn't serve my scripting needs on Unix. But I agree it has good web frameworks and it may be helpful there.

Re: Python for Perl programmers

#39

Post by lucian1900 »

eblume wrote: post #30
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…

That's most likely because of the overhead of all those syscalls for each line.

A nicer way to do such things is to open the file with mmap, which does one system call and then just bumps a pointer. mmaps expose both a file and a list-like API.

Re: Python for Perl programmers

#40

Post by [deleted] »

lucian1900 wrote: post #39
eblume wrote: post #30

Earlier quoted context omitted.

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…

That's most likely because of the overhead of all those syscalls for each line. A nicer way to do such things is to open the file with mmap, which does one system call and then just bumps a pointer. mmaps expose both a file and a list-like API.

[deleted]
Post reply on HN