[Tutor] Starting python from a DOS prompt from any directory?

[Daniel McQuay]

hello fellow programmers,

newbie question here and this isn't much a programming question as it is a
windows and python question, so sorry in advance.

i have been having what i think is a problem with running python on windows
from a DOS prompt. i am used to running python from a linux box where you
can just type "python" or "python24" from a shell prompt and the python
shell executes from any directory. now if i remember right, when used a
window 2000, i could break out a DOS prompt and type "python" from any
directory and it would execute the python screen where you could then begin
testing code. now i am using a windows xp media center edition laptop with
python 2.5 installed and when i go to run and then type "cmd" and then type
"python" from the directory where the run "cmd" command drops me it says
'python' is not a recognized as an internal or external command. i would
like to be able to just type "python" from any directory and have it run.
does any one know why it's doing this or how i can achieve running python
from just any directory. now i can navigate to the python folder and execute
python from there. but there seems to me to be a way to achieve what i want
to do.

sorry for such a newbie question but i would like to figure this out because
there are some situations where i need that to work from any directory.

thanks in advance,

--
Daniel McQuay
boxster.homelinux.org
H: 814.825.0847
M: 814-341-9013
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] XML-RPC data transfers.

[Kent Johnson]

Luke Paireepinart wrote:

> But the main strategy is to get the data out of the ImageGrab object.
> one way is stated above - use the save method to write to a file.
> another possible way is to create a filelike class, implementing 'tell' 
> 'seek' and 'write' methods, that just collects all the data written to 
> it and keeps it in memory
> rather than writing it out to a file.
> This is hinted at in the documentation for im.save():
> "You can use a file object instead of a filename. In this case, you must 
> always specify the format. The file object must implement the *seek*, 
> *tell*, and *write* methods, and be opened in binary mode."
> (I assume it means you can use a file-like object, also, but it's 
> possible that you can't, and I leave it to you to test that :) )

You can probably use a StringIO or cStringIO object instead of an actual 
file.

> a third solution is to convert the data to a string using
> *im.tostring().
> *send that over your connection, and use im.fromstring() on the other 
> end to recreate the image.

That sounds like a good plan too.

Kent

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] XML-RPC data transfers.

[Kent Johnson]

Chris Hengge wrote:
> if I'm trying to transmit a 'file' that is actually saved on the HD, the 
> code from the link in my first post works fine (reading in the file 
> using binary mode access). My problem is that I'm trying to figure out 
> how to transfer data that isn't yet saved to the drive, because I'm 
> wanting to be able to send any sort of data type across the connection. 
> This is getting rather frustrating because I'm getting so many replies 
> back that aren't even attempts at answers, but rather questions about 
> things I'm not trying to do. I'll restate the problem.
> 
> grab image data from server side connection.
> transfer image data to client side
> write image data to file on client side.
> 
> I've already established a working RPC connection, and if I transmit a 
> 'file' that can be read using binary mode (exact same code as posted in 
> both the link in my first email, and by others in this thread) it works 
> fine. My problem I'm trying to overcome is that I
> 
> ***do not want to write the image data from the server to a file, just 
> to send it, then delete the image file on the server***

I understand all that. What I want to know is, do you have code that 
does write the image data to a file and successfully send the file? 
Could you show that code so we can help you change it to what you want?

Or are you just sending a random file?

Kent

> 
> For this specific challenge, I've found no actual "how-to" help... Just 
> bits of information making it sound possible. Again, I dont want to 
> "file transfer" anything, I want to send data that isn't in the default 
> data-types for xml-rpc, which I've read can be done using binary mode 
> transfers.
> 
> On 12/30/06, *Kent Johnson* <[EMAIL PROTECTED] > 
> wrote:
> 
> Chris Hengge wrote:
>  > I might have been unclear, or this tid-bit might have been lost
> in the
>  > thread... but I'm trying to send directly from ImageGrab.Grab(),
> without
>  > saving the data as a file. Thats where I'm getting hung... If it
> try to
>  > send an actual stored file, I have no problem. Is this maybe
> impossible?
>  > My thought was that I could just save a little process time and file
>  > fragmentation if I cut out the middle man, plus there really is no
>  > reason to save the screen capture on the server side.
> 
> Can you show the code that works? If you are writing your image data to
> a file, then using something like Lee's example below, that just reads
> the file data into a Binary object, you should be able to just create
> the Binary object from the image data directly.
> 
> Kent
> 
>  >
>  > Maybe I really need to look into SOAP for this sort of stuff? I'm
> just
>  > playing with the technology, and from the searching I've done, the
>  > XML-RPC seemed to fit my needs best. I could certainly be wrong
> though.
>  >
>  > Thanks for both of you giving me feedback.
>  >
>  > On 12/29/06, *Lee Harr* <[EMAIL PROTECTED]
> 
>  > >> wrote:
>  >
>  >  >
> http://www.velocityreviews.com/forums/t343990-xmlrpc-send-file.html
>  > <
> http://www.velocityreviews.com/forums/t343990-xmlrpc-send-file.html>
>  >  >
>  >  >Using this example I get error's about 'expected binary
> .read(),
>  > but got
>  >  >instance instead.
>  >
>  >
>  > I assume you are using this ...
>  >
>  >  >d = xmlrpclib.Binary(open("C:\\somefile.exe").read())
>  >
>  >
>  > Are you using windows?
>  >
>  > I think you would need to pass the binary flag to open ...
>  >
>  > imagedata = open(filename, 'rb').read()
>  >
>  >
>  >
>  > It's probably a good idea to use the binary flag if you are
> expecting
>  > binary data just in case it gets ported somewhere else later.
>  >
>  >
>  >  >I've just been using xmlrpclib and simplexmlrpcserver for this,
>  > but I'm
>  >  >wondering if I should perhaps use twisted instead.
>  >
>  > I've used xml-rpc to send image data before. It worked.
>  >
>  > _
>  > Don't just search. Find. Check out the new MSN Search!
>  > http://search.msn.com/ 
>  >
>  > ___
>  > Tutor maillist  -  Tutor@python.org 
>  >
>  > http://mail.python.org/mailman/listinfo/tutor
>  >  >
>  >
>  >
>  >
>  >
> 

Re: [Tutor] XML-RPC data transfers.

[Chris Hengge]

First off, thanks for the info luke, I'll give these idea's a shot. Second,
I fully understand the wow factor from figuring out stuff on my own, but I
also work fulltime and attend roughly 20 credits of college a term, while
taking care of my family/homelife and this xmas break is one of the few
chances where I got time away from both work and from school, leaving just
my family and my freetime. All I'm trying to do is get the most of my time.
I also prefer examples as answers, not necessarily code... but something
more then "you need to figure out how to do X", because more often then not,
I've already come up with that possibility. However, that doesn't mean the
method is a good one. Much like your own answers to most of my questions,
you state several ways varying from "probably works" to "how I'd try to do
it". Personally, I'd rather understand more of the "how I know it works" so
that later as I get better I can fall back to working methods, and leave
myself open to creating my own ways as I stumble upon them, or have need for
a different approach. It's like cooking.. first you learn how to make a
pizza like everyone else, but after a while you get tired of eating that
pizza, so you make your own variation.

And yes, I'm still messing around with my VNC program, thats what this is in
relation too. I was just trying out XML-RPC because its suited for the job
best I can tell from what I've read and seen it used for. I've got most of
the projects features already done using plain sockets, this is just another
way I was trying, and if you check the other emails I've said a few reasons
why. As for twisted.. Thats next.. I even stated that it might be better,
and tossed it out for critic review, but nobody said otherwise so I figured
I was fine. (I started with sockets for simplicity, then XML-RPC is supposed
to be next easiest with twisted being last for my needs, also the most
overhead)

Anyways, I'll give your suggestions a shot and see what I come up with.

On 12/30/06, Luke Paireepinart <[EMAIL PROTECTED]> wrote:


Chris Hengge wrote:
> if I'm trying to transmit a 'file' that is actually saved on the HD,
> the code from the link in my first post works fine (reading in the
> file using binary mode access). My problem is that I'm trying to
> figure out how to transfer data that isn't yet saved to the drive,
> because I'm wanting to be able to send any sort of data type across
> the connection. This is getting rather frustrating because I'm getting
> so many replies back that aren't even attempts at answers, but rather
> questions about things I'm not trying to do. I'll restate the problem.
>
> grab image data from server side connection.
> transfer image data to client side
> write image data to file on client side.
>
> I've already established a working RPC connection, and if I transmit a
> 'file' that can be read using binary mode (exact same code as posted
> in both the link in my first email, and by others in this thread) it
> works fine. My problem I'm trying to overcome is that I
>
> ***do not want to write the image data from the server to a file, just
> to send it, then delete the image file on the server***
>
And how...

It's clear what you're trying to do.
The problem is this:

1) ImageGrab.grab() -> returns image object that has a 'save' method.
You use this method with the following syntax
import Image, ImageGrab
im = ImageGrab.grab()
im.save('filename.jpg')

to save the file .
2)
you read back in the file by doing:
f = file('filename.jpg','rb')
contents = f.read()


3)
you send it with this:
xmlrpclib.Binary(contents)


What you're trying to do is to eliminate step 1 and 2, so that you read
the ImageGrab's data directly into the xmlrpclib.Binary method call
without having to write a file.

Okay.
So the main problem we're having here is that you seem to think that you
should be able to send the ImageGrab object itself over the connection.
What is the problem is that xmlrpclib doesn't understand these class
instances.  you need to give it plain binary data that it can send.
So there's a few ways you can go about this.

But the main strategy is to get the data out of the ImageGrab object.
one way is stated above - use the save method to write to a file.
another possible way is to create a filelike class, implementing 'tell'
'seek' and 'write' methods, that just collects all the data written to
it and keeps it in memory
rather than writing it out to a file.
This is hinted at in the documentation for im.save():
"You can use a file object instead of a filename. In this case, you must
always specify the format. The file object must implement the *seek*,
*tell*, and *write* methods, and be opened in binary mode."
(I assume it means you can use a file-like object, also, but it's
possible that you can't, and I leave it to you to test that :) )

a third solution is to convert the data to a string using
*im.tostring().
*send that over your connection, and use im.fromstring() on the other
end to recreat

Re: [Tutor] XML-RPC data transfers.

[Luke Paireepinart]

Chris Hengge wrote:
> This works...
> d = xmlrpclib.Binary(open("C:\\somefile.exe", "rb").read())
>
> What I need is more like
> screenShot = ImageGrab.Grab()
> d = xmlrpclib.Binary(screenShot)

because screenShot is not binary data.
It's an instance of the class Image.
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] XML-RPC data transfers.

[Luke Paireepinart]

Chris Hengge wrote:
> if I'm trying to transmit a 'file' that is actually saved on the HD, 
> the code from the link in my first post works fine (reading in the 
> file using binary mode access). My problem is that I'm trying to 
> figure out how to transfer data that isn't yet saved to the drive, 
> because I'm wanting to be able to send any sort of data type across 
> the connection. This is getting rather frustrating because I'm getting 
> so many replies back that aren't even attempts at answers, but rather 
> questions about things I'm not trying to do. I'll restate the problem.
>
> grab image data from server side connection.
> transfer image data to client side
> write image data to file on client side.
>
> I've already established a working RPC connection, and if I transmit a 
> 'file' that can be read using binary mode (exact same code as posted 
> in both the link in my first email, and by others in this thread) it 
> works fine. My problem I'm trying to overcome is that I
>
> ***do not want to write the image data from the server to a file, just 
> to send it, then delete the image file on the server***
>
And how...

It's clear what you're trying to do.
The problem is this:

1) ImageGrab.grab() -> returns image object that has a 'save' method.
You use this method with the following syntax
import Image, ImageGrab
im = ImageGrab.grab()
im.save('filename.jpg')

to save the file .
2)
you read back in the file by doing:
f = file('filename.jpg','rb')
contents = f.read()


3)
you send it with this:
xmlrpclib.Binary(contents)


What you're trying to do is to eliminate step 1 and 2, so that you read 
the ImageGrab's data directly into the xmlrpclib.Binary method call
without having to write a file.

Okay.
So the main problem we're having here is that you seem to think that you 
should be able to send the ImageGrab object itself over the connection.
What is the problem is that xmlrpclib doesn't understand these class 
instances.  you need to give it plain binary data that it can send.
So there's a few ways you can go about this.

But the main strategy is to get the data out of the ImageGrab object.
one way is stated above - use the save method to write to a file.
another possible way is to create a filelike class, implementing 'tell' 
'seek' and 'write' methods, that just collects all the data written to 
it and keeps it in memory
rather than writing it out to a file.
This is hinted at in the documentation for im.save():
"You can use a file object instead of a filename. In this case, you must 
always specify the format. The file object must implement the *seek*, 
*tell*, and *write* methods, and be opened in binary mode."
(I assume it means you can use a file-like object, also, but it's 
possible that you can't, and I leave it to you to test that :) )

a third solution is to convert the data to a string using
*im.tostring().
*send that over your connection, and use im.fromstring() on the other 
end to recreate the image.

you could even use im.getdata(), iterate over it, construct your own 
representation of the data, and convert this back to an image at the 
other end.

All of these strategies have nothing at all to do with xmlrpc.
I have no idea what xmlrpc is, but I don't need to.
Your question is simplified to:
How do I convert a PIL Image instance into binary data?

As Kent said:
"If you are writing your image data to
a file, then using something like Lee's example below, that just reads
the file data into a Binary object, you should be able to just create
the Binary object from the image data directly."

 > For this specific challenge, I've found no actual "how-to" help... 
Just bits of information making it sound possible. Again, I dont want to 
"file transfer" anything, I want to send data that isn't in the default 
data-types for xml-rpc, which I've read can be done using binary mode 
transfers.

The reason you haven't had any actual 'how-to' help is because we 
believe that you could figure out what to do from the information given 
to you.
One of the greatest things about learning programming is figuring out 
how to do things yourself.
That being said, this mailing list's purpose is to help you when you get 
stuck along the way.
Not to give you code snippets that do exactly what you want - just to 
give you that little nudge in the right direction so you can continue 
working things out for yourself.
An example of this - I was playing Twilight Princess last night, and I 
got stuck in this one area.  I couldn't figure out what to do, and I ran 
around for an hour trying to find out what to do next.  I finally asked 
the in-game character that follows you around for help - and she gave me 
a hint.
I went to the place she told me to (I'm trying to avoid spoilers) and I 
did what she suggested - looking more closely at something.
After a good 30 seconds, it all of the sudden hit me.  I knew exactly 
what to do, and I went on happily through the game.

The point is that the most enjoyable part of th

Re: [Tutor] XML-RPC data transfers.

[Chris Hengge]

This works...
d = xmlrpclib.Binary(open("C:\\somefile.exe", "rb").read())

What I need is more like
screenShot = ImageGrab.Grab()
d = xmlrpclib.Binary(screenShot)

This doesn't work though.

On 12/30/06, Kent Johnson <[EMAIL PROTECTED]> wrote:


Chris Hengge wrote:
> I might have been unclear, or this tid-bit might have been lost in the
> thread... but I'm trying to send directly from ImageGrab.Grab(), without
> saving the data as a file. Thats where I'm getting hung... If it try to
> send an actual stored file, I have no problem. Is this maybe impossible?
> My thought was that I could just save a little process time and file
> fragmentation if I cut out the middle man, plus there really is no
> reason to save the screen capture on the server side.

Can you show the code that works? If you are writing your image data to
a file, then using something like Lee's example below, that just reads
the file data into a Binary object, you should be able to just create
the Binary object from the image data directly.

Kent

>
> Maybe I really need to look into SOAP for this sort of stuff? I'm just
> playing with the technology, and from the searching I've done, the
> XML-RPC seemed to fit my needs best. I could certainly be wrong though.
>
> Thanks for both of you giving me feedback.
>
> On 12/29/06, *Lee Harr* <[EMAIL PROTECTED]
> > wrote:
>
>  >
http://www.velocityreviews.com/forums/t343990-xmlrpc-send-file.html
> 
>  >
>  >Using this example I get error's about 'expected binary .read(),
> but got
>  >instance instead.
>
>
> I assume you are using this ...
>
>  >d = xmlrpclib.Binary(open("C:\\somefile.exe").read())
>
>
> Are you using windows?
>
> I think you would need to pass the binary flag to open ...
>
> imagedata = open(filename, 'rb').read()
>
>
>
> It's probably a good idea to use the binary flag if you are
expecting
> binary data just in case it gets ported somewhere else later.
>
>
>  >I've just been using xmlrpclib and simplexmlrpcserver for this,
> but I'm
>  >wondering if I should perhaps use twisted instead.
>
> I've used xml-rpc to send image data before. It worked.
>
> _
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.com/
>
> ___
> Tutor maillist  -  Tutor@python.org 
> http://mail.python.org/mailman/listinfo/tutor
> 
>
>
>
> 
>
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] XML-RPC data transfers.

[Chris Hengge]

if I'm trying to transmit a 'file' that is actually saved on the HD, the
code from the link in my first post works fine (reading in the file using
binary mode access). My problem is that I'm trying to figure out how to
transfer data that isn't yet saved to the drive, because I'm wanting to be
able to send any sort of data type across the connection. This is getting
rather frustrating because I'm getting so many replies back that aren't even
attempts at answers, but rather questions about things I'm not trying to do.
I'll restate the problem.

grab image data from server side connection.
transfer image data to client side
write image data to file on client side.

I've already established a working RPC connection, and if I transmit a
'file' that can be read using binary mode (exact same code as posted in both
the link in my first email, and by others in this thread) it works fine. My
problem I'm trying to overcome is that I

***do not want to write the image data from the server to a file, just to
send it, then delete the image file on the server***

For this specific challenge, I've found no actual "how-to" help... Just bits
of information making it sound possible. Again, I dont want to "file
transfer" anything, I want to send data that isn't in the default data-types
for xml-rpc, which I've read can be done using binary mode transfers.

On 12/30/06, Kent Johnson <[EMAIL PROTECTED]> wrote:


Chris Hengge wrote:
> I might have been unclear, or this tid-bit might have been lost in the
> thread... but I'm trying to send directly from ImageGrab.Grab(), without
> saving the data as a file. Thats where I'm getting hung... If it try to
> send an actual stored file, I have no problem. Is this maybe impossible?
> My thought was that I could just save a little process time and file
> fragmentation if I cut out the middle man, plus there really is no
> reason to save the screen capture on the server side.

Can you show the code that works? If you are writing your image data to
a file, then using something like Lee's example below, that just reads
the file data into a Binary object, you should be able to just create
the Binary object from the image data directly.

Kent

>
> Maybe I really need to look into SOAP for this sort of stuff? I'm just
> playing with the technology, and from the searching I've done, the
> XML-RPC seemed to fit my needs best. I could certainly be wrong though.
>
> Thanks for both of you giving me feedback.
>
> On 12/29/06, *Lee Harr* <[EMAIL PROTECTED]
> > wrote:
>
>  >
http://www.velocityreviews.com/forums/t343990-xmlrpc-send-file.html
> 
>  >
>  >Using this example I get error's about 'expected binary .read(),
> but got
>  >instance instead.
>
>
> I assume you are using this ...
>
>  >d = xmlrpclib.Binary(open("C:\\somefile.exe").read())
>
>
> Are you using windows?
>
> I think you would need to pass the binary flag to open ...
>
> imagedata = open(filename, 'rb').read()
>
>
>
> It's probably a good idea to use the binary flag if you are
expecting
> binary data just in case it gets ported somewhere else later.
>
>
>  >I've just been using xmlrpclib and simplexmlrpcserver for this,
> but I'm
>  >wondering if I should perhaps use twisted instead.
>
> I've used xml-rpc to send image data before. It worked.
>
> _
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.com/
>
> ___
> Tutor maillist  -  Tutor@python.org 
> http://mail.python.org/mailman/listinfo/tutor
> 
>
>
>
> 
>
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] about reload

[linda.s]

On 12/30/06, Luke Paireepinart <[EMAIL PROTECTED]> wrote:
>
> > I got confused now:-> if IDLE keeps the imports in between runs of the
> > program, do I still need import and reload? or click F5 in IDLE is OK?
> >
> The purpose of import is so that python knows what packages you intend
> to use,
> because if it imported every package every time, then many bad things
> would occur
> - one broken package would cause every python script on your computer to
> stop running until you deleted or fixed the problem package
> - it would clutter the global namespace
> - it would slow down startup of your scripts.
> - various other things that I can't think of.
>
> So this explains why we need import.
>
> Now in IDLE, because it is itself written in Python,
> there are strange side effects (when it can't open a subprocess).
> If you write a script in IDLE that goes into an infinite loop, the IDLE
> windows will stop responding.
> As we mentioned before, if you run one script through an IDLE shell that
> imports a module,
> on all the subsequent runs, even of different scripts, through the same
> IDLE shell, the imports will still be in the global namespace.
>
> That does not mean that you don't need to have an import at the top of
> each of your scripts.
> You want the program to run outside of IDLE, right?  How about in a
> fresh copy of IDLE?
> then you better put the imports in.
> Python won't know what you mean when you say something like 'print
> math.pi' unless you have an 'import math' at the beginning of your script.
>
> As far as reload goes:
>
> reload does NOTHING if you're running your script from the command line
> (as far as you're concerned, at this stage in learning Python.).
> Take this for example:
>
> #- config.py
> a = 'apples'
> #- end
>
> #- script.py
>
> import config
> print a
> reload(config)
> print a
>
> #--
> The output of this is going to be
> apples
> apples
> unless you change the 'config.py' file in between the first 'print a'
> and the 'reload'.
>
> In other words, reload updates changes that you make to your
> modules/packages.
> If you aren't planning on editing modules while your script is running,
> you don't have to worry about what 'reload' does.
> The imports will always be reloaded automatically when you run the
> Python interpreter again.
>
> There are 2 situations, as a beginner, that you would want reload.
> Take this for example.
>
> #-config.py
> a = 'apples'
> #-
>
>  >>> import config
>  >>> print config.a
> apples
>
> #--- we go and edit config.py while the interactive interpreter is
> still running, and we change it to this:
> a = 'aardvark'
> #-
>
>  >>> print config.a
> apples
>  >>> reload(config)
>  >>> print config.a
> aardvark
>
> See, the 'config' module's attributes didn't change until we reloaded
> it.  So case 1: when using an interactive interpreter and editing modules,
> reload updates our changes.
>
> The second case is, if IDLE is running, remember how we said that it
> keeps the imported modules imported?
>
> Well, say your program does this:
> #
> import config
> print config.a
> #-
> Now, the first time, and all subsequent times we run this program, it
> will do the same thing:
> it will print whatever 'a' was when config was imported in the FIRST run
> of the program.
> So if we went and edited config.py, none of the changes would be
> reflected in the print statement of this script.
>
> Basically, if you're designing a module in IDLE and you're making lots
> of changes to it, you have 2 choices:
> First, you could add a reload() to the top of the script that's using
> the module,
> and take it out when you're done.
>
> Or, a better solution, start IDLE from the start menu, instead of
> right-clicking and choosing "Edit..." and it will open a subprocess,
> and none of these 'imported stuff hanging around' problems will occur.
>
> HTH - tell me if anything's unclear
> -Luke
>
>
Thanks a lot!
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] question about importing threads

[Alan Gauld]

"shawn bright" <[EMAIL PROTECTED]> wrote i

> testing this right away. This long a .py script is becomming a 
> headache and
> i think it will be easier by far if it is pulled apart somewhat.

As a general rule of thumb, any Python script (or any programming
language file for that matter!) that gets longer than 4 or 5 hundred
lines should be looked at closely in terms of splitting it into 
modules.

There are a few (very few) times where I've seen a thousand line
file that was justified, but nearly any time you get beyond 500
lines you should be splitting things up - especially in high level
languages like Python where the methods/functions tend to be
short anyway.

FWIW

A quick check of the Python standard library shows the
average file size there to be: 459 lines(*) And that's pretty
high IMHO!

There are 19 files over a thousand lines and the biggest file
is over 3000 lines... which seems way too big to me!
But that's out of 188 files...

(*)
Cygwin; Python 2.4
In case you want to repeat for your version I used:
>>> libs = [len(open(f).readlines()) for f in glob('*.py')]
>>> print sum(libs)/len(libs)
>>> print max(libs)
>>> print len([s for s in libs if s>1000])

Alan G


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] question about importing threads

[shawn bright]

great help, and great link, thanks again.
shawn

On 12/30/06, Kent Johnson <[EMAIL PROTECTED]> wrote:


shawn bright wrote:
> Kent, Thanks.
> this is great. Yes, when i start the thread, i also pass the gtk object
> to it.
> kinda like this.
>
> serial_1 = Serial1(self.serial_1_buffer, self.serial_1_view)
> serial_1.start()
>
> so i am wanting to change that, but i do not exactly know how to stop a
> thread once i have it running, so that i could start another one.

The usual way to stop a thread is to set a flag that the thread checks.
Here is an example using a threading.Event as a flag:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65448

> anyway, thanks for the link and the info, i am going to get started on
> testing this right away. This long a .py script is becomming a headache
> and i think it will be easier by far if it is pulled apart somewhat.

Yes, 4000 lines is pretty long for one file IMO.

Kent



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] question about importing threads

[Kent Johnson]

shawn bright wrote:
> Kent, Thanks.
> this is great. Yes, when i start the thread, i also pass the gtk object 
> to it.
> kinda like this.
> 
> serial_1 = Serial1(self.serial_1_buffer, self.serial_1_view)
> serial_1.start()
> 
> so i am wanting to change that, but i do not exactly know how to stop a 
> thread once i have it running, so that i could start another one.

The usual way to stop a thread is to set a flag that the thread checks. 
Here is an example using a threading.Event as a flag:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/65448

> anyway, thanks for the link and the info, i am going to get started on 
> testing this right away. This long a .py script is becomming a headache 
> and i think it will be easier by far if it is pulled apart somewhat.

Yes, 4000 lines is pretty long for one file IMO.

Kent


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] question about importing threads

[shawn bright]

Kent, Thanks.
this is great. Yes, when i start the thread, i also pass the gtk object to
it.
kinda like this.

serial_1 = Serial1(self.serial_1_buffer, self.serial_1_view)
serial_1.start()

so i am wanting to change that, but i do not exactly know how to stop a
thread once i have it running, so that i could start another one.

anyway, thanks for the link and the info, i am going to get started on
testing this right away. This long a .py script is becomming a headache and
i think it will be easier by far if it is pulled apart somewhat.

thanks again
shawn

On 12/30/06, Kent Johnson <[EMAIL PROTECTED]> wrote:


shawn bright wrote:
> Hello there all.
> i have an app that has grown to about 4000 lines. It uses 6 threads and
> a GTK2 GUI.
> i was wondering if i could split it into seperate files that i could
> import. Each thread is a class.

That should be fine.

> i did not think that this would be a problem, but some of the threads
> pass information to views and buffers.

How do the threads find out about the views and buffers? If they are
global objects then you will have a problem. If they are passed to the
threads as parameters then it should be fine.

> If i had a thread outside of the main file, could i pass a gtk object to
> it so that it could write to it when it needed too?

Yes.

> and one last thing. If i did this, would i be able to only import the
> class when i started the thread, and then re-import it if i started the
> thread later . If so, this would allow me to work on a thread without
> having to restart the main program, and i could let the other threads
> keep running. As i find bugs, i could squash them without loosing any
> functionality of the other threads. Then if i wanted to stop or restart
> a thread by clicking a button, i could just re-import the class.
>
> is this ok ?

You can use reload() to update a module that has been changed. You will
also have to recreate any objects that were created from classes in the
module so they become instances of the modified module. You might be
interested in this recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164

Kent

>
> thanks
> shawn
>
>
> 
>
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor



___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] question about importing threads

[Kent Johnson]

shawn bright wrote:
> Hello there all.
> i have an app that has grown to about 4000 lines. It uses 6 threads and 
> a GTK2 GUI.
> i was wondering if i could split it into seperate files that i could 
> import. Each thread is a class.

That should be fine.

> i did not think that this would be a problem, but some of the threads 
> pass information to views and buffers.

How do the threads find out about the views and buffers? If they are 
global objects then you will have a problem. If they are passed to the 
threads as parameters then it should be fine.

> If i had a thread outside of the main file, could i pass a gtk object to 
> it so that it could write to it when it needed too?

Yes.

> and one last thing. If i did this, would i be able to only import the 
> class when i started the thread, and then re-import it if i started the 
> thread later . If so, this would allow me to work on a thread without 
> having to restart the main program, and i could let the other threads 
> keep running. As i find bugs, i could squash them without loosing any 
> functionality of the other threads. Then if i wanted to stop or restart 
> a thread by clicking a button, i could just re-import the class.
> 
> is this ok ?

You can use reload() to update a module that has been changed. You will 
also have to recreate any objects that were created from classes in the 
module so they become instances of the modified module. You might be 
interested in this recipe:
http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/160164

Kent

> 
> thanks
> shawn
> 
> 
> 
> 
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] XML-RPC data transfers.

[Kent Johnson]

Chris Hengge wrote:
> I might have been unclear, or this tid-bit might have been lost in the 
> thread... but I'm trying to send directly from ImageGrab.Grab(), without 
> saving the data as a file. Thats where I'm getting hung... If it try to 
> send an actual stored file, I have no problem. Is this maybe impossible? 
> My thought was that I could just save a little process time and file 
> fragmentation if I cut out the middle man, plus there really is no 
> reason to save the screen capture on the server side.

Can you show the code that works? If you are writing your image data to 
a file, then using something like Lee's example below, that just reads 
the file data into a Binary object, you should be able to just create 
the Binary object from the image data directly.

Kent

> 
> Maybe I really need to look into SOAP for this sort of stuff? I'm just 
> playing with the technology, and from the searching I've done, the 
> XML-RPC seemed to fit my needs best. I could certainly be wrong though.
> 
> Thanks for both of you giving me feedback.
> 
> On 12/29/06, *Lee Harr* <[EMAIL PROTECTED] 
> > wrote:
> 
>  >http://www.velocityreviews.com/forums/t343990-xmlrpc-send-file.html
> 
>  >
>  >Using this example I get error's about 'expected binary .read(),
> but got
>  >instance instead.
> 
> 
> I assume you are using this ...
> 
>  >d = xmlrpclib.Binary(open("C:\\somefile.exe").read())
> 
> 
> Are you using windows?
> 
> I think you would need to pass the binary flag to open ...
> 
> imagedata = open(filename, 'rb').read()
> 
> 
> 
> It's probably a good idea to use the binary flag if you are expecting
> binary data just in case it gets ported somewhere else later.
> 
> 
>  >I've just been using xmlrpclib and simplexmlrpcserver for this,
> but I'm
>  >wondering if I should perhaps use twisted instead.
> 
> I've used xml-rpc to send image data before. It worked.
> 
> _
> Don't just search. Find. Check out the new MSN Search!
> http://search.msn.com/
> 
> ___
> Tutor maillist  -  Tutor@python.org 
> http://mail.python.org/mailman/listinfo/tutor
> 
> 
> 
> 
> 
> 
> ___
> Tutor maillist  -  Tutor@python.org
> http://mail.python.org/mailman/listinfo/tutor


___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

[Tutor] question about importing threads

[shawn bright]

Hello there all.
i have an app that has grown to about 4000 lines. It uses 6 threads and a
GTK2 GUI.
i was wondering if i could split it into seperate files that i could import.
Each thread is a class.
i did not think that this would be a problem, but some of the threads pass
information to views and buffers.
If i had a thread outside of the main file, could i pass a gtk object to it
so that it could write to it when it needed too?
and one last thing. If i did this, would i be able to only import the class
when i started the thread, and then re-import it if i started the thread
later . If so, this would allow me to work on a thread without having to
restart the main program, and i could let the other threads keep running. As
i find bugs, i could squash them without loosing any functionality of the
other threads. Then if i wanted to stop or restart a thread by clicking a
button, i could just re-import the class.

is this ok ?

thanks
shawn
___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] about reload

[Luke Paireepinart]

> I got confused now:-> if IDLE keeps the imports in between runs of the
> program, do I still need import and reload? or click F5 in IDLE is OK?
>
The purpose of import is so that python knows what packages you intend 
to use,
because if it imported every package every time, then many bad things 
would occur
- one broken package would cause every python script on your computer to 
stop running until you deleted or fixed the problem package
- it would clutter the global namespace
- it would slow down startup of your scripts.
- various other things that I can't think of.

So this explains why we need import.

Now in IDLE, because it is itself written in Python,
there are strange side effects (when it can't open a subprocess).
If you write a script in IDLE that goes into an infinite loop, the IDLE 
windows will stop responding.
As we mentioned before, if you run one script through an IDLE shell that 
imports a module,
on all the subsequent runs, even of different scripts, through the same 
IDLE shell, the imports will still be in the global namespace.

That does not mean that you don't need to have an import at the top of 
each of your scripts.
You want the program to run outside of IDLE, right?  How about in a 
fresh copy of IDLE?
then you better put the imports in.
Python won't know what you mean when you say something like 'print 
math.pi' unless you have an 'import math' at the beginning of your script.

As far as reload goes:

reload does NOTHING if you're running your script from the command line 
(as far as you're concerned, at this stage in learning Python.).
Take this for example:

#- config.py
a = 'apples'
#- end

#- script.py

import config
print a
reload(config)
print a

#--
The output of this is going to be
apples
apples
unless you change the 'config.py' file in between the first 'print a' 
and the 'reload'.

In other words, reload updates changes that you make to your 
modules/packages.
If you aren't planning on editing modules while your script is running, 
you don't have to worry about what 'reload' does.
The imports will always be reloaded automatically when you run the 
Python interpreter again.

There are 2 situations, as a beginner, that you would want reload.
Take this for example.

#-config.py
a = 'apples'
#-

 >>> import config
 >>> print config.a
apples

#--- we go and edit config.py while the interactive interpreter is 
still running, and we change it to this:
a = 'aardvark'
#-

 >>> print config.a
apples
 >>> reload(config)
 >>> print config.a
aardvark

See, the 'config' module's attributes didn't change until we reloaded 
it.  So case 1: when using an interactive interpreter and editing modules,
reload updates our changes.

The second case is, if IDLE is running, remember how we said that it 
keeps the imported modules imported?

Well, say your program does this:
#
import config
print config.a
#-
Now, the first time, and all subsequent times we run this program, it 
will do the same thing:
it will print whatever 'a' was when config was imported in the FIRST run 
of the program.
So if we went and edited config.py, none of the changes would be 
reflected in the print statement of this script.

Basically, if you're designing a module in IDLE and you're making lots 
of changes to it, you have 2 choices:
First, you could add a reload() to the top of the script that's using 
the module,
and take it out when you're done.

Or, a better solution, start IDLE from the start menu, instead of 
right-clicking and choosing "Edit..." and it will open a subprocess,
and none of these 'imported stuff hanging around' problems will occur.

HTH - tell me if anything's unclear
-Luke

___
Tutor maillist  -  Tutor@python.org
http://mail.python.org/mailman/listinfo/tutor