Differences between revisions 1 and 18 (spanning 17 versions)
Revision 1 as of 2002-10-22 20:50:50
Size: 5071
Editor: adsl-64-170-226-162
Comment:
Revision 18 as of 2003-04-04 19:58:13
Size: 8784
Editor: ip51cc4013
Comment: Oops. :)
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
= Moving to Python from other Programming Languages = #pragma section-numbers off
Line 3: Line 3:
If you are already a programmer, Python could be the easiest to learn of all the languages you have encountered. It is pretty typical to learn the Python language while you are writing your first non-trival Python program! In other words, feel free to skip "Hello World" and move right to file administration, GUI programming, and exotic numerical analysis! I am exaggerating, I admit! :) But you will definately be much farther with Python during your first 3 days than you would be with any other language. If you are already a programmer, Python could be the easiest to learn of all the languages you have encountered. It is pretty typical to learn the Python language while you are writing your first non-trivial Python program! In other words, feel free to skip "Hello World" and move right to file administration, GUI programming, and exotic numerical analysis! I am exaggerating, I admit! :) But you will definitely be much farther with Python during your first 3 days than you would be with any other language.
Line 7: Line 7:
* ["http://www.linuxjournal.com/article.php?sid=3882" Eric S. Raymond "Why Python?"] * [http://www.linuxjournal.com/article.php?sid=3882 Eric S. Raymond 'Why Python?']
Line 17: Line 17:
== Where is Python's CPAN? ==

Python doesn't have a CPAN.

Before you roll your eyes and run back to the waiting arms of PERL, consider these points:

(some taken from [http://www.seapig.org/PythonDoesntNeedCpan Python Doesn't Need CPAN Wiki])

 * Python comes with "Batteries Included". The standard modules shipped with Python has a lot of good stuff, and for many common tasks you just don't need the extra step of CPAN. '''Python's standard library of modules is nothing to sneeze at!'''

 * Python now has a centralised database of software, the [http://www.python.org/pypi Python Package Index (PYPI)]. Any developer of Python software packaged using distutils (the built-in packaging system) may easily submit their package information to the index.

 * Python has [http://www.vex.net/parnassus The Vaults of Parnassus]. Unfortunately, the Vaults are not standardized or automated to the degree that the CPAN is.

People get addicted to programming in Python. So Pythonistas code from scratch where it would be better to use public code.

== Python PEP 8: Style Guide for Python Code ==

[http://www.python.org/peps/pep-0008.html Style Guide for Python Code]

You will read this sooner or later. Why not sooner?

Back when I was learning programming and I was learning C, I made my own personal convention for braces and parentheses, just like every C newbie does. And like every C newbie, I thought my personal convention was right, all other ways of doing it were wrong, and I was willing to fight to the death over it.

Of course the best way to program in any language is to become a member of that language's community and follow the community's norms. It is initially hard to program in a style that goes against your preferences and prejudices. But the sooner you pick up the community norms, and join the community, the soon you can take full advantage of all the community's resources.

PEP 8 is a style guide written mainly by Guido. Beyond learning stylistic norms, you will also be presented with a style that is very well thought out (like most things in Python). If you follow this guide, you ''will'' program more '''Pythonically''', and you will be more productive with Python.
Line 19: Line 47:
(The phrase ''Thinking in Python'' was borrowed from the Bruce Eckel book of the same name. It is currently an online book, available for reading for free-as-in beer! ["http://www.mindview.net/Books/TIPython" Mindview Inc. ''Thinking in Python''] This book is not meant for beginners to Python, however. It is the Python equivilant of Bruce Eckel's popular ''Thinking in C++'' and ''Thinking in Java'') (The phrase ''Thinking in Python'' was borrowed from ["http://www.mindview.net/Books/TIPython" the Bruce Eckel book] of the same name. It is currently an online book, available for reading for free-as-in beer! This book is not meant for beginners to Python, however. It is the Python equivalent of Bruce Eckel's popular ''Thinking in C++'' and ''Thinking in Java'')
Line 21: Line 49:
The following was taken from a post in comp.lang.python from Mel Wilson, which I thought well summarized good Python programming style for people coming from other languages.   ''Thinking in Python'' is completely different from ''Thinking in C++/Java''. It's adapted from Eckel's draft for ''Thinking in Patterns'', a bit like the Wiki:DesignPatternsBook by the Wiki:GangOfFour.
Line 23: Line 51:
* The docs at python.org are very, very good. Hold onto that wallet, you don't need a trip to the bookstore to learn Python! The following was taken from a post in comp.lang.python from Mel Wilson, which I thought well summarized good Python programming style for people coming from other languages. I also added some things I would have appreciated knowing during my first 3 days with Python.
Line 25: Line 53:
* Scan the full list of built-in module names early on. Python is advertised as "batteries included", so knowledge of the built-in modules could make a 80 line program turn into a 8 line program.  * The docs at python.org are very, very good. Hold onto that wallet, you don't need a trip to the bookstore to learn Python!
Line 27: Line 55:
* Learn Python slice notation, you will be using it a lot.  * Scan the full list of built-in module names early on. Python is advertised as "batteries included", so knowledge of the built-in modules could reduce the lines of code by a factor of ten.
Line 29: Line 57:
* Lose the braces, as you know them, and most of the semicolons, obviously.  * Learn Python slice notation, you will be using it a lot. I have this chart taped to my monitor:
Line 31: Line 59:
* Backslash can be used to allow continuing the program line past a carriage-return, but you almost never have to use it. Python is smart enough to do the right thing when it sees an open bracket, a comma separated list, and a carriage-return. {{{
Python indexes and slices for a six-element list.
Indexes enumerate the elements, slices enumerate the spaces between the elements.
Line 33: Line 63:
* Where you would use `<vector T>`, use lists, or tuples, that is [] or (). Where you would use `<map T1, T2>`, use dictionaries, that is {} . Index from rear: -6 -5 -4 -3 -2 -1 a=[0,1,2,3,4,5] a[1:]==[1,2,3,4,5]
Index from front: 0 1 2 3 4 5 len(a)==6 a[:5]==[0,1,2,3,4]
                   +---+---+---+---+---+---+ a[0]==0 a[:-2]==[0,1,2,3]
                   | a | b | c | d | e | f | a[5]==5 a[1:2]==[1]
                   +---+---+---+---+---+---+ a[-1]==5 a[1:-1]==[1,2,3,4]
Slice from front: : 1 2 3 4 5 : a[-2]==4
Slice from rear: : -5 -4 -3 -2 -1 :
                                                b=a[:]
                                                b==[0,1,2,3,4,5] (shallow copy of a)
}}}
Line 35: Line 74:
   The semantics of iterators is available, but most of the
syntax goes away. `for item in alist:` iterates over all
the items in alist, one by one .. where `alist` is a
sequence, i.e. a list, tuple, or string. To iterate over a
sublist, use slices: `for item in alist[1:-1]:` does as
above, but omits the first and last items.
 * Lose the braces, as you know them, and most of the semicolons, obviously.
Line 42: Line 76:
   For trickier iterations, read and re-read the Library doc
on the topic of general-purpose functions. There are some
functions that apply to sequences: map, filter, reduce,
zip. that can work wonders. Hidden somewhere under the
documentation for sequences there is a description of string
methods that you'll want to read.
 * Backslash can be used to allow continuing the program line past a carriage-return, but you almost never have to use it. Python is smart enough to do the right thing when it sees an open bracket, a comma separated list, and a carriage-return.
Line 49: Line 78:
   Hidden under the docs for 'Other Types' are the
descriptions of all the file methods. There are no
iostreams per se, but the class method __str__ can get some
of the effect for your own classes, and there are surely
other angles I haven't thought of.
 * Strings are immutable. Whenever you think you have changed a string, remember that you really created a new string.
Line 55: Line 80:
   Forget polymorphism. You can define a function, and call
it with anything you want, but if it has to behave
differently for different type operands, you have to use the
run-time type identification `type` function explicitely
within the single definition of the function. Default
arguments to functions are just as powerful a tool as in
C++.
 * Where you would use `<vector T>`, use lists, or tuples, that is [] or (). Where you would use `<map T1, T2>`, use dictionaries, that is {} .
Line 63: Line 82:
   In class definitions the equivalents of operator methods
are covered in a chapter in the Python Language Reference.
(Look for the double-underscore methods like __cmp__,
__str__, __add__, etc.)
 * The semantics of iterators is available, but most of the syntax goes away. `for item in alist:` iterates over all the items in alist, one by one .. where `alist` is a sequence, i.e. a list, tuple, or string. To iterate over a sublist, use slices: `for item in alist[1:-1]:` does as above, but omits the first and last items.
Line 68: Line 84:
   In C, the gotcha for new users is probably about
pointers; they're tricky and they can't be avoided. The
gotchas in Python are situations when you use different
references to a single object, thinking you are using
different objects. I believe the difference between mutable
and immutable objects comes into play. I have no clear
answers here .. I still get caught once in a while .. keep
your eyes open.
 * For trickier iterations, read and re-read the Library doc on the topic of general-purpose functions. There are some functions that apply to sequences: map, filter, reduce, zip. that can work wonders. Hidden somewhere under the documentation for sequences there is a description of string methods that you'll want to read.
Line 77: Line 86:
   Read the Tutorial once, skim the Library Reference .. at
least the table of contents, then skim the Language
Reference and you will probably have encountered everything
you need.
 * Hidden under the docs for 'Other Types' are the descriptions of all the file methods. There are no iostreams per se, but the class method __str__ can get some of the effect for your own classes, and there are surely other angles I haven't thought of.

 * Forget polymorphism. You can define a function, and call it with anything you want, but if it has to behave differently for different type operands, you have to use the run-time type identification `type` function explicitly within the single definition of the function. Default arguments to functions are just as powerful a tool as in C++. ''Actually polymorphism does work as expected, it just doesn't require deriving from a base class as in C++ or Java.''

 * In class definitions the equivalents of operator methods are covered in a chapter in the Python Language Reference. (Look for the double-underscore methods like `__cmp__`, `__str__`, `__add__`, etc.)

 * In C, the gotcha for new users is probably about pointers; they're tricky and they can't be avoided. The gotchas in Python are situations when you use different references to a single object, thinking you are using different objects. I believe the difference between mutable and immutable objects comes into play. I have no clear answers here .. I still get caught once in a while .. keep your eyes open.

 * Read the Tutorial once, skim the Library Reference .. at least the table of contents, then skim the Language Reference and you will probably have encountered everything you need.

== Python Culture ==

 * [http://www.python.org/dev/culture.html Python Culture (Tim Peters channeling Guido)]

----
See also: MovingFromPerlToPython

If you are already a programmer, Python could be the easiest to learn of all the languages you have encountered. It is pretty typical to learn the Python language while you are writing your first non-trivial Python program! In other words, feel free to skip "Hello World" and move right to file administration, GUI programming, and exotic numerical analysis! I am exaggerating, I admit! :) But you will definitely be much farther with Python during your first 3 days than you would be with any other language.

Here is an account of a programmer coming to Python and being extremely productive far sooner than he expected to be.

* [http://www.linuxjournal.com/article.php?sid=3882 Eric S. Raymond 'Why Python?']

Significant Whitespace

The less said, the better. Python uses whitespace to signify end-of-line and code blocks. This will annoy you! But you will get used to it, as did thousands of programmers before you. You might even grow to like it.

comp.lang.python

Probably your most valuable Python resource, right after python.org. Spot Python luminaries in their native habitat! Don't be surprised to have your questions answered by the original programmer or the author of the book open on your desk! The best thing about comp.lang.python is how "newbie-friendly" the mail group is. You can ask any question and never get a "RTFM" thrown back at you.

Where is Python's CPAN?

Python doesn't have a CPAN.

Before you roll your eyes and run back to the waiting arms of PERL, consider these points:

(some taken from [http://www.seapig.org/PythonDoesntNeedCpan Python Doesn't Need CPAN Wiki])

  • Python comes with "Batteries Included". The standard modules shipped with Python has a lot of good stuff, and for many common tasks you just don't need the extra step of CPAN. Python's standard library of modules is nothing to sneeze at!

  • Python now has a centralised database of software, the [http://www.python.org/pypi Python Package Index (PYPI)]. Any developer of Python software packaged using distutils (the built-in packaging system) may easily submit their package information to the index.

  • Python has [http://www.vex.net/parnassus The Vaults of Parnassus]. Unfortunately, the Vaults are not standardized or automated to the degree that the CPAN is.

People get addicted to programming in Python. So Pythonistas code from scratch where it would be better to use public code.

Python PEP 8: Style Guide for Python Code

[http://www.python.org/peps/pep-0008.html Style Guide for Python Code]

You will read this sooner or later. Why not sooner?

Back when I was learning programming and I was learning C, I made my own personal convention for braces and parentheses, just like every C newbie does. And like every C newbie, I thought my personal convention was right, all other ways of doing it were wrong, and I was willing to fight to the death over it.

Of course the best way to program in any language is to become a member of that language's community and follow the community's norms. It is initially hard to program in a style that goes against your preferences and prejudices. But the sooner you pick up the community norms, and join the community, the soon you can take full advantage of all the community's resources.

PEP 8 is a style guide written mainly by Guido. Beyond learning stylistic norms, you will also be presented with a style that is very well thought out (like most things in Python). If you follow this guide, you will program more Pythonically, and you will be more productive with Python.

Tips for "Thinking in Python"

(The phrase Thinking in Python was borrowed from ["http://www.mindview.net/Books/TIPython" the Bruce Eckel book] of the same name. It is currently an online book, available for reading for free-as-in beer! This book is not meant for beginners to Python, however. It is the Python equivalent of Bruce Eckel's popular Thinking in C++ and Thinking in Java)

  • Thinking in Python is completely different from Thinking in C++/Java. It's adapted from Eckel's draft for Thinking in Patterns, a bit like the DesignPatternsBook by the GangOfFour.

The following was taken from a post in comp.lang.python from Mel Wilson, which I thought well summarized good Python programming style for people coming from other languages. I also added some things I would have appreciated knowing during my first 3 days with Python.

  • The docs at python.org are very, very good. Hold onto that wallet, you don't need a trip to the bookstore to learn Python!
  • Scan the full list of built-in module names early on. Python is advertised as "batteries included", so knowledge of the built-in modules could reduce the lines of code by a factor of ten.
  • Learn Python slice notation, you will be using it a lot. I have this chart taped to my monitor:

Python indexes and slices for a six-element list.
Indexes enumerate the elements, slices enumerate the spaces between the elements.

Index from rear:    -6  -5  -4  -3  -2  -1      a=[0,1,2,3,4,5]    a[1:]==[1,2,3,4,5]
Index from front:    0   1   2   3   4   5      len(a)==6          a[:5]==[0,1,2,3,4]
                   +---+---+---+---+---+---+    a[0]==0            a[:-2]==[0,1,2,3]
                   | a | b | c | d | e | f |    a[5]==5            a[1:2]==[1]
                   +---+---+---+---+---+---+    a[-1]==5           a[1:-1]==[1,2,3,4]
Slice from front:  :   1   2   3   4   5   :    a[-2]==4
Slice from rear:   :  -5  -4  -3  -2  -1   :
                                                b=a[:]
                                                b==[0,1,2,3,4,5] (shallow copy of a)
  • Lose the braces, as you know them, and most of the semicolons, obviously.
  • Backslash can be used to allow continuing the program line past a carriage-return, but you almost never have to use it. Python is smart enough to do the right thing when it sees an open bracket, a comma separated list, and a carriage-return.
  • Strings are immutable. Whenever you think you have changed a string, remember that you really created a new string.
  • Where you would use <vector T>, use lists, or tuples, that is [] or (). Where you would use <map T1, T2>, use dictionaries, that is {} .

  • The semantics of iterators is available, but most of the syntax goes away. for item in alist: iterates over all the items in alist, one by one .. where alist is a sequence, i.e. a list, tuple, or string. To iterate over a sublist, use slices: for item in alist[1:-1]: does as above, but omits the first and last items.

  • For trickier iterations, read and re-read the Library doc on the topic of general-purpose functions. There are some functions that apply to sequences: map, filter, reduce, zip. that can work wonders. Hidden somewhere under the documentation for sequences there is a description of string methods that you'll want to read.
  • Hidden under the docs for 'Other Types' are the descriptions of all the file methods. There are no iostreams per se, but the class method str can get some of the effect for your own classes, and there are surely other angles I haven't thought of.

  • Forget polymorphism. You can define a function, and call it with anything you want, but if it has to behave differently for different type operands, you have to use the run-time type identification type function explicitly within the single definition of the function. Default arguments to functions are just as powerful a tool as in C++. Actually polymorphism does work as expected, it just doesn't require deriving from a base class as in C++ or Java.

  • In class definitions the equivalents of operator methods are covered in a chapter in the Python Language Reference. (Look for the double-underscore methods like __cmp__, __str__, __add__, etc.)

  • In C, the gotcha for new users is probably about pointers; they're tricky and they can't be avoided. The gotchas in Python are situations when you use different references to a single object, thinking you are using different objects. I believe the difference between mutable and immutable objects comes into play. I have no clear answers here .. I still get caught once in a while .. keep your eyes open.
  • Read the Tutorial once, skim the Library Reference .. at least the table of contents, then skim the Language Reference and you will probably have encountered everything you need.

Python Culture


See also: MovingFromPerlToPython

MovingToPythonFromOtherLanguages (last edited 2021-01-16 07:35:23 by JaraKaca)

Unable to edit the page? See the FrontPage for instructions.