python可以像c一样编写应用程序吗_如何“真实” python程序员工作？

Hello,

Let me start by saying that I am coming from a background using Matlab

(or Octave), and C++. I am going to outline the basic nuts-and-bolts

of how I work in these languages, and ask for some help to find out how

the same thing is done in Python. I am not sure what the standard is.

In C++, I open up an editor in one window, a Unix shell in another. I

write the code in the editor, then switch to the shell window for

compile and run. I then go back to the editor for modifications, and

then compile and run in the shell window.

In Matlab, I do much the same thing, except there is no compile phase.

I have the editor on one window, the Matlab interactive shell in the

other. I often make a bunch of small scripts for exploration of a

problem, before writing any larger apps. I go back and forth editing

the current file, and then running it directly (Matlab looks at the

time stamp, and automagically reloads the script when I modify it).

In Python, there seems to be a couple ways of doing things. I could

write it in one window, and from a Unix shell call

python myscript.py

and be like C++, but then I lose the interactiveness which makes

prototyping easier. If I use the python shell, I can use import (and

reload), or execfile perhaps.

How do experienced python programmers usually do it? Is there a

"usually" about it, or is it up to personal taste? Are there any

convenient ways of doing these things?

I realize this is a pretty newbie question, but it could possibly save

me hours of time if there is a better way to work.

thanks,

Brian Blais

解决方案On 12 Jan 2006 12:20:50 -0800

"bblais" wrote:

Hello,

Let me start by saying that I am coming from a background using Matlab

(or Octave), and C++. I am going to outline the basic nuts-and-bolts

of how I work in these languages, and ask for some help to find out

how the same thing is done in Python. I am not sure what the

standard is.

In C++, I open up an editor in one window, a Unix shell in another. I

write the code in the editor, then switch to the shell window for

compile and run. I then go back to the editor for modifications, and

then compile and run in the shell window.

In Matlab, I do much the same thing, except there is no compile phase.

I have the editor on one window, the Matlab interactive shell in the

other. I often make a bunch of small scripts for exploration of a

problem, before writing any larger apps. I go back and forth editing

the current file, and then running it directly (Matlab looks at the

time stamp, and automagically reloads the script when I modify it).

In Python, there seems to be a couple ways of doing things. I could

write it in one window, and from a Unix shell call

python myscript.py

and be like C++, but then I lose the interactiveness which makes

prototyping easier. If I use the python shell, I can use import (and

reload), or execfile perhaps.

How do experienced python programmers usually do it? Is there a

"usually" about it, or is it up to personal taste? Are there any

convenient ways of doing these things?

I realize this is a pretty newbie question, but it could possibly save

me hours of time if there is a better way to work.

thanks,

Brian Blais

Well, I think it will depend on your project ...

If you''re developing GUI application, you will have trouble using the

python shell. At least you will need a special, customized shell that

will take care of launching the main loop of your GUI and let you enter

commands. But I don''t think this is a big help to build GUI ...

Now, what I do for other stuffs (or when I have access to such a

modified shell). First, when I develop an object, I quit and

reload my script after each modification, mainly because problems

arises quickly with different variables with difference version of the

same class and you have no way to exactly know what variable hold what

version of the class. However, when I''m developing algorithms I reload

the modules while keeping the shell launched. Only at the very end do I

quit and relaunch to be 100% sure my algorithm is working with the

new versions of the modules ...

Pierre

--

You will overcome the attacks of jealous associates.

bblais wrote:In Python, there seems to be a couple ways of doing things. I could

write it in one window, and from a Unix shell call

python myscript.py

and be like C++, but then I lose the interactiveness which makes

prototyping easier. If I use the python shell, I can use import (and

reload), or execfile perhaps.

or "python -i myscript.py" which runs the script then leaves you in the

interpreter.

On Thu, 12 Jan 2006, bblais wrote:

In Matlab, I do much the same thing, except there is no compile phase. I

have the editor on one window, the Matlab interactive shell in the

other. I often make a bunch of small scripts for exploration of a

problem, before writing any larger apps. I go back and forth editing

the current file, and then running it directly (Matlab looks at the time

stamp, and automagically reloads the script when I modify it).

I wouldn''t describe myself as an experienced programmer, but this is

definitely how i work - editor plus interactive interpreter, using

import/reload to bring in and play with bits of of code.

Towards the end of coding a program, when i''m done with the inner

functions and am working on the main function, which does stuff like

command line parsing, setting up input and output, etc, i''ll often leave

the interpreter and work from the OS shell, since that''s the proper

environment for a whole program.

Often, i''ll actually have more than one shell open - generally three: one

with an interpreter without my code loaded, for doing general exploratory

programming, testing code fragments, doing sums, etc; one with an

interpreter with my code loaded, for testing individual components of the

code, and one at the OS shell, for doing whole-program tests, firing up

editors, general shell work, etc.

Another trick is to write lightweight tests as functions in the

interpreter-with-code-loaded that reload my module and then do something

with it. For example, for testing my (entirely fictional) video

compressor, i might write:

def testcompressor():

reload(vidzip)

seq = vidzip.ImageSequence((640, 480))

for i in xrange(200):

frameName = "testmovie.%02i.png" % i

frame = Image.open(frameName)

seq.append(frame)

codec = vidzip.Compressor(vidzip.DIRAC, 9)

codec.compress(seq, file("testmovie.bbc", "w"))

Then, after editing and saving my code, i can just enter

"testcompressor()" (or, in most cases, hit up-arrow and return) to reload

and test. You can obviously extend this a bit to make the test routine

take parameters which control the nature of the test, so you can easily

test a range of things, and you can have multiple different test on the go

at once.

tom

--

Only men''s minds could have mapped into abstraction such a territory