Learning Object Oriented Python
I wrote this as a guide for a financial analyst friend of mine looking to learn Python. He is already fairly well versed in doing Project Euler problems in Ruby. All italicized text is for the benefit of any other readers, such as yourself.
Each section is divided into a short resource (10 minutes or less), a long resource (days to weeks or more), and a challenge.
So what you're looking to do is to be able to recreate financial models in code. And other types of models. This is a noble pursuit.
I recommend learning object oriented programming (OOP) in Python. But first, learn python:
Try Python (Short)
Pretty sure I had you go through the Ruby version of this. These will help familiarize you with Python's syntax. Should take you about 10 minutes to go through, according to their site.
Learn Python the Hard Way (Long)
Ditto, this should look familiar. Learn Python 3.0+. Note that Zed specifically says to use Python 2. I made a mistake in my email - this was an artifact from when I was suggesting the Python Koans.
Project Euler (Challenge)
You know what this is. It's a series of ever more difficult computational math problems that you can use to sharpen your knowledge of Python syntax.
Object oriented programming is the use of metaphorical "objects" to represent concepts. Objects are bundles of data and behavior (colons : denote data, octothorpes # denote behavior). For instance, a Dog has a :fur_color and can #bark. Sometimes its behavior modifies its data. For instance, if a Dog #eats, it becomes :well_fed.
In typical object oriented languages, the kinds of behaviors and data that an object possess are defined by something called a class. A class defines the types of behaviors and data contained within an object of its type, also known as an instance of that class.
In some sense, it's like a cookie cutter. Each additional cookie you cut with that shape is an instance of that class, and each of those cookies can be different. Their states can be different (baked or not), their data could be different (decorated differently), and their behavior can also be different depending on its state.
Context for below: We had been talking about his family farm and modeling the business aspects in code.
So instances of a FamilyFarm class could include a case_farm, a kung_farm, a lee_farm, etc. Within that FamilyFarm class, it might embed a Ledger class that keeps track of the account history, and an Almanac that makes predictions based on the account history (I know this is slightly wrong, but it's cute). Each of these classes embeds certain behaviors and data that serve a certain purpose (See Single Responsibility Principle). The Almanac does financial prediction, the Ledger houses the account history, and the FamilyFarm is the basic conceptual unit that we are seeking to model.
If this seems unrelated to the realization of a financial model or algorithm into code, you may be right. If you learn OOP, you'll learn a lot more organizational skills rather than algorithmic wizardry (see Organizational Skills Beat Algorithmic Wizardry), but they'll be skills you can take elsewhere that are valuable to collaboration, organizations, and the discipline of software engineering. You can always learn algorithms by doing Project Euler. But I recommend learning at least a little bit of OOP in order to make your code usable and easily understandable, both to future collaborators and coworkers alike.
Building Skills in Object-Oriented Design (Long, Challenge)
This book seems really cool and totally free. It goes through gradually more difficult OO modeling problems. I'm thinking of reading through it, myself. This is also the challenge.
Anyway, those are my thoughts as they stand. Let me know what you think, and if you run into any snags, let me know! I'd be glad to work on pretty much anything with you.
Some additional resources, recommended by TJ. You'll definitely read the docs while coding, and you should also know the style and spirit in which Python is written. I've added the style guides and "The Zen of Python" for the latter two considerations.