(beginner) question on threads...
Fred Pacquier
Looking into threads, I've been toying with BaseHTTPServer again, to see if
I could make it respond to several requests at a time (like serving a page
while downloading a file, etc.).
Off to a bad start, I made the following simple-minded change :
in class BaseHTTPRequestHandler(SocketServer.StreamRequestHandler) :
in def handle(self) :
the last line : method() # generally self.do_GET()
becomes : thread.start_new_thread(method, () )
This immediately breaks the module :-), as in :
Unhandled exception in thread:
Traceback (most recent call last):
File "daft.py", line 308, in do_GET
self.send_page(INDEX)
File "daft.py", line 293, in send_page
self.send_response('200')
File "daft.py", line 163, in send_response
self.wfile.write("%s %s %s\r\n" %
File "c:\python21\lib\socket.py", line 192, in write
self.flush()
File "c:\python21\lib\socket.py", line 179, in flush
self._sock.send(self._wbuf)
AttributeError: 'int' object has no attribute 'send'
Am I just misusing the thread library, or is the whole idea hopelessly
naive (ie the vanilla HTTPServer is inherently not threadable) ? I just
want to learn, certainly not rewrite Medusa/Zope & all the AsyncHTTPServers
out there :-)
TIA,
fp
--
YAFAP : http://www.multimania.com/fredp/
Skip Montanaro
Fred> Off to a bad start, I made the following simple-minded change :
Fred> in class BaseHTTPRequestHandler(SocketServer.StreamRequestHandler) :
Fred> in def handle(self) :
Fred> the last line : method() # generally self.do_GET()
Fred> becomes : thread.start_new_thread(method, () )
I think you can just create a suitable subclass of SocketServer.TCPServer.
In my XML-RPC server, I did:
class GenericServer(SocketServer.ThreadingMixIn, SocketServer.TCPServer):
"""generic XML-RPC server class"""
...
Each request to my server is handled in a separate thread.
--
Skip Montanaro (sk...@pobox.com)
http://www.mojam.com/
http://www.musi-cal.com/
Fred Pacquier
> I think you can just create a suitable subclass of
> SocketServer.TCPServer. In my XML-RPC server, I did:
>
> class GenericServer(SocketServer.ThreadingMixIn,
> SocketServer.TCPServer):
> """generic XML-RPC server class"""
> ...
> Each request to my server is handled in a separate thread.
By Jove, it works ! Python will never cease to amaze me...
I probably got more than I bargained for, though : now I need to understand
_why_ it just works -- and probably have to delve into that "mixin" stuff I
was saving for later too :-)
Thanks for the tip, Skip ! (hey, that sounds like an old Paul Simon song :)
--
YAFAP : http://www.multimania.com/fredp/
Joseph Andrew Knapka
>
> Skip Montanaro <sk...@pobox.com> said :
>
> > I think you can just create a suitable subclass of
> > SocketServer.TCPServer. In my XML-RPC server, I did:
> >
> > class GenericServer(SocketServer.ThreadingMixIn,
> > SocketServer.TCPServer):
> > """generic XML-RPC server class"""
> > ...
> > Each request to my server is handled in a separate thread.
>
> By Jove, it works ! Python will never cease to amaze me...
> I probably got more than I bargained for, though : now I need to understand
> _why_ it just works -- and probably have to delve into that "mixin" stuff I
> was saving for later too :-)
Had a similar experience recently. Class A had some code that would be
very handy in class B. I thought the code in question would probably
work unchanged, since A and B already contained all the data attributes
needed. So I pulled the method in question (only -- the data on which it
depended stayed put) out into a separate mixin class, had A and B
inherit
the new class, and Poof! It worked immediately. I used to be a
static-analysis zealot, but I am gaining a really strong appreciation
for Python's wonderful dynamicism.
> Thanks for the tip, Skip ! (hey, that sounds like an old Paul Simon song :)
"Just say no to C, Lee,
And get yourself free..."
Cheers,
--
# Joe Knapka
# "You know how many remote castles there are along the
# gorges? You can't MOVE for remote castles!" - Lu Tze re. Uberwald
# Linux MM docs:
http://home.earthlink.net/~jknapka/linux-mm/vmoutline.html
Fred Pacquier
> Had a similar experience recently. Class A had some code that would be
> very handy in class B. I thought the code in question would probably
> work unchanged, since A and B already contained all the data attributes
> needed. So I pulled the method in question (only -- the data on which
> it depended stayed put) out into a separate mixin class, had A and B
> inherit the new class, and Poof! It worked immediately. I used to be a
> static-analysis zealot, but I am gaining a really strong appreciation
> for Python's wonderful dynamicism.
Hmm. I was loath to make a fool of myself yet again, but you just offered
the opportunity for another naive question :-)
I was wondering how people handle this class hierarchy stuff in large
bodies of code. Right now I load a module in an editor, see it inherits
from some class in module foo, so I load that in another window. If foo
inherits some class in bar, I need to look that up too, and so on. I find I
rather quickly hit the ceiling in my ability for abstraction, and the
general picture muddies up pretty fast :)
Is there not a better way ? Some tool that will build a picture of a class
from its code, with all its methods and attributes, inherited or not ?
>> Thanks for the tip, Skip ! (hey, that sounds like an old Paul Simon
>> song :)
> "Just say no to C, Lee,
> And get yourself free..."
Dead on :-))
--
YAFAP : http://www.multimania.com/fredp/
Markus Schaber
Fred Pacquier <fr...@mygale.org.nospam> schrub:
> Is there not a better way ? Some tool that will build a picture of a
> class from its code, with all its methods and attributes, inherited or
> not ?
That's _really_ difficult in python, because one can add methods or
attributes to classes even at run-time, depending on user input or
random generators :-)
But the usual, statically written in source way, it should be possible,
I've seen something like this in the Delphi environment, as pop-down
menu in the editor.
markus
--
"The strength of the Constitution lies entirely in the determination of
each citizen to defend it. Only if every single citizen feels duty
bound to do his share in this defense are the constitutional rights
secure." -- Albert Einstein
Fred Pacquier
>> Is there not a better way ? Some tool that will build a picture of a
>> class from its code, with all its methods and attributes, inherited or
>> not ?
>
> That's _really_ difficult in python, because one can add methods or
> attributes to classes even at run-time, depending on user input or
> random generators :-)
>
> But the usual, statically written in source way, it should be possible,
> I've seen something like this in the Delphi environment, as pop-down
> menu in the editor.
On the one hand, I'm glad to learn my way of exploring is not so dumb after
all. OTOH, I'm sadly disappointed that there is no magic bullet :-)
--
YAFAP : http://www.multimania.com/fredp/
Joal Heagney
> Hmm. I was loath to make a fool of myself yet again, but you just offered
> the opportunity for another naive question :-)
*chuckles* You'll find this is THE best newsgroup to ask naive questions
in. The gurus (Tim, Emile and Guido to name a few) don't mind answering
the really interesting questions (Implementation, exotic classes etc.)
people pop up, the intermediates take this as an example of good
behaviour and take care of the medium level questions and then people
like me answer as many newbie questions that they can accuratly field.
The trick is to know when to shut up and let somebody more experienced
field the question. Plus each of us at the just-above neophyte level has
experience in different aspects of python, and how we learnt it - I know
some of the beginner-useful modules (not all) and I'm very good at how
to build python and python extension module rpms.
> I was wondering how people handle this class hierarchy stuff in large
> bodies of code. Right now I load a module in an editor, see it inherits
> from some class in module foo, so I load that in another window. If foo
> inherits some class in bar, I need to look that up too, and so on. I find I
> rather quickly hit the ceiling in my ability for abstraction, and the
> general picture muddies up pretty fast :)
If you look at the standard library, you'll see one of the major
principles of python coding is to keep the inheritance tree as flat as
possible. For example, you have a module A, that imports module B, which
imports module C. Now module A uses a function in module B that comes
from module C. It is better code practice to import module C into module
A and use the function directly, rather than rely on it being included
in module B.
A diagram:
module A
(contains all functions in B and C because it)
|
imports B
(which contains all functions in C because it)
|
imports C
A uses B.C.function.
Now if B is altered so that it no longer imports C, A breaks, and you
have to transverse the inheritence tree to find out why.
Alternatively, say B stays the same, but C is altered so that function
is no longer provided. B may not break, but A does. It's simple in this
example to find out what's happening, but in more complex trees, you can
get really tangled.
Instead:
module A
(contains all functions in B and C because it)
| |
imports B and C
(which contains all
functions in C
because it)
|
imports C
Instead of A using B.C.function, it now uses C.function directly. B is
altered so that it no longer imports C, A still works. If C breaks in
the second example above, you no longer have to hunt down where the
function came from, you know you got it from C, so you can check it
directly.
> Is there not a better way ? Some tool that will build a picture of a class
> from its code, with all its methods and attributes, inherited or not ?
from pydoc import help
import os
help(os)
class test:
def __init__(self,blah):
self.blah = blah
def afunc(self,values):
blahblablah
class test2(test):
def bfunc(self):
blah-blablabla - blabblah
help(test)
And then the pydoc module supports other objects that let you build
html/txt and output to file.
--
Joal Heagney is: _____ _____
/\ _ __ __ _ | | _ ___ |
/__\|\ || ||__ |\ || |___|/_\|___] |
/ \ \_||__ ||___| \_|! | | \ \ !
Fred Pacquier
> *chuckles* You'll find this is THE best newsgroup to ask naive
> questions in. The gurus (Tim, Emile and Guido to name a few) don't mind
> answering the really interesting questions (Implementation, exotic
> classes etc.) people pop up, the intermediates take this as an example
> of good behaviour and take care of the medium level questions and then
> people like me answer as many newbie questions that they can accuratly
> field. The trick is to know when to shut up and let somebody more
> experienced field the question. Plus each of us at the just-above
> neophyte level has experience in different aspects of python, and how
> we learnt it - I know some of the beginner-useful modules (not all) and
> I'm very good at how to build python and python extension module rpms.
Yup -- that is definitely a huge part of the global python picture. There
is the language itself and its own merits, and then there are the sorts of
people who tend to gather around it, push it in various directions, and
form its distinctive community. Don't know which way the chicken-and-egg
aspect really works, but python certainly wouldn't be where it is without
both...
> If you look at the standard library, you'll see one of the major
> principles of python coding is to keep the inheritance tree as flat as
> possible. For example, you have a module A, that imports module B,
> which imports module C. Now module A uses a function in module B that
> comes from module C. It is better code practice to import module C into
> module A and use the function directly, rather than rely on it being
> included in module B.
Well, in my own code I certainly take care to keep things at the simplicity
level I feel I can handle :-)
But in this particular case, I was nosing through the standard lib's
*HTTPServer modules, where classes are effectively nested a few levels
deep.
>> Is there not a better way ? Some tool that will build a picture of a
>> class from its code, with all its methods and attributes, inherited or
>> not ?
>
> from pydoc import help
> import os
> help(os)
> class test:
> def __init__(self,blah):
> self.blah = blah
> def afunc(self,values):
> blahblablah
> class test2(test):
> def bfunc(self):
> blah-blablabla - blabblah
> help(test)
> And then the pydoc module supports other objects that let you build
> html/txt and output to file.
Aha. This is new in 2.x, right ? Need to look into that. Thanks for the tip
and encouragement !