[Tutor] Apparent incosistency with Python interperter in IDLE
Luke Paireepinart
rabidpoobear at gmail.com
Thu Jun 18 23:23:33 CEST 2009
Karen Palen wrote:
> WOW! Thanks for the detailed explanation!
>
Sure thing, putting off doing homework so...
> This was about what I had expected so it is no surprise.
>
> My conclusion (so far) is that there is not much to gain from an IDE in this situation and a lot of complexity to deal with.
>
You'd be surprised how many people write Python without an IDE at all.
I end up doing most of my work just in an editor with syntax
highlighting (such as Notepad ++) and setting my f5 to run my Python
program in a new window. That circumvents all the issues IDEs have with
their stdout, as well as some other issues IDLE has (namely, if IDLE
can't create a subprocess (which it is the default behavior on windows
not to) and you run a program, all variables and imports will hang
around for the next program run. therefore you can have the line
"import os" then run your program, remove the line, and run it again,
and even if you use methods from the "os" module, your code will still
work fine... that is, until you restart IDLE.)
> Clearly I will have to deal with stdin and stdout as part of any real app however.
>
Python makes it really easy to deal with stdin and stdout - they are
just generic File objects. Since Python does Duck Typing (anything that
walks like a duck and quacks like a duck may as well be a duck), you can
place any class into stdin and stdout that has the common File methods
(write, writeline, read, readline, etc.) You don't even have to inherit
the class from File. You can make an entirely new class, so long as it
implements the common methods. That's one of the beauties of Python.
so you can do something like
class GUIStdOut(object):
def write(self, data):
#draw data in your GUI
self.stdout = GUIStdOut()
and then you can
print "Hello, World!"
and it will show up in your GUI.
> The intended app is to run a mono based subprocess (yes I know, but it is too big to change) and then control it through a pipe with stdin and stdout.
>
>
> It looks as I I will just have to write something in C#/mono to echo my commands for testing then go from there.
>
> At the moment it looks like the straight Python interpreter plus Gedit/PDB will be the tools of choice.
>
Yes, those are perfectly suitable tools. You may find an IDE that you
like later, but just using editors are fine. One thing I do miss about
IDEs is the printing of the method docstrings while you're typing, but
you can get plugins to do that for most editors, I believe.
> I am using Python 301 because this is a brand new project and I don't want to have to convert 6 months or so down the road.
>
> Can you suggest a better strategy?
>
No, Python 3 is probably a better bet in the long run. Just be wary of
it in regard to other libraries - most 3rd party libraries do not work
on Python 3 yet (Python 3 broke backward compatibility). So if you have
to use any of those libraries, you're going to end up having to use 2.6.
I'm personally not moving to Python 3 until all the libraries I use
support it, even if I'm not using one of said libraries for a specific
program.
More information about the Tutor
mailing list