Learning Python Programming - Advice for Beginners

[science.girl]

I am new to computer programming, but if anyone familiar with Python has any suggestions or resources for a beginner, I would appreciate it.

How useful is programming in Python? How does it compare to other programming languages?

I've also heard that Python is relatively simple to learn; is this true in your experience?

Thanks for your responses!

 

[Dick]

Yes, it is simple to learn. And it's extremely powerful and coherent. Find out for yourself. Just learn it. There are endless numbers of tutorials and websites. Start learning how to use the objects and inheritance sooner rather than later, that's my advice. It will change your life.

 

[science.girl]

Yes, it is simple to learn. And it's extremely powerful and coherent. Find out for yourself. Just learn it. There are endless numbers of tutorials and websites. Start learning how to use the objects and inheritance sooner rather than later, that's my advice. It will change your life.

Hmm... Learn how to use objects and inheritance sooner rather than later... some good advice, I'm sure. =)

I appreciate your response, and will look into the tutorials soon. Thanks!

 

[mgb_phys]

Start here http://diveintopython.org/
And possibly here http://www.greenteapress.com/thinkpython/ (there is a link to a free version of the book)
For science stuff checkout scipy http://www.scipy.org/

The nice thing about python is you can do procedural/object orientated or functional programming depending on the problem.

 

[rootX]

http://www.python.org/doc/

some google fun:
http://code.google.com/
http://code.google.com/apis/calendar/docs/1.0/developers_guide_python.html

I don't know python but I can use google python api and make things out of it.

 

[science.girl]

Thank you all very much -- I have already begun checking out the links, and I can't wait to dive into some applications.

 

[robphy]

http://vpython.org/

http://www.google.com/search?q=vpython

 

[signerror]

People, try harder. This is bad advice you're giving out.

Start learning how to use the objects and inheritance sooner rather than later, that's my advice. It will change your life.

No, someone new to programming has no use for object oriented programming. Simple, small programs really are sequences of commands (imperative statements) - procedural, or maybe functional, styles are most natural for this. OOP is an unnecessary distraction for the new programmer. It distracts from far more fundamental issues - for instance, variable scoping, typing, procedures/functions, organizing code without objects...

Start here http://diveintopython.org/

Dive Into Python is a Python book for experienced programmers.

 

[signerror]

I am new to computer programming, but if anyone familiar with Python has any suggestions or resources for a beginner, I would appreciate it.

How useful is programming in Python? How does it compare to other programming languages?

I've also heard that Python is relatively simple to learn; is this true in your experience?

Thanks for your responses!

Yes, Python is probably the best language to start with. It is very easy to learn. It is also very useful - it is very popular, and has lots of very good third-party libraries (as mentioned here, you have SciPy for numerical work, and vPython for basic graphics...)

Another important point is that you can program interactively, with an interpreter executing your code in real time - this is extremely good for experimentation and learning. You can examine objects and variables interactively too. You'll quickly see how useful this is.

One very useful reference is the official docs for Python libraries,

http://docs.python.org/library/

I'm sorry I'm not sure which introductory books are good right now.

 

[science.girl]

Yes, Python is probably the best language to start with. It is very easy to learn. It is also very useful - it is very popular, and has lots of very good third-party libraries (as mentioned here, you have SciPy for numerical work, and vPython for basic graphics...)

Another important point is that you can program interactively, with an interpreter executing your code in real time - this is extremely good for experimentation and learning. You can examine objects and variables interactively too. You'll quickly see how useful this is.

One very useful reference is the official docs for Python libraries,

http://docs.python.org/library/

I'm sorry I'm not sure which introductory books are good right now.

Thank you very much, Signerror. Will follow your suggestions.

 

[mgb_phys]

Sorry I had forgotten that dive into wasn't for new programmers.
Thinking like a computer scientist in python is - it's aimed at high school students
Free online version here http://openbookproject.net//thinkCSpy/

 

[Dick]

People, try harder. This is bad advice you're giving out.
No, someone new to programming has no use for object oriented programming. Simple, small programs really are sequences of commands (imperative statements) - procedural, or maybe functional, styles are most natural for this. OOP is an unnecessary distraction for the new programmer. It distracts from far more fundamental issues - for instance, variable scoping, typing, procedures/functions, organizing code without objects...

Really got to disagree with you there, signerror. Unlike some other languages I could name, objects are not an 'add-on' in Python. They ARE the language. The rest of those concepts are the 'distractions'. That's what you learn when you've finally really gotten Python. Even a small program is more efficiently and flexibly structured as an object. It just fits. It's easy to start off in Python by emulating styles from other languages, which you can do, but when you finally get it, you realize that was wrong.

 

[AUMathTutor]

I, for one, think that it's true one should start without objects, but...
You should get there as soon as possible. Realistically, you should be comfortable with data types, branching, loops, and functions before you really start trying to use objects. Then, you should get good with using simple objects before using inheritance, polymorphism, etc.

It would be a shame for anybody to learn to program nowadays without learning OO programming. I doubt anybody starts off learning by writing fully OO programs. People start off writing procedural code in an OO language.

 

[Dick]

Sure they do. I couldn't agree more. I started by writing convoluted code using procedures and rearranging lists, coming from writing a lot of mathematica. My mistake. Feel free to start that way. There's probably a lot of other ways to make fundamental design errors. I'm just saying that the sooner you get beyond that the sooner you realize what a bad idea that was.

 

[Cryptonic]

I'm new too, and this has helped me a lot get my foot in the door.
http://pythonbook.coffeeghost.net/

 

[TurtleMeister]

I'm really tired of hearing all the hype about OOP. Maybe it's a good paradigm for some situations. And maybe it works well for some programmers. But I have a hard time accepting that it is the "be all end all" of programming. I've been programming for over 30 years (assembly for (Z80, 8086, various micro-controllers), basic, vb.net, java, PHP and c#). And after hearing all the hype, and after trying it myself, and after not being able to "get" why it's better than procedural methods, it was nice to come across at least one other person that was not so "gung ho" about it.

http://www.geocities.com/tablizer/oopbad.htm

 

[mXSCNT]

I write python for personal use, and I rarely feel the need to define my own classes. My code is just a bunch of functions that operate on simple data. If I need a data structure that has three or four properties, most likely I'll just use a list or tuple instead of an object--the tuple is more convenient. Also, frequently it's simpler to pass a function as an argument to my function, instead of using polymorphism. If I NEED object oriented features because my objects have so many properties that I need to name them to keep track of them, then I'll define a class, but on small personal projects of a few hundred lines or less, this doesn't happen much.

I've done all the object oriented stuff in Java, too, plus I've cut my teeth on an armful of other languages. I just find functions to usually be a more convenient way of structuring code, at least on small personal projects.

 

[AUMathTutor]

I think that OOP can contribute to making software projects better in several respects: it fosters reuse and encapsulation, for example. I doubt anyone would argue that OOP is the end-all solution for every software project, but the reasons why it has reached such a privileged status cannot be ignored.

I've worked on a couple of scientific projects where OOP would have helped in the development efforts immensely. We didn't use it because the PI couldn't understand it, which I think is a real shame.

I, for one, think that the OOP paradigm generally makes development a lot easier than not. Considering that most popular programming languages are OOP and procedural hybrids (that is, the objects' methods are written using procedural style), it's usually not so contrived or difficult to make an OO design procedural, or vice versa.

I don't think functions operating on arrays is the way to go. I guess my position is that the number of objects and the complexity of the object hierarchy should be as low as possible... but no lower. Certain objects just suggest themselves... to willfully not use the benefits of OOP when practical seems superstitious to me.

 

[mXSCNT]

Object oriented programming comes at a cost besides the increased code length. Every time you add a new class and write functions to work with the class, you force someone else to figure out how your class works before they can use those functions. That decreases the likelihood that they are going to re-use your functions.

If you have a function that takes a string and an int, it's more likely to be re-used than an equivalent function that takes a MyOwnObject, where MyOwnObject has two fields, MyOwnObject.stringVal and MyOwnObject.intVal.

Of course, no one should say that user-defined classes are useless; they have their place, which is mostly in larger projects (beyond a few hundred lines), where you pass around enough fields in your data to want to name them. Also, hiding data behind an interface can be a good idea, to avoid tying your code down to an implementation. However, data hiding is only a concern on larger projects; for smaller projects it tends not to be worth the time and added complexity.

 

[AUMathTutor]

"Object oriented programming comes at a cost besides the increased code length."
OOP facilitates software development on large projects. There is actual evidence supporting my claim... I will be happy to look for it if you are interested. Apparently, the increased length of code is not such a hindrance.

"Every time you add a new class and write functions to work with the class, you force someone else to figure out how your class works before they can use those functions."
Of course, this is true of *any* code you write, whether it be OO, functional, logic, ... People will have to understand how your code works before they can use it. The argument is that it's easier for people to intuitively grasp how objects behave than it is to grasp how mathematical functions or sentences of propositional logic.

That decreases the likelihood that they are going to re-use your functions."
Since reuse is one of the main benefits of OOP, I'm sure you'll agree that while OOP may not be perfect, it is often better than the alternatives. Just because *you* have a harder time understanding OO code doesn't mean it's inferior.

"If you have a function that takes a string and an int, it's more likely to be re-used than an equivalent function that takes a MyOwnObject, where MyOwnObject has two fields, MyOwnObject.stringVal and MyOwnObject.intVal."
That's a little contrived, and you know it. Any paradigm can be made to look silly if you misuse it. Consider the following code to calculate the product of two integers.

product_of_two(x,y) : divide(subtract(square(subtract(x,y)), add(square(x), square(y)),-2)

See, so using procedures is stupid by the same logic. If you understood how to use OOP, you would see that your code is just as unnecessary and contrived as is mine.

And I disagree that OOP is only good for large projects. While it's true that larger projects get even more benefit from OOP, even small programs can benefit from (appropriate) usage of OOP - which goes well beyond defining a few record types to store data. Lots of programs tend to start small and get bigger; the global-variable, goto, pure-procedural style of programming is simply not scalable. You invariably end up with a nightmare of interconnected global variables and parallel arrays and function pointers that only you and the other people who were with you at the time can comprehend, and if you lose the documentation (assuming you make any at all, and if your PI is not in CS, then odds are the documentation will be slim to none) then good luck knowing what you were thinking when you try to figure it out after a week of vacation.

 

[mXSCNT]

You seem to have built a strawman of everything that is bad programming, and used it to besmirch any programming that is not object-oriented. I think you would benefit from learning how to express things efficiently outside the object oriented paradigm. Try learning Haskell. Done properly, the experience should dispel many of your fears about global variables and spaghetti code :)

Let me give you an example. Here's a snippet of code I wrote recently to assign indices to combinations of objects from several different groups (in response to a math question somebody asked me). This code is well organized. I don't see any way that this code could benefit from defining a class.

# given binsizes=b_1, b_2, ..., b_n, compute sum(b_i)! / (b_1! b_2! ... b_n!)
# or 0 if sum(b_i) = 0.  This is the number of ways to arrange sum(b_i) objects 
# in a row,
# where group i has b_i indistinguishable elements, and objects from different 
# groups are distinguishable
# s is an optional argument, which if supplied should be equal to sum(binsizes)
def multichoose(binsizes, s=-1):
    if s == -1:
        s = sum(binsizes)
    if s == 0:
        return 0
    i = 0
    result = 1
    while i < len(binsizes):
        result *= choose(s, binsizes[i])
        s -= binsizes[i]
        i += 1
    return result

# Given a combination, written as a list of numbers like C = [0,1,1,0,0], assigns 
# a number N(C) to this combination.  N is invertible, mapping any n, 0 <= n < 
# max_C {N(C)} to some C, where the maximum is taken over all C matching 
# the pattern of the given C (in this case, the pattern is 3 0's and 2 1's).  The 
# numbers appearing in C must be in range(0,multichoose(binsizes)), with no gaps
def combcount(C):
    binsizes = [0]*len(set(C))
    for i in xrange(len(C)):
        binsizes[C[i]] += 1
    s = sum(binsizes)
    result = 0
    for i in xrange(len(C)):
        # add to result the number of valid combinations V whose prefixes (up to index i-1)
        # are as given, and where V[i] < C[i]
        for j in xrange(C[i]):
            if binsizes[j] == 0:
                continue
            binsizes[j] -= 1
            s -= 1
            result += multichoose(binsizes, s)
            binsizes[j] += 1
            s += 1
        binsizes[C[i]] -= 1
        s -= 1
    return result

# given a number N and a list of bin sizes (as in the argument of multichoose), 
# where 0 <= N < multichoose(binsizes)
# produce the combination C matching binsizes such that combcount(C)=N.
def combcreate(N,binsizes):
    s = sum(binsizes)
    l = len(binsizes)
    C = [0]*s
    for i in xrange(s):
        mchoose = 0
        j = -1
        # subtract from N the number of valid combinations V whose prefixes (up to 
# index i-1) are as already found, and where V[i] < j, where j is the largest 
# integer such that N remains nonnegative during this process
        while N >= 0:
            newj = j+1
            while newj != l and binsizes[newj] == 0:
                newj += 1
                mchoose = 0
            if newj == l:
                break
            j = newj
            binsizes[j] -= 1
            s -= 1
            mchoose = multichoose(binsizes,s)
            N -= mchoose
            binsizes[j] += 1
            s += 1
        C[i] = j
        N += mchoose
        binsizes[j] -= 1
        s -= 1
    return C

def choose(n, k):
    # iterative solution, dividing first when possible
    nmink = n - k
    if nmink < k:
        nmink, k = k, nmink
    result = 1
    while n > 0:
        if n == nmink:
            break
        result *= n
        n -= 1
        if k > 1 and result % k == 0:
            result /= k
            k -= 1
    for i in xrange(2,k+1):
        result /= i
    return result

 

[AUMathTutor]

Well, I guess I may have been a little overzealous. The point I was trying to make is just that procedural-based OOP is probably the most general paradigm one should become comfortable with.

And yeah, granted, your snippet of code is fine... there's not anything wrong with it, per se. I guess I just wouldn't consider something of that size to be a case where considerations like what we're talking about make any difference at all.

I mean, I count around 70 actual lines of code... and for 70 lines of code, just about any way you choose to program will be manageable. I mean, you could translate that code, by hand, into assembly language and it wouldn't take too much effort. For tasks of this magnitude, you really can't go wrong with just about any paradigm.

My thing, though, is that the paradigm doesn't scale well with problem size. If you're just going to be writing 100 line programs, then it doesn't much matter whether the code is inherently clear or well-structured. And if this is all you will ever need to do, by all means, purely procedural or functional programming is fine. In fact, they can often be preferred over the OOP approach since they are more concise and elegant in many cases - especially when one just needs some calculation to be done.

However, it has been my experience that projects start small, and get a little bigger, and a little bigger, and a little bigger... and one day you find yourself wondering how a 100 line program to calculate scattering cross sections turned into a 10,000 line program that runs a variety of test suites, does a laundry list of calculations, and manages preposterously large formatted data records.

And 10,000 lines of code is small for lots of real projects. What's more, at least in my experience developing software for scientific research, feature creep is the not what you're trying to avoid, but the whole point of doing it in the first place. It's all too easy to adopt lazy programming practices in pure procedural C-style code... you use a global variable here because it makes one thing a little easier to do, and then you realize 15 functions are intimately related to that variable.

The semantics of such programs are so unwieldy that you get to a point where you're just hoping that adding code that changes certain things leaves the system intact. This isn't a desirable situation. OOP's main features - encapsulation, generalization, etc - help with issues such as these, at least in my experience. Oh well.

 

[Sypher]

What are you guys going on about? I mean this person is trying to get advise about Python and you want to set your personal ideas about the language.

Personaly I like OOP although I don't use it to much.
My advise to science.girl is: Learn what you want to learn. When you get to the OOP section, define a class with instace variables and methods. And NEVER LET ANYONE BULLY YOU into accepting their view on programming but listen to good advise.

Thats all so good luck