RE: perl to python

Discussion in 'Python' started by Hornberger, Chris, May 12, 2004.

  1. First off, this isn't even remotely a slam, so I hope it's not taken as such.

    My question is this.

    Why bother with getting perl code translated into python code?

    Perl is probably one of the best string manipulation and RegEx processors ever.

    Python is probably one of the easist general purpose scripting languages ever.

    They don't have to overlap. With Python's pipe handling there's little reason not to simply leave the perl code where it is and run it from an orchestration script in Python.

    Perl is a pretty involved, terse and comprehensive wheel. Not sure I see the reasons to reinvent it. It's safe to say that a large majority of the people using perl are also working with it (writing in it).

    $.02

    *note - these are my observations from the environments I'm used to working in. your mileage may vary*

    --------------------------
    Chris Hornberger
    Blackrock - 302.797.2318


    Card carrying MSDN member since 2004.
    No, really. I've got the card to prove it.


    -----Original Message-----
    From: python-list-bounces+chris.hornberger=
    [mailto:python-list-bounces+chris.hornberger=]On
    Behalf Of Scott Schwartz
    Sent: Wednesday, May 12, 2004 3:08 PM
    To:
    Subject: Re: perl to python


    Duncan Booth <> writes:
    > import sys
    > for line in sys.stdin:
    > line = line[:-1].split('\t')
    > print "%s %s %s %s" % (line[3], line[2], line[1], line[0])


    > While I agree with you that using the appropriate tool is preferred over
    > using Python for everything, I don't really see much to choose between the
    > Python and awk versions here.


    1) Python throws an error if you have less than three fields,
    requiring more typing to get the same effect.

    2) Python generators on stdin behave strangely. For one thing,
    they're not properly line buffered, so you don't get any lines until
    eof. But then, eof is handled wrongly, and the loop doesn't exit.

    3) There is no efficient RS equivalent, in case you need to read
    paragraphs.

    The simpler example

    for line in sys.stdin:
    print line

    demonstrates the problem nicely.

    $ python z
    a
    b
    c
    ^D
    a

    b

    c

    foo
    bar
    baz
    ^D
    foo

    bar

    baz
    ^D
    ^D
    $

    Explanations in the docs about buffering and readahead don't excuse
    this poor result.

    $ awk '{print}'
    a
    a
    b
    b
    c
    c
    ^D
    $
    --
    http://mail.python.org/mailman/listinfo/python-list
     
    Hornberger, Chris, May 12, 2004
    #1
    1. Advertising

  2. Hornberger, Chris

    Ville Vainio Guest

    >>>>> "Chris" == Hornberger, Chris <> writes:

    Chris> Why bother with getting perl code translated into python
    Chris> code?

    Because Python code is more readable and maintainable. That is a huge
    win in multi-maintainer situations (which is typical in production
    code). You can also bump up the functionality of the script while
    porting, and get better reuse.

    Porting perl code to Python is always very easy. Perl doesn't really
    do anything that isn't as easy to express in Python.

    Chris> Perl is probably one of the best string manipulation and
    Chris> RegEx processors ever.

    Yes, and so is Python. There have been several requests of examples
    where Perl does a better job at string manipulation/regexp processing
    than Python, and none have been presented. Perl regexps might execute
    slightly faster, but that is hardly a winning argument.

    Chris> They don't have to overlap. With Python's pipe handling

    But they do. Perl and Python completely overlap, to the extent car
    ("horseless carriage") and a horsefull variant of the carriage
    overlap.

    Chris> there's little reason not to simply leave the perl code
    Chris> where it is and run it from an orchestration script in
    Chris> Python.

    If the perl script is "complete" already, with no need to implement
    extra functionality ever, that is probably ok. Then you can think of
    the code as almost an executable third party binary, and have no
    responsibilities or attachment regarding the source code.


    --
    Ville Vainio http://tinyurl.com/2prnb
     
    Ville Vainio, May 13, 2004
    #2
    1. Advertising

  3. On 13 May 2004 08:37:00 +0300,
    Ville Vainio <> wrote:

    > Because Python code is more readable and maintainable. That is a
    > huge win in multi-maintainer situations (which is typical in
    > production code) ...


    Agreed.

    > ... You can also bump up the functionality of the script while
    > porting, and get better reuse.


    That part makes me cringe.

    Port first. Make sure the new code still passes every *old* test
    you can find. Write new tests against the current functionality
    and the new code; porting inevitably leads to new corner cases and
    language idiosyncrasies.

    Bump the functionality later.

    If I'm the manager and I hear, "feature X, which wasn't even in
    the old code, is almost working; but featyre Y, which was in the
    old code, seems to be broken," then heads will roll.

    Obviously, e.g., porting an OS from one hardware platform to
    another (which I've done, more than once) will lead to
    functionality changes, but there had better not be any bumping
    until you know that the port is at least as solid as the original.

    Most of the time, though, it's the other way around: you find
    bugs in the old code due to the new scrutiny, but then you have
    the nasty problem of determining whether or not something else
    depends on the buggy behavior (but that's a better topic for a new
    thread on another newsgroup). At that point, bumping the
    functionality during the port could be extremely troublesome.

    Regards,
    Heather

    --
    Heather Coppersmith
    That's not right; that's not even wrong. -- Wolfgang Pauli
     
    Heather Coppersmith, May 13, 2004
    #3
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. dpackwood
    Replies:
    3
    Views:
    1,862
  2. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Jan 23, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    332
    PerlFAQ Server
    Jan 23, 2011
  3. PerlFAQ Server
    Replies:
    0
    Views:
    726
    PerlFAQ Server
    Feb 3, 2011
  4. PerlFAQ Server

    FAQ 1.4 What are Perl 4, Perl 5, or Perl 6?

    PerlFAQ Server, Feb 27, 2011, in forum: Perl Misc
    Replies:
    0
    Views:
    322
    PerlFAQ Server
    Feb 27, 2011
  5. PerlFAQ Server
    Replies:
    0
    Views:
    734
    PerlFAQ Server
    Apr 4, 2011
Loading...

Share This Page