Re: Newbie edit/compile/run cycle question
Op Mon, 10 Dec 2007 16:00:04 -0800, schreef Matimus: better written: python -mpy_compile FILENAME The -m option doesn't work in all versions of cpython (I think since v2.4, or maybe 2.3?). -- JanC -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Jeremy C B Nicoll a écrit : Bruno Desthuilliers [EMAIL PROTECTED] wrote: Jeremy C B Nicoll a écrit : Figuring out how IDLE works is a bit beyond me at this stage. Did you try out, or is it just an a priori ? Sort of, no and yes... A few weeks ago I started trying to use Python IDLE and found a bug (which I reported on idle-dev). In the course of discussing that I found out that the whole IDLE source was present in \idlelib which I hadn't realised, FWIW, Python is free software, and you have access to all sources - C and Python - of the python exe and standard lib. and did look at it. But for a Python newbie (if not a programming newbie) it's too much to understand. Mmm... Possibly, yes. OTHO, I know from experience that reading other peoples code is a good way to learn. Working mostly with free softwares myself, I often use the source as documentation... -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
On Dec 8, 6:45 pm, Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Steve Howell [EMAIL PROTECTED] wrote: --- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: What command (in XP) does one need to issue to syntaxcheck a saved python script without running it? Perhaps oversimplifying a bit, running python does a syntaxcheck, and if it passes, moves on the next steps of interpretation/execution. Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. I don't know of a command line tool to do that, but I hasten to point out that you have the source code of IDLE available so you could just figure out what it's doing and encapsulate that in a script. Regards, ~Simon -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Bruno,
Please explain why the NOP import is a GoodThing. Use small words
please. I'm not as young as I used to be.
I didn't know about reload(), but now that I'm informed on that point
I'm still using
os.remove('foo.pyc')
reload(foo)
A single command to do that would be nice.
Martin
Bruno Desthuilliers wrote:
[EMAIL PROTECTED] a �crit :
Thanks for all the help. Thought I'd spend my newbie days right in the
Python shell (there's lots to test when you're just starting) but I
guess that's not going to happen.
Everyone told me to get out of the Python shell, one way or another.
Everyone told you to not use the shell that way - which is not exactly
the same thing. The shell is just great for exploring things. Like
quicly testing APIs, expressions, syntax etc before or while coding, or
inspecting the state after execution of your code (using the -i option),
etc... A common (AFAICT) practice is to have some 'test setup' code in
a .py file, that you use to import the modules under test and init a
couple vars, then launch this script with the -i option. Emacs
python-mode let you start a python shell in another frame, and eval
either your whole file or just parts of it in this shell.
OK. But this means that every execution must first load Python, then
import my stuff.
Just like it does with Java - but it might be much faster.
Import becoming a NOP after first use in the shell is
a six-legged feature, at best.
import becoming (almost) a NOP after first effective import is the
RightThing(tm) to do. If you want to reload a module, you have to ask
for it explicitely - using reload(module). But this won't affect already
instanciated objects, and can lead to very strange situations - hence
the common pattern of the setup script + the -i option.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] wrote:
Bruno,
Please explain why the NOP import is a GoodThing. Use small words
please. I'm not as young as I used to be.
Because otherwise every import would result in overhead without any benefit.
Think of a module like this:
A_GLOBAL_VARIABLE = extremely_costly_initialization_of_cache_contents()
You only want that to happen once.
I didn't know about reload(), but now that I'm informed on that point
I'm still using
os.remove('foo.pyc')
reload(foo)
A single command to do that would be nice.
You can create your own function that does this.
def better_reload(module):
import os
if os.path.exists(module.__file__) and module.__file__[-3:] == 'pyc':
os.remove(module.__file__) # attention - you might want more checks
reload(module)
Then you can put that into a file, e.g.
~/.pythonrc
and point the environment-variable PYTHONSTARTUP to that file.
Diez
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] a écrit :
Bruno,
Please explain why the NOP import is a GoodThing. Use small words
please. I'm not as young as I used to be.
Each module that need access to another module must explicitely import
it. This means that, in a typical program, your main script will import
a couple modules, each importing other modules, etc. Chances are that
some modules - and not necessarily light-weight ones - may end up being
imported dozens or more times.
Now the import statement does 2 things : first load the module, then
inject it in the current namespace. Obviously, the costly operation is
the first one, and obviously it doesn't need to be done more than once
for a given process. I'd even say it should *not* be done more than once
for a given process, since reloading a module doesn't affect objects
using the already existing code.
So caching the module on first import is obviously the right thing to do.
I didn't know about reload(), but now that I'm informed on that point
I'm still using
os.remove('foo.pyc')
reload(foo)
Mmm... I stopped using the reload function many years ago - in practice,
it's the perfect way to go on wild goose chase for bugs that don't
even exist - but IIRC, you shouldn't have to manually remove the .pyc file.
A single command to do that would be nice.
That was the purpose of the reload function AFAICT. Now it has proven to
be such a disaster in practical use that everyone and her sister found
better ways - like the ones that have already been suggested here.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Simon Forman [EMAIL PROTECTED] wrote: On Dec 8, 6:45 pm, Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. I don't know of a command line tool to do that, but I hasten to point out that you have the source code of IDLE available so you could just figure out what it's doing and encapsulate that in a script. I was afraid someone would suggest that. Figuring out how IDLE works is a bit beyond me at this stage. I note the idea posted by Jan Claeys involves running a working python program which manages the compile process, which is an approach I'd not have thought of in a hurry. My experience of other languages' compilers has never been like this, eg to compile a Fortran program I would not expect to run a Fortran program that calls the compiler, IYSWIM. -- Jeremy C B Nicoll - my opinions are my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Jeremy C B Nicoll a écrit : Simon Forman [EMAIL PROTECTED] wrote: On Dec 8, 6:45 pm, Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. I don't know of a command line tool to do that, but I hasten to point out that you have the source code of IDLE available so you could just figure out what it's doing and encapsulate that in a script. I was afraid someone would suggest that. Figuring out how IDLE works is a bit beyond me at this stage. Did you try out, or is it just an a priori ? -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
python -c import py_compile; py_compile.compile(r'FILENAME') ... where FILENAME is the filename of the python script you want to check. What this does in practice is (trying to) compile the source, and any errors or warnings will be reported. better written: python -mpy_compile FILENAME also see compileall Matt -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Bruno Desthuilliers [EMAIL PROTECTED] wrote: Jeremy C B Nicoll a écrit : Figuring out how IDLE works is a bit beyond me at this stage. Did you try out, or is it just an a priori ? Sort of, no and yes... A few weeks ago I started trying to use Python IDLE and found a bug (which I reported on idle-dev). In the course of discussing that I found out that the whole IDLE source was present in \idlelib which I hadn't realised, and did look at it. But for a Python newbie (if not a programming newbie) it's too much to understand. -- Jeremy C B Nicoll - my opinions are my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
On Dec 9, 1:26 pm, [EMAIL PROTECTED] wrote: Thanks for all the help. Thought I'd spend my newbie days right in the Python shell (there's lots to test when you're just starting) but I guess that's not going to happen. It would be a shame not to use the shell. Everyone told me to get out of the Python shell, one way or another. OK. But this means that every execution must first load Python, then import my stuff. Import becoming a NOP after first use in the shell is a six-legged feature, at best. Don't jump to conclusions too early. In the shell, type 'help(reload)'. This might help. -- Arnaud -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Thanks for all the help. Thought I'd spend my newbie days right in the Python shell (there's lots to test when you're just starting) but I guess that's not going to happen. Everyone told me to get out of the Python shell, one way or another. OK. But this means that every execution must first load Python, then import my stuff. Import becoming a NOP after first use in the shell is a six-legged feature, at best. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] a écrit : Thanks for all the help. Thought I'd spend my newbie days right in the Python shell (there's lots to test when you're just starting) but I guess that's not going to happen. Everyone told me to get out of the Python shell, one way or another. Everyone told you to not use the shell that way - which is not exactly the same thing. The shell is just great for exploring things. Like quicly testing APIs, expressions, syntax etc before or while coding, or inspecting the state after execution of your code (using the -i option), etc... A common (AFAICT) practice is to have some 'test setup' code in a .py file, that you use to import the modules under test and init a couple vars, then launch this script with the -i option. Emacs python-mode let you start a python shell in another frame, and eval either your whole file or just parts of it in this shell. OK. But this means that every execution must first load Python, then import my stuff. Just like it does with Java - but it might be much faster. Import becoming a NOP after first use in the shell is a six-legged feature, at best. import becoming (almost) a NOP after first effective import is the RightThing(tm) to do. If you want to reload a module, you have to ask for it explicitely - using reload(module). But this won't affect already instanciated objects, and can lead to very strange situations - hence the common pattern of the setup script + the -i option. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] schrieb: Thanks for all the help. Thought I'd spend my newbie days right in the Python shell (there's lots to test when you're just starting) but I guess that's not going to happen. Everyone told me to get out of the Python shell, one way or another. OK. But this means that every execution must first load Python, then import my stuff. Import becoming a NOP after first use in the shell is a six-legged feature, at best. Being a Java-guy you might thing that starting a runtime environment is a costly operation. Trust me - with python it isn't. Starting the python runtime usually takes fractions of a second. If you want to work with the REPL (read/evaluate/print-loop), make sure you install rlcompleter2. Google for it - it makes working with the interpreter much easier. However, I also recommend you to use small scriptlets to test out things - I always have a shell open, and with alt-tab switch to it. Arrow-Up gives me the last commandline (e.g. python /tmp/test.py) - and then hitting return will execute it. This costs about 2-3 seconds, and spares me the troubles of misspellings in larger statements and the like. And some of the nastier aspects of reload (google for reload and my name to see a recent thread why I don't recommend it) Diez -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Steve Howell [EMAIL PROTECTED] wrote: --- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Steve Howell [EMAIL PROTECTED] wrote: --- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: What command (in XP) does one need to issue to syntax check a saved python script without running it? Perhaps oversimplifying a bit, running python does a syntax check, and if it passes, moves on the next steps of interpretation/execution. Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. What's your normal text editor? You might want try googling to see if it has a Python mode. Also, look into seeing if it has a way to automatically invoke external programs. Mansfield Software's Kedit, but that's not the problem. You said that running python does a syntax check and then goes on to run the program. I would want to replicate IDLE's check process which syntax checks a program and then, even if it is ok, doesn't go on to run it. I see nothing on the python.exe CLI options that offers that. The only way I can think of doing it is to copy the file to be syntax-checked to a temporary file (presumably in the same directory though, or search paths won't be right) and append a line with a guaranteed syntax error in it, then ask python to 'execute' the dummy file. If the original file was ok then it will fail the syntax check on the final deliberate-error line, whereas, obviously any other syntax error is a genuine one. But that seems a crazy way to go about things. -- Jeremy C B Nicoll - my opinions are my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Op Sun, 09 Dec 2007 01:11:28 +, schreef Jeremy C B Nicoll: What command (in XP) does one need to issue to syntax check a saved python script without running it? Does a syntax check report all syntax errors or just the first one found? python -c import py_compile; py_compile.compile(r'FILENAME') ... where FILENAME is the filename of the python script you want to check. What this does in practice is (trying to) compile the source, and any errors or warnings will be reported. -- JanC -- http://mail.python.org/mailman/listinfo/python-list
Newbie edit/compile/run cycle question
I'm a java guy used to the effective edit/run cycle you get with a good IDE. Today I'm writing my first Python, but can't seem to find the way to use Python's inherent edit/run cycle. I edit my source, import it into Python, run it. Fine. Then I edit again, but the next import doesn't notice that a new compile is needed. I'm making a little progress (very little) by exiting/ reentering Python after each edit. Ugh. What don't I know that I should know to just edit/run, preferably at the tap of a function key? -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] a écrit : I'm a java guy used to the effective edit/run cycle you get with a good IDE. Today I'm writing my first Python, but can't seem to find the way to use Python's inherent edit/run cycle. I edit my source, import it into Python, run it. Fine. Then I edit again, but the next import doesn't notice that a new compile is needed. This is not an accurate definition of what happens. The import mechanism keeps already imported modules in cache (for obvious reasons). wrt/ notice(ing) a new compile is needed, it's not the import mechanism's duty, but the VM one's. I'm making a little progress (very little) by exiting/ reentering Python after each edit. Ugh. Java doesn't have an interactive shell, so there's no real parallel here, but anyway: with Java, you have to restart a Java VM each time you run your code. Why do you hope something else with Python ? What don't I know that I should know to just edit/run, Do what you would do with Java: $ python yourprogram.py Or if you want to inspect the state after execution (something you can't do with Java): $ python -i yourprogram.py preferably at the tap of a function key? Use an IDE then. Or a real code editor like emacs - it's python-mode is way more powerful than what I saw in any IDE. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
--- [EMAIL PROTECTED] wrote: What don't I know that I should know to just edit/run, preferably at the tap of a function key? Most good editors let you do these things: 1) Save a file. 2) Run a script from the shell. 3) Turn steps 1 and 2 into a macro. 4) Allow you to map the function key to a macro. It really depends more on the editor than the programming language. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
--- Bruno Desthuilliers [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] a écrit : I'm a java guy used to the effective edit/run cycle you get with a good IDE. Today I'm writing my first Python, but can't seem to find the way to use Python's inherent edit/run cycle. Use an IDE then. Or a real code editor like emacs - it's python-mode is way more powerful than what I saw in any IDE. Martin, for Python-specific IDEs, I recommend looking at the following page, although I think you might want to get some feedback from the list as well: http://c2.com/cgi/wiki?PythonIde Having said that, I'm more in Bruno's camp that the choice of an editor usually transcends Python. I prefer to use a powerful editor that's good for working on several languages, as long as it has a good Python mode. There are a zillion powerful editors out there. I've been productive in EditPlus, MultiEdit, SlickEdit, vim, and emacs, just to throw out a few examples. I'm confident you'll find a solution that fits your style, and you are obviously doing a good thing in terms of optimizing edit/run cycle, as it's pretty key to productivity. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] | What don't I know that I should know to just edit/run, preferably at | the tap of a function key? In IDLE, which come with Python, it is F5. (See Options/General/Autosave) Startup is about .1 sec since the program runs in a window of the same interpreter. Stand-alone editors require longer to start a separate interpreter, but then you have a clean new interpreter that is not running TK or anything else. Your choice. Have fun. If you run a separate interpreter, you might benefit from also having an interactive interpreter window open in which to run quick experiments to check names or syntax you are not sure of. This comes with running idle. tjr -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Steve Howell [EMAIL PROTECTED] wrote: There are a zillion powerful editors out there. I've been productive in EditPlus, MultiEdit, SlickEdit, vim, and emacs, just to throw out a few examples. What command (in XP) does one need to issue to syntax check a saved python script without running it? Does a syntax check report all syntax errors or just the first one found? -- Jeremy C B Nicoll - my opinions are my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
--- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Steve Howell [EMAIL PROTECTED] wrote: There are a zillion powerful editors out there. I've been productive in EditPlus, MultiEdit, SlickEdit, vim, and emacs, just to throw out a few examples. What command (in XP) does one need to issue to syntax check a saved python script without running it? Perhaps oversimplifying a bit, running python does a syntax check, and if it passes, moves on the next steps of interpretation/execution. Does a syntax check report all syntax errors or just the first one found? Just the first one. In practice, you end up fixing them one at a time anyway, so this works for me, as long as I have a fluid way to call out to python and return to the editor. Looking for last minute shopping deals? Find them fast with Yahoo! Search. http://tools.search.yahoo.com/newsearch/category.php?category=shopping -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
Steve Howell [EMAIL PROTECTED] wrote: --- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: What command (in XP) does one need to issue to syntax check a saved python script without running it? Perhaps oversimplifying a bit, running python does a syntax check, and if it passes, moves on the next steps of interpretation/execution. Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. Does a syntax check report all syntax errors or just the first one found? Just the first one. In practice, you end up fixing them one at a time anyway, so this works for me, as long as I have a fluid way to call out to python and return to the editor. Yes, I suppose so. -- Jeremy C B Nicoll - my opinions are my own. -- http://mail.python.org/mailman/listinfo/python-list
Re: Newbie edit/compile/run cycle question
--- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: Steve Howell [EMAIL PROTECTED] wrote: --- Jeremy C B Nicoll [EMAIL PROTECTED] wrote: What command (in XP) does one need to issue to syntax check a saved python script without running it? Perhaps oversimplifying a bit, running python does a syntax check, and if it passes, moves on the next steps of interpretation/execution. Ah, I've been using IDLE so far (but would probably prefer to write Python in my normal text editor). In IDLE Alt-X syntax checks the saved copy of the file being edited (at least it seems to), and I was wondering how to replicate that elsewhere. What's your normal text editor? You might want try googling to see if it has a Python mode. Also, look into seeing if it has a way to automatically invoke external programs. Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs -- http://mail.python.org/mailman/listinfo/python-list
