Couple of noobish question
bdesth.quelquechose at free.quelquepart.fr
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:
if os.uname() == "Linux":
return "this is the Linux version"
return "this is not the Linux version"
something = some_module.something
# some_module not installed
something = "default"
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