In your situation it's perfectly reasonable to study IronPython (especially as this book does a great job helping you do that!). You'll have access to essentially all of Python 2.5 functionality (not sure when IronPython will upgrade to a 2.6 version of Python, but 2.5 is already quite usable), plus all the .Net libraries and assemblies you know and love, and tools such as Visual Studio add-ins.
The differences between CPython and IronPython (and Jython, for that matter, which applies the same concept as IronPython to the JVM -- Jim Hugunin was the originator of Jython long before he moved to Microsoft where he originated IronPython, both projects now thrive) are chiefly in garbage collection and threading: IronPython and Jython rely on their underlying platforms (so, you get mark-and-sweep garbage collection and free threading), CPython rolls its own (so, it's mostly reference-count GC, with mark-and-sweep once in a while to resolve reference loops, and threading hampered by a global interpreter lock).
A well-coded Python script does not rely on the implementation details in question (it never assumes that GC happens immediately, never assumes that an operation is atomic under threading except for the few, like Queue.Queue's methods, that are explicitly documented to be), but of course there's plenty of scripts out in the wild that are sloppy. For example:
data = open('x.txt').read()
this leaves the file object open until it's garbage collected; in a reference-count environment the collection happens immediately (so the file gets closed ASAP), in a mark-and-sweep environment that is not the case (so the process using such constructs often would erroneously keep some files, maybe many files, uselessly open for far longer than they need to be, wasting system resources &c).
So, proper Python coding is instead:
# needed in 2.5, unneeded but innocuous in 2.6
from __future__ import with_statement
with open('x.txt') as f: data = f.read()
which does guarantee immediate closure of the file in every implementation (the with statement is very very handy that way;-).
This doesn't affect your learning of Python, nor does it impede reuse of properly-coded Python code, but if and when you want to reuse sloppily-coded Python code (especially in a long-running server, service, daemon process, &c) you may in the future need to do some tightening up thereof. So, btw, will people who want to use newer and better CPython versions, such as Unladen Swallow &c, once those versions implement better garbage collection mechanisms, get rid of the GIL, and other enhancements; hopefully this is already changing the "culture" of the Python community towards more correct, less sloppy coding, but of course there's bazillions of lines of old sloppy code around, so some care is needed;-).