Learning Python now coming from Perl

Discussion in 'Python' started by Bertilo Wennergren, Dec 6, 2008.

  1. I'm planning to start learning Python now, using Python 3000.
    I have no previous Python skills, but I now Perl pretty well.
    I'm also well experienced with JavaScript.

    Any pointers and tips how I should go about getting into
    Python?

    --
    Bertilo Wennergren <http://bertilow.com>
     
    Bertilo Wennergren, Dec 6, 2008
    #1
    1. Advertising

  2. Bertilo Wennergren

    Roy Smith Guest

    In article <ghdt15$6e7$>,
    Bertilo Wennergren <> wrote:

    > I'm planning to start learning Python now, using Python 3000.
    > I have no previous Python skills, but I now Perl pretty well.
    > I'm also well experienced with JavaScript.
    >
    > Any pointers and tips how I should go about getting into
    > Python?


    I assume you use Perl to solve real problems in whatever job you do. My
    recommendation would be the next time some problem comes up that you would
    normally solve with Perl, try doing it in Python. Having a real task that
    you need to accomplish is a great way to focus the mind. For your first
    project, pick something that's small enough that you think you could tackle
    it in under 50 lines of Perl.

    One of the very first things you'll probably discover that's different
    between Perl and Python is how they handle string pattern matching. In
    Perl, it's a built in part of the language syntax. In Python, you use the
    re module. The regular expressions themselves are the same, but the
    mechanism you use to apply them to input text is quite different.
     
    Roy Smith, Dec 6, 2008
    #2
    1. Advertising

  3. Roy Smith wrote:

    > Bertilo Wennergren <> wrote:


    >> I'm planning to start learning Python now, using Python 3000.
    >> I have no previous Python skills, but I now Perl pretty well.
    >> I'm also well experienced with JavaScript.
    >>
    >> Any pointers and tips how I should go about getting into
    >> Python?


    > I assume you use Perl to solve real problems in whatever job you do. My
    > recommendation would be the next time some problem comes up that you would
    > normally solve with Perl, try doing it in Python. Having a real task that
    > you need to accomplish is a great way to focus the mind. For your first
    > project, pick something that's small enough that you think you could tackle
    > it in under 50 lines of Perl.


    Good advice.

    > One of the very first things you'll probably discover that's different
    > between Perl and Python is how they handle string pattern matching. In
    > Perl, it's a built in part of the language syntax. In Python, you use the
    > re module. The regular expressions themselves are the same, but the
    > mechanism you use to apply them to input text is quite different.


    Thanks.

    I don't suppose there is any introductory material out there
    that is based on Python 3000 and that is also geared at people
    with a Perl background? Too early for that I guess..

    --
    Bertilo Wennergren <http://bertilow.com>
     
    Bertilo Wennergren, Dec 6, 2008
    #3
  4. Bertilo Wennergren wrote:
    > Roy Smith wrote:
    >
    >> Bertilo Wennergren <> wrote:

    >
    >>> I'm planning to start learning Python now, using Python 3000.
    >>> I have no previous Python skills, but I now Perl pretty well.
    >>> I'm also well experienced with JavaScript.
    >>>
    >>> Any pointers and tips how I should go about getting into
    >>> Python?

    >
    >> I assume you use Perl to solve real problems in whatever job you do.
    >> My recommendation would be the next time some problem comes up that
    >> you would normally solve with Perl, try doing it in Python. Having a
    >> real task that you need to accomplish is a great way to focus the
    >> mind. For your first project, pick something that's small enough that
    >> you think you could tackle it in under 50 lines of Perl.

    >
    > Good advice.
    >
    >> One of the very first things you'll probably discover that's different
    >> between Perl and Python is how they handle string pattern matching.
    >> In Perl, it's a built in part of the language syntax. In Python, you
    >> use the re module. The regular expressions themselves are the same,
    >> but the mechanism you use to apply them to input text is quite different.

    >
    > Thanks.
    >
    > I don't suppose there is any introductory material out there
    > that is based on Python 3000 and that is also geared at people
    > with a Perl background? Too early for that I guess..
    >


    This is from a post within the last few
    days: http://www.qtrac.eu/pyqtbook.html

    Colin W.
     
    Colin J. Williams, Dec 6, 2008
    #4
  5. On Sat, 06 Dec 2008 08:50:20 -0500, Roy Smith wrote:

    > For your first
    > project, pick something that's small enough that you think you could
    > tackle it in under 50 lines of Perl.


    Is there anything which *can't* be written in under 50 lines of Perl?

    :)


    > One of the very first things you'll probably discover that's different
    > between Perl and Python is how they handle string pattern matching. In
    > Perl, it's a built in part of the language syntax. In Python, you use
    > the re module. The regular expressions themselves are the same, but
    > the mechanism you use to apply them to input text is quite different.


    Also, Perl REs are faster than Python REs, or so I'm told. Between the
    speed and the convenience, Perl programmers tend to use RE's for
    everything they can. Python programmers tend to use REs only for problems
    that *should* be solved with REs rather than *can* be solved with a RE.

    Well, I say "tend", but in truth we get our fair share of questions like
    "Hi, how do I factorize a 20 digit number with a regular expression?"
    too.

    Probably the biggest difference is that in Python, you always refer to
    objects the same way, regardless of what sort of data they contain.
    Regardless of whether x is a scalar or a vector, you always call it just
    plain x.



    --
    Steven
     
    Steven D'Aprano, Dec 6, 2008
    #5
  6. Bertilo Wennergren

    Aahz Guest

    In article <ghe0jo$3i1$>,
    Bertilo Wennergren <> wrote:
    >
    >I don't suppose there is any introductory material out there that is
    >based on Python 3000 and that is also geared at people with a Perl
    >background? Too early for that I guess..


    Honestly, the differences between 2.x and 3.0 are small enough that it
    doesn't much matter, as long as you're not the kind of person who gets
    put off by little problems. Because so much material is for 2.x, you
    may be better off just learning 2.x first and then moving to 3.x.
    --
    Aahz () <*> http://www.pythoncraft.com/

    "It is easier to optimize correct code than to correct optimized code."
    --Bill Harlan
     
    Aahz, Dec 6, 2008
    #6
  7. Bertilo Wennergren

    News123 Guest

    I fully agree with Roy's answer.

    COding small tasks is a good starting point. For quite some time you'll
    be of course less efficient than with your previous language, but that's
    part of the learning curve, isn't it.

    I guess you'll learn the syntax rather quickly.
    What's more painful is to learn which functianilty is in which library
    and which library exists.

    There's of course a lot of online documentation, but often you find
    answers to trivial python questions fastest with Google:
    for example: search for something like "python string reverse example"

    And there's of course this newsgroup whenever you're stuck with a
    'missing' feature, (though mostly the features aren't missing, but just
    a little different)


    bye

    N


    Roy Smith wrote:
    > In article <ghdt15$6e7$>,
    > Bertilo Wennergren <> wrote:
    >
    >> I'm planning to start learning Python now, using Python 3000.
    >> I have no previous Python skills,
    >> . . .

    >
    > I assume you use Perl to solve real problems in whatever job you do. My
    > recommendation would be the next time some problem comes up that you would
    > normally solve with Perl, try doing it in Python. Having a real task that
    > you need to accomplish is a great way to focus the mind. For your first
    > project, pick something that's small enough that you think you could tackle
    > it in under 50 lines of Perl.
    >
    > One of the very first things you'll probably discover that's different
    > between Perl and Python is how they handle string pattern matching. In
    > Perl, it's a built in part of the language syntax. In Python, you use the
    > re module. The regular expressions themselves are the same, but the
    > mechanism you use to apply them to input text is quite different.
     
    News123, Dec 6, 2008
    #7
  8. Bertilo Wennergren

    Roy Smith Guest

    In article <ghecgk$81m$>, (Aahz)
    wrote:

    > In article <ghe0jo$3i1$>,
    > Bertilo Wennergren <> wrote:
    > >
    > >I don't suppose there is any introductory material out there that is
    > >based on Python 3000 and that is also geared at people with a Perl
    > >background? Too early for that I guess..

    >
    > Honestly, the differences between 2.x and 3.0 are small enough that it
    > doesn't much matter, as long as you're not the kind of person who gets
    > put off by little problems. Because so much material is for 2.x, you
    > may be better off just learning 2.x first and then moving to 3.x.


    I'm not sure I agree. If you're starting out, you might as well learn the
    new stuff. Then there's no need to unlearn the old way.

    Using material meant for 2.x is likely to lead to confusion. If you don't
    know either, you'll never know if something isn't working as described
    because you're doing it wrong or if it's just not the same as it used to
    be. When everything is new, what seem like little stumbling blocks to
    experts become total blockers to people starting from zero.
     
    Roy Smith, Dec 6, 2008
    #8
  9. News123 wrote:
    >
    > What's more painful is to learn which functianilty is in which library
    > and which library exists.
    >

    <cut>
    Yes and one mistake I still often find myself doing is, when confronted
    with a particular problem, that I write some helper code to deal with
    it. Of course later on I discover that there is a standard module or
    built-in that does exactly what I want and better. :)

    Somehow in the heat of the moment my mind is not thinking 'there must be
    something out there which does what I want' but rather 'hmmm I think I
    can do it this way, clicker-di-click'.

    In my opinion it is a positive attribute to the language that it makes
    solving problems so easy that you forget about searching for solutions.
    Maybe python should prompt every 10 lines of code a message saying 'Are
    you sure this can not be done with a built-in?' Most of the time it will
    be right anyway :)

    --
    mph
     
    Martin P. Hellwig, Dec 6, 2008
    #9
  10. Bertilo Wennergren

    Roy Smith Guest

    In article <014a96e0$0$20670$>,
    Steven D'Aprano <> wrote:

    > On Sat, 06 Dec 2008 08:50:20 -0500, Roy Smith wrote:
    >
    > > For your first
    > > project, pick something that's small enough that you think you could
    > > tackle it in under 50 lines of Perl.

    >
    > Is there anything which *can't* be written in under 50 lines of Perl?

    [...]
    > Also, Perl REs are faster than Python REs, or so I'm told. Between the
    > speed and the convenience, Perl programmers tend to use RE's for
    > everything they can. Python programmers tend to use REs only for problems
    > that *should* be solved with REs rather than *can* be solved with a RE.


    Well, as an old-time unix hacker (who learned REs long before Perl
    existed), my question to you would be, "Is there any problem which
    *shouldn't* be solved with an RE?" :)

    It's easy to go nuts with REs, and create write-only code. On the other
    hand, they are an extremely powerful tool. If you are wise in the ways of
    RE-fu, they can not only be the most compact way to write something, but
    also the most efficient and even the most comprehensible. Unfortunately,
    REs seem to be regarded as some kind of monster these days and few people
    take the time to master them fully. Which is a shame.

    One really nice feature of REs in Python is the VERBOSE flag. It lets you
    write some way-complicated REs in a way which is still easy for somebody to
    read and understand. Python's raw strings, and triple-quoted strings, also
    help reduce the sea of backslashes which often make REs seem much worse
    than they really are.

    One of the reasons REs don't get used in Python as much as in Perl is
    because strings have useful methods like startswith(), endswith(), and
    split(), and also the "in" operator. These combine to give you easy ways
    to do many things you might otherwise do with REs.
     
    Roy Smith, Dec 6, 2008
    #10
  11. Bertilo Wennergren

    Rainy Guest

    On Dec 6, 5:00 am, Bertilo Wennergren <> wrote:
    > I'm planning to start learning Python now, using Python 3000.
    > I have no previous Python skills, but I now Perl pretty well.
    > I'm also well experienced with JavaScript.
    >
    > Any pointers and tips how I should go about getting into
    > Python?
    >
    > --
    > Bertilo Wennergren <http://bertilow.com>


    There's a lot of hoopla about Py3k being different, incompatible
    with Py2.x. However, you have to keep in mind that this matters
    most of all to old, large programs, which will need to be changed
    if one would like to run them on Py3k. For learning the differences
    don't matter much. If you learn to code in py2.x for half a year,
    you will be able to pick up on most of the differences and transfer
    to py3k in a few days. If you find good docs on py2.x go ahead and
    use them and don't worry.
     
    Rainy, Dec 6, 2008
    #11
  12. Bertilo Wennergren

    Carl Banks Guest

    On Dec 6, 12:30 pm, Roy Smith <> wrote:
    > In article <ghecgk$>, (Aahz)
    > wrote:
    >
    > > In article <ghe0jo$>,
    > > Bertilo Wennergren  <> wrote:

    >
    > > >I don't suppose there is any introductory material out there that is
    > > >based on Python 3000 and that is also geared at people with a Perl
    > > >background? Too early for that I guess..

    >
    > > Honestly, the differences between 2.x and 3.0 are small enough that it
    > > doesn't much matter, as long as you're not the kind of person who gets
    > > put off by little problems.  Because so much material is for 2.x, you
    > > may be better off just learning 2.x first and then moving to 3.x.

    >
    > I'm not sure I agree.  If you're starting out, you might as well learn the
    > new stuff.  Then there's no need to unlearn the old way.


    One disadvantage of learning Python 3 first is the availability of
    third-party libraries (especially extension libraries), most of which
    will not be updated for Python 3.x for quite a while.

    Also, I don't think it's really advisable to be completely ignorant of
    the 2.x difference even if one intends to start with 3.0. There is a
    lot of code and material out there for 2.x, and until these start to
    be widely available for 3.x, people will sometimes have to make do
    with the 2.x stuff.


    Carl Banks
     
    Carl Banks, Dec 6, 2008
    #12
  13. On Sat, 06 Dec 2008 14:15:28 -0500, Roy Smith wrote:

    > In article <014a96e0$0$20670$>,
    > Steven D'Aprano <> wrote:
    >
    >> On Sat, 06 Dec 2008 08:50:20 -0500, Roy Smith wrote:
    >>
    >> > For your first
    >> > project, pick something that's small enough that you think you could
    >> > tackle it in under 50 lines of Perl.

    >>
    >> Is there anything which *can't* be written in under 50 lines of Perl?

    > [...]
    >> Also, Perl REs are faster than Python REs, or so I'm told. Between the
    >> speed and the convenience, Perl programmers tend to use RE's for
    >> everything they can. Python programmers tend to use REs only for
    >> problems that *should* be solved with REs rather than *can* be solved
    >> with a RE.

    >
    > Well, as an old-time unix hacker (who learned REs long before Perl
    > existed), my question to you would be, "Is there any problem which
    > *shouldn't* be solved with an RE?" :)



    I think you've answered your own question:

    > One of the reasons REs don't get used in Python as much as in Perl is
    > because strings have useful methods like startswith(), endswith(), and
    > split(), and also the "in" operator. These combine to give you easy
    > ways to do many things you might otherwise do with REs.



    Also:

    * splitting pathnames and file extensions

    * dealing with arbitrarily nested parentheses

    * any time you need a full-blown parser (e.g. parsing HTML or XML)

    * sanitizing untrusted user input
    ("I bet I can think of *every* bad input and detect them all
    with this regex!")

    * validating email addresses
    http://northernplanets.blogspot.com/2007/03/how-not-to-validate-email-addresses.html

    * testing prime numbers
    http://jtauber.com/blog/2007/03/18/python_primality_regex/

    * doing maths
    http://blog.stevenlevithan.com/archives/algebra-with-regexes
    http://weblogs.asp.net/rosherove/archive/2004/11/08/253992.aspx



    There's probably more.


    --
    Steven
     
    Steven D'Aprano, Dec 7, 2008
    #13
  14. Perl Cookbook for Python Programmers:
    http://pleac.sourceforge.net/pleac_python/index.html

    P3K as starting point (slight cringe) as long as you know the caveats.

    I'm of the mind as Christopher with regard to how Python 3.0 has been
    released on Python.org:

    """I don't think that Python 3.0 is a bad thing. But that it's
    displayed so prominently on the Python web site, without any kind of
    warning that it's not going to work with 99% of the Python code out
    there, scares the hell out of me. People are going to download and
    install 3.0 by default, and nothing's going to work. They're going to
    complain, and many are going to simply walk away.
    - Christopher Lenz"""

    Python3 is beautiful, and I am totally with James Bennet
    http://www.b-list.org/weblog/2008/dec/05/python-3000/

    That said I would suggest you learn the whole history of the Py3K
    project and its 19+ years of 20/20 hindsight on what works well and
    what doesn't so you can if you want to jump right into Python3 fully
    informed on why it is the way it is and why you need to wait for 3rd
    party libraries to catch up and release a Python 3 compatible version
    and why all the Internal libraries are no worry except for the fact
    some of them have disappeared in the cleanup or merged into a single
    library. Then you can make sense of all the 2.x books and posts and
    know where to start when trying to apply it to Python 3.

    Cheers,
    PN
    (Python 2.5.2, Stackless Python 2.5.2, Python 2.6 and Python 3.0 on my box)

    P.S. Look into iPython as your new favourtie shell and virtualenv to
    help you keep all your projects straight and you'll be very productive
    in no time =)


    2008/12/7 Bertilo Wennergren <>:
    > I'm planning to start learning Python now, using Python 3000.
    > I have no previous Python skills, but I now Perl pretty well.
    > I'm also well experienced with JavaScript.
    >
    > Any pointers and tips how I should go about getting into
    > Python?
     
    Python Nutter, Dec 7, 2008
    #14
  15. > In article <014a96e0$0$20670$>,
    > Steven D'Aprano <> wrote:
    >
    > Well, as an old-time unix hacker (who learned REs long before Perl
    > existed), my question to you would be, "Is there any problem which
    > *shouldn't* be solved with an RE?" :)
    >
    > One of the reasons REs don't get used in Python as much as in Perl is
    > because strings have useful methods like startswith(), endswith(), and
    > split(), and also the "in" operator. These combine to give you easy ways
    > to do many things you might otherwise do with REs.



    I agree, I'm going through the new book Python for Unix and Linux
    Administration now and although in general I like what they say, they
    take you through the built in string functions and then introduce REs
    and end the chapter leaving the reader with the impression that REs
    are the better solution and I only agree with the case of the
    problem/program they presented.

    However I used the built ins more effectively using the indexes
    returned within the string and I've built plenty of scripts that did
    not need to move to REs to perform the text/file processing that I
    did. This intermediate use of string built-in functions was missing
    between the first string-function and RE versions of code and imho it
    is not letting the readers see that string-functions are even more
    powerful than the reader is lead to believe and that REs are pushed
    more towards edge cases than the impression the reader seems to be
    left with which is to use REs more.

    At least if you push REs inform the readers where to get the a RE GUI
    builder written in Python so they can build and *test* the complex and
    unwieldy REs to perform anything beyond the basic pattern searches.

    Cheers,
    PN
     
    Python Nutter, Dec 7, 2008
    #15
  16. Aahz wrote:

    > In article <ghe0jo$3i1$>,


    > Bertilo Wennergren <> wrote:


    >> I don't suppose there is any introductory material out there that is
    >> based on Python 3000 and that is also geared at people with a Perl
    >> background? Too early for that I guess..


    > Honestly, the differences between 2.x and 3.0 are small enough that it
    > doesn't much matter, as long as you're not the kind of person who gets
    > put off by little problems. Because so much material is for 2.x, you
    > may be better off just learning 2.x first and then moving to 3.x.


    The main reason I waited until Python 3000 came out is
    the new way Unicode is handled. The old way seemed really
    broken to me. Much of what I do when I program consists
    of juggling Unicode text (real Unicode text with lots of
    actual characters outside of Latin 1). So in my case
    learning version 2.x first might not be very convenient.
    I'd just get bogged down with the strange way 2.x handles
    such data. I'd rather skip that completely and just go
    with the Unicode handling in 3.0.

    --
    Bertilo Wennergren <http://bertilow.com>
     
    Bertilo Wennergren, Dec 7, 2008
    #16
  17. Bertilo Wennergren

    MRAB Guest

    Bertilo Wennergren wrote:
    > Aahz wrote:
    >
    >> In article <ghe0jo$3i1$>,

    >
    >> Bertilo Wennergren <> wrote:

    >
    >>> I don't suppose there is any introductory material out there that is
    >>> based on Python 3000 and that is also geared at people with a Perl
    >>> background? Too early for that I guess..

    >
    >> Honestly, the differences between 2.x and 3.0 are small enough that it
    >> doesn't much matter, as long as you're not the kind of person who gets
    >> put off by little problems. Because so much material is for 2.x, you
    >> may be better off just learning 2.x first and then moving to 3.x.

    >
    > The main reason I waited until Python 3000 came out is
    > the new way Unicode is handled. The old way seemed really
    > broken to me. Much of what I do when I program consists
    > of juggling Unicode text (real Unicode text with lots of
    > actual characters outside of Latin 1). So in my case
    > learning version 2.x first might not be very convenient.
    > I'd just get bogged down with the strange way 2.x handles
    > such data. I'd rather skip that completely and just go
    > with the Unicode handling in 3.0.
    >

    I wouldn't have said it was broken, it's just that it was a later
    addition to the language and backwards compatibility is important.
    Tidying things which would break backwards compatibility in a big way
    was deliberately left to a major version, Python 3.
     
    MRAB, Dec 7, 2008
    #17
  18. Bertilo Wennergren

    Roy Smith Guest

    In article <>,
    "Python Nutter" <> wrote:

    > At least if you push REs inform the readers where to get the a RE GUI
    > builder written in Python so they can build and *test* the complex and
    > unwieldy REs to perform anything beyond the basic pattern searches.


    Oh, my, I think my brain's about to explode. A RE GUI builder? Cough,
    gasp, sputter. This is literally the first time I've ever heard of such a
    thing, and it's leaving a bad taste in my mouth.

    RE is the last bastion of Real Programmers. Real Programmers don't use GUI
    builders. Using a GUI to build an RE is like trying to program by pushing
    little UMLish things around with a mouse. It's Just Wrong.
     
    Roy Smith, Dec 7, 2008
    #18
  19. Bertilo Wennergren

    Aahz Guest

    In article <ghfb0r$iae$>,
    Bertilo Wennergren <> wrote:
    >
    >The main reason I waited until Python 3000 came out is the new way
    >Unicode is handled. The old way seemed really broken to me. Much of
    >what I do when I program consists of juggling Unicode text (real
    >Unicode text with lots of actual characters outside of Latin 1). So in
    >my case learning version 2.x first might not be very convenient. I'd
    >just get bogged down with the strange way 2.x handles such data. I'd
    >rather skip that completely and just go with the Unicode handling in
    >3.0.


    Sounds like you have a good use-case for 3.0 -- go to it!
    --
    Aahz () <*> http://www.pythoncraft.com/

    "It is easier to optimize correct code than to correct optimized code."
    --Bill Harlan
     
    Aahz, Dec 7, 2008
    #19
  20. Bertilo Wennergren

    Roy Smith Guest

    In article <-wood.com>,
    Nick Craig-Wood <> wrote:

    > My favourite mistake when I made the transition was calling methods
    > without parentheses. In perl it is common to call methods without
    > parentheses - in python this does absolutely nothing! pychecker does
    > warn about it though.
    >
    > perl -> $object->method
    > python -> object.method()


    On the other hand, leaving out the parens returns the function itself,
    which you can then call later. I've often used this to create data-driven
    logic.

    For example, I'm currently working on some code that marshals objects of
    various types to a wire protocol. I've got something like:

    encoders = {
    SM_INT: write_int,
    SM_SHORT: write_short,
    SM_FLOAT: write_float,
    # and so on
    }

    class AnyVal:
    def __init__(self, type, value):
    self.type = type
    self.value = value

    def write_anyval(any):
    encoders[any.type](any.value)

    The fact that functions are objects which can be assigned and stored in
    containers makes this easy to do.
     
    Roy Smith, Dec 8, 2008
    #20
    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. Richard

    Coming together so nicely now.

    Richard, Jan 22, 2005, in forum: HTML
    Replies:
    7
    Views:
    454
    Blinky the Shark
    Jan 23, 2005
  2. Steve Holden

    PyCon is Coming! PyCon is Coming!

    Steve Holden, Jan 5, 2006, in forum: Python
    Replies:
    0
    Views:
    315
    Steve Holden
    Jan 5, 2006
  3. Hal Vaughan
    Replies:
    7
    Views:
    480
  4. Amer Neely

    Coming from Perl

    Amer Neely, Sep 13, 2007, in forum: Python
    Replies:
    29
    Views:
    721
    Steve Holden
    Sep 18, 2007
  5. Andrey Popp

    [I'm learning C]: Learning to use ucontext

    Andrey Popp, Jan 29, 2012, in forum: C Programming
    Replies:
    5
    Views:
    733
    Keith Thompson
    Jan 31, 2012
Loading...

Share This Page