[Tutor] Apparent incosistency with Python interperter in IDLE

[Luke Paireepinart]

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.