On 2011-03-13 16:32:14 -0400, Mike Orr said:
- marrow.server.http is asynchronous. I don't think we want to make
such a large leap from multithreaded to asynchronous in the default
server. People have just gotten used to making their apps thread-safe;
I don't think we want to force them to make them asynchronous-safe too
in order to upgrade to Python 3.
WSGI isn't asynchronous, and marrow.server (the underlying server
abstraction API) provides a worker thread pool in the form of a Futures
executor to the higher-level protocol in order to implement threading.
It also implements multi-process out of the box with logical processor
detection. (The use of Futures allows extension to more complicated,
i.e. dynamically scaling, thread pools, while maintaining a consistent
API.)
This flexibility allows you to choose the best configuration for your
particular problem: cpu-bound, io-bound, or a mix.
I'm not sure how/what would be needed for "asynchronous-safeness"… if
you're thread safe, you're good to go.
- marrow.script disavows argparse and optparse in favor of its own
GNU-like syntax. Do we need another command-line parser? I was just
starting to use argparse. (PasteScript does not use either, but
argparse would be an advantage.)
Argparse, optparse, getopt — these are all very much based on the C API
and as such, aren't very Pythonic at all. Compare:
1 import optparse
2
3 if __name__=="__main__":
4 parser = optparse.OptionParser("usage: %prog [options] arg1 arg2")
5 parser.add_option("-H", "--host", dest="hostname",
6 default="127.0.0.1", type="string",
7 help="specify hostname to run on")
8 parser.add_option("-p", "--port", dest="portnum",
9 default=80, type="int",
10 help="port number to run on")
11 (options, args) = parser.parse_args()
12 if len(args) != 2:
13 parser.error("incorrect number of arguments")
14 hostname = options.hostname
15 portnum = options.portnum
1 import argparse
2
3 parser = argparse.ArgumentParser(description='Process some integers.')
4 parser.add_argument('integers', metavar='N', type=int, nargs='+',
5 help='an integer for the accumulator')
6 parser.add_argument('--sum', dest='accumulate', action='store_const',
7 const=sum, default=max,
8 help='sum the integers (default: find the max)')
9
10 args = parser.parse_args()
11 print(args.accumulate(args.integers))
1 # encoding: utf-8
2
3 import marrow.script
4
5
6 @marrow.script.describe(
7 host = "specify a hostname to run on",
8 port = "port number to run on"
9 )
10 def serve(arg1, arg2, host="127.0.0.1", port=80):
11 pass
12
13
14 if __name__ == '__main__':
15 marrow.script.execute(serve)
- Is the distinction between PasteScript and PasteDeploy really worth
keeping? Marrow seems to keep the distinction but I was going to meld
them together. It seems like you rarely use them apart, and for our
purposes of "create" and "serve" both are necessary. People are always
having to look in both PasteDeploy and PasteScript to see where
something is defined.
I'm often utilizing the marrow.blueprint system (templated directory
trees) independant of marrow.script within my own applications. The
two serve very specific problem domains.
— Alice.
--
You received this message because you are subscribed to the Google Groups
"pylons-devel" group.
To post to this group, send email to pylons-devel@googlegroups.com.
To unsubscribe from this group, send email to
pylons-devel+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-devel?hl=en.
