Learning Python now coming from Perl

[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?

 

[Roy Smith]

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.

 

[Bertilo Wennergren]

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

 

[Colin J. Williams]

Good advice.


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.

 

[Steven D'Aprano]

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.

 

[Aahz]

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.

 

[News123]

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]

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.

 

[Martin P. Hellwig]

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

 

[Roy Smith]

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.

 

[Rainy]

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?

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.

 

[Carl Banks]

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

 

[Steven D'Aprano]

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.

 

[Python Nutter]

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

 

[Python Nutter]

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

 

[Bertilo Wennergren]

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.

 

[MRAB]

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.

 

[Roy Smith]

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.

 

[Aahz]

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!

 

[Roy Smith]

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.