On Mon, 2011-04-04 at 10:52 -0700, Alice Bevan–McGregor wrote: > > Regarding Paste and comments on > > https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm: > > > > 1. YAML vs INI - is there any decision? > > There isn't any particular reason not to go with both, INI for > backwards compatibility (using similar logic to YAML's parsing of > lists, numbers, etc., and YAML for the future. YAML's native rich > structures are just too handy, and if you know JSON, you can write YAML. > > I'll be rolling that into marrow.config. > > > 2. Is marrow.script not being argparse-compatible a big issue? Wouldn't > > it be easy to fix? > > marrow.script was designed to be explicitly argparse/optparse/getopt > incompatible. Paste Script's wrapping of optparse made things more > complicated, not easier. Unless, of course, someone can come up with > an _excellent_ reason why marrow.script should be rewritten to utilize > argparse. > > Marrow.script, OTOH, wraps nothing. It's a direct command line -> > argspec converter and help text generator. The ease of just throwing a > function or class at marrow.script (new or existing!) is highly > desirable. > > > 3. The same goes for marrow.server.http being asynchronous. As long as > > it was multithreaded too I don't know how this could be a problem (but > > maybe I don't know enough). And according to the readme on github > > (https://github.com/marrow/marrow.server.http), multi-threading is on > > the todo list: > > "threaded — Enable multi-threading. This is currently unimplemented > > pending support up-stream in marrow.server and defaults to False." > > Seems I need to fix that reference. Threading is supported (now that > it's supported in marrow.server) using a Futures-based thread pool. > The underlying server being async has never been a bad thing in any of > the benchmarking I've done, including C10K and 12KR/sec concurrency and > speed benchmarks, even with the thread pool enabled. > > > 4. "I'm uncomfortable with the direction of these libs personally. They > > seem to be more researchy than practical in lots of cases." > > Could somebody elaborate? I'm not trying to question anything, I don't > > know that much, I would just like to know what is wrong with Marrow. > > Same! :D > > Just because the packages take a distinctly different approach to some > things than Paste/WebOb/Django/<pkgname here> doesn't make them "bad", > "unusable", or "unstable". In fact, for PyPi releases, the packages > require 100% unit test coverage, full documentation, and 2.6+/3.1+ > polygot compatibility; that already makes them somewhat "better" than > (some of) the alternatives.
I think "researchy" describes some of the marrow stuff pretty well (that doesn't imply bad, unusable or unstable, it just implies opinionatedness that is outside the current mainstream). For example, in this message you've quoted use of a futures-based asynchronous server that says it implements WSGI 2.0, but WSGI 2.0 does not yet exist in any ratified form. I don't see WSGI 2.0 draft compatibility as a goal that we need to explore under GSOC. I think it's great you're pushing the envelope, but we really just need some very simple things that are well behind any of the curves you're at the front of. In the meantime, I don't much care if we get a PasteDeploy replacement that works under Python 3.X for GSOC. Pyramid apps don't strictly require PasteDeploy, they can be run without any declarative configuration. I also don't care much if we don't get a PasteScript replacement for GSOC either. Having a command line wrapper that does a bunch of stuff is handy but not required to make things run. We actually really just need some bits of Paste itself (the FileApp app, StaticURLParser, some of the auth_tkt bits) to work in order to reach a reasonable goal for 3.X compat. After that, we can think about how we'd like to wrap it up nicely for usage. I see the PasteScript/PasteDeploy stuff as a sort of last-resort project for GSOC, because it's pretty gratuituous until we get all the other dependencies ported. > I'm already using marrow.tags (and the widgeting it provides), > marrow.script, and marrow.blueprint in a number of projects, all with > great success. -- 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.
