[Tutor] Re: Thanks for your help :-)

[Rob McGee]

On Wed, Nov 28, 2001 at 04:58:51PM -0800, Kirby Urner wrote:
> >batch file solution that you provided, seems to be a Windows thing, not a 
> >Linux/Unix thing. Will this hinder my ability to produce cross platform 
> >applications?
> >I know this question is very advanced but I would like to get it right, up 
> >front.
> 
> Linux is similar, except you can use ! "bang" notation at the top
> of a program to tell the OS what interpreter to use.  Then you
> can make the programs executables directly, so a single command
> (the name of the program), with optional arguments, will work.

Actually there is Windows trickery to do this as well, involving some
registry editing. You tell the registry that a .py extension is to be
executed with the Drive:\path-to\python.exe interpreter.

I can't help with details because I don't even have a Windows system
available to me. But I think you can do the registry editing in that
"file types" tab -- I can't remember what main dialog it's attached to
but perhaps you or someone else has seen it before.

> >4) Also, I would like to distribute my apps standalone.
> 
> You'll have to bundle your app with the Python interpreter if
> you can't assume the target machines have Python installed.

Note that you can't distribute the same package for Windows and Linux.
You should also be aware that there are issues with using pre-compiled
binary packages on different GNU/Linux distributions. The UNIX standard,
which works with almost every UNIX-like flavor, is to distribute source
code packages. A binary package might not even work on other systems of
the same distro and version!

My advice is to make your standalone package for Windows only. For your
GNU/Linux users, just give them the script and information about python.
Every major distribution includes a package for python, so most users
probably already have it.

> >5) I also have some question related to how to approach a PYTHON 
> >project(taking into consideration OO). I would like to produce re-usable 
> >code, instead of one time only code.
> 
> As a learner, you should accept the idea of writing lots of
> throwaway code, useful for the learning process, but not
> necessarily worth keeping as is.

I do accept that, Kirby. :) But it's still a good question. I think what
he meant was not that his code was of such high quality, but that he
wants to minimize work over the long term.

For the answer I would have to defer to someone more knowledgeable in
python, but the idea is to save your reusable routines in one or more
.py files separate from your project at hand. Then you import them:
    import [path-to]myRoutines
and you call them with the filename as a prefix:
    duh = myRoutines.helloWorld
    print duh
    approval = myRoutines.getInput('Did you like that?', '(y/n)')
    if approval == 'y':
      print "Great, there's more where that came from."
    elif approval = 'n':
      print "You're no fun."
    else:
      print 'Can\'t you follow simple directions? Type "Y" or "N"!!'

As time goes on and you learn more you can go in and edit myRoutines.py.
If parameters and input formats remain compatible you won't have to edit
the programs which depend on myRoutines. But as you get better ideas,
such as for a new parameter for your getInput() function, you'll break
your old code which is missing the parameter. So perhaps Kirby's right
and at this point it's not worth the trouble to modularize your work.
Again, the judgement of more experienced Python people should be given
more consideration than mine.

    Rob - /dev/rob0