Python/C and PYTHONPATH

[Samuel Walters]

Ack...  definitely not pep-7 compliant code

And to think...  A co-worker once called me "obsessive" about indention.
(They say "obsessive," I say "consistent and legible.")

Well, It seems PAN likes to perform a stealth word-wrap when you edit from
the non-attached editor. (I used vim because I'm comfy hammering out code
there)  Nope, on second look, I must have accidentally mashed some keys
while in vim.  That extraneous "else" block is just a copy of the "else"
block.

If you run it through indent, and clean up a couple of oddball line-wraps
it will at least be legible. Remove the unneeded prototypes, embarrassing
extra else block, and it will compile. Remove the whole block about
searching for the = and fix the typo in the second setenv call (extrapath
should be eventual_path) and it will run without segfault.  Then replace
the ";" with ":" and it will run properly on a linux system.  For myself,
I made the snippet a little more general and added the option of choosing
which pathlist env variable and changed the function name to
envPathAppend. Then it's not a bad little snippet.


|Thus Spake Tero Pihlajakoski On the now historical date of Tue, 06 Jan
2004 01:04:31 +0000|

> Here. I might not want to add ';' or ':', depending on the OS (probably
> not)? I can solve this with #ifdefs for WIN32 and Linux, but everytime I
> want to run it on a new system, I'd have to find out the delimiter... It
> also needs a buffer underrun check on that [1024]. I'll stick with the
> PyRun_... for now, but I'll definitely save this code, so thanks. Again.

That buffer overrun is not the only bit of braindead logic in that
snippet.  The "success/failure" condition testing leaves a couple of loose
ends.

> Also, found this piece from sys.path docs (now that my net is up and
> running):
>   ... "A program is free to modify this (sys.path) list for its own
> purposes." ...

Hmmm...  I suppose it's a matter of aesthetics and scope of the project
you're working on.  If you're writing a big program for which the python
interpretor is only one small or medium part of the functionality and the
majority is c/c++, then you're opening up a whole big realm of
cross-platform issues.  However, if the bulk of your code is python, then
perhaps you should have the main program be in python with your extra c
code as a module. That would be cleaner and probably more portable.

I suspect that at this point you're just trying to tinker with the
interface, then use what's most comfortable.  Now at least, you have an
option.  Besides, it seems that someone already posted a cleaner fix than
I could have given you.

HTH

Sam Walters.

-- 
Never forget the halloween documents.
http://www.opensource.org/halloween/
""" Where will Microsoft try to drag you today?
    Do you really want to go there?"""