Couple of noobish question

Bruno Desthuilliers bdesth.quelquechose at
Wed Feb 4 16:49:53 EST 2009

Catherine Heathcote a écrit :
> Firstly hi, I don't know any of you yet but am picking up Python and 
> will be lurking here a lot lol. I am a hobbiest coder (did 3 out of 4 
> years of a comp tech degree, long story) and am learning Python, 'cos I 
> saw some code and it just looks a really nice language to work with. I 
> come from C++, so I am bound to trip up trying to do things the wrong way!
> I have been working with Project Euler to get the hang of Python, and 
> all goes well. I have an idea for a small project, an overly simplistic 
> interactive fiction engine (well more like those old choose your own 
> adventure books, used to love those!) that uses XML for its map files.

You may have good reasons to choose this format, but FWIW, some (most ?) 
of us here tend to prefer "lighter" formats like json or yaml, or even 
just plain Python source. But, well, just so you know there are possible 
alternatives to XML !-)

> The main issues I see so far is the XML parsing (I should pick that up 
> ok, I have a blackbelt in google-foo), but more importantly splitting 
> code files.


Oh, you mean, how to organize your source code ?

> In C++ I would obviously split .cpp and .h files, pairing them up and 
> using #include. How do I do this in Python? I see that you don't tend to 
> split logic from defenition,


First thing you must know: in Python, almost everything happens at 
runtime (the only error you might get at compile time is SyntaxError), 
and "import", "class" and "def" are actually executable statements. That 
is, when a module (or main program FWIW) is first loaded (directly for 
the main program, via an import statement for other modules), all the 
top-level code of the corresponding source file is executed 
sequentially. One of the implications is that there's no need for 
preprocessor directives - you just use Python code (at the module 
top-level) to have alternative versions of a function or conditional 
imports (which BTW are _not_ the same as #include directives ). Like:


import os

if os.uname()[0] == "Linux":
    def somefunc():
        return "this is the Linux version"
    def somefunc():
        return "this is not the Linux version"

   import some_module
   something = some_module.something
    # some_module not installed
   something = "default"

# etc...

To make a long story short: your notions of "definition" and "logic" 
don't really apply here.

>  but how do I keep different classes in 
> different files? 

You don't necessarily have to keep you class in "different files" - it 
really depends on the project's complexity. If you only have a couple 
classes, functions and (pseudo)constants, you just stick them either in 
the main program file (if it's a simple script) or in a module. If it 
gets a bit more complex, regroup classes and functions in distinct 
modules or packages trying to make each module (or package) as cohesive 
and decoupled as possible. Just have at look at the modules and packages 
in the stdlib to see what it may looks like.

> My google-fu fails me so far.

You were probably lokking for this:

My two cents...

More information about the Python-list mailing list