Howdy!
On 2011-05-25 14:50:58 -0700, Mike Orr said:
Alice, thank you for correcting any misconceptions about Marrow, and
for documenting it on the Brainstorm page for future reference. I
apologize if I've made any mischaracterizations, either from reading
something that was false or interpreting it wrongly.
No worries! Besides, if something isn't documented properly or gives
the wrong impression, that's more my fault than anything else.
The Marrow suite looks like a well-thought-out, pythonic collection of
services. As such, it definitely serves as an example of one way
Pyramid could handle things in the future. It'll be several months
before we make any definite decision though.
Of course. Following the Zen, *right now* is rarely a good idea. ;)
As you know, a few people are advocating various approaches for
replacing Paste*, PasteHTTPServer and the INI file. In the next few
months they'll be releasing them and writing HOWTOs for them. If you
feel like it, a HOWTO for adding Marrow enhancements to a typical
Pyramid or Akhet application would be welcome.
Somewhat difficult to write HOWTO's for a framework I don't currently
use. :P I'll see what can be done, however, as upcoming employment
does make use of Pyramid, which should give me a better 'working grasp'
of how to integrate my Marrow packages.
I took a quick look at the Marrow parser both for Pyramid and for my
standalone utilities. My command-line options tend to have complex
specifications and interactions, and they don't always correspond
directly to function arguments.
I would love to see some examples of complex interactions. If one of
your requirements are options that are only made available if another
option is enabled/defined, that's on the roadmap. :) Also,
sub-commands (hg/git style) are already supported in head using classes
instead of bare functions.
Perhaps if I thought more about it, they could. But the "magic" in the
decorators is not something I need, even if others find it desirable.
The decorators I used are adding a py3k feature to 2.x. Python 3
already includes a method for adding 'hinting' information to
arguments. These decorators are actually the examples given in the
decorator PEP! :D
Argparse does what it does reasonably well; I have not yet gotten sick
enough of it to jettison it.
For sure there is no point taking an existing working solution and
throwing it to the wind to re-engineer it under a different parser.
Marrow.script is primarily targeted at people who either have an
existing callable (class/method) they want to expose as a command-line
script, or for those who want to write really, really fast one-off
scripts.
OTOH it could greatly simplify the paster scripts I have thus far come
across in the wild.
For Pyramid, the developers seem to prefer conservative innovation.
Make incremental improvements, but not too radical. Obviously, Pyramid
is a radical departure from Pylons 1, but that's an occasional paradigm
shift akin to Python 3; it's not typical for all Pyramid/Pylons
development.
Despite optional ZCML and the use of ZCA, Pyramid isn't, in my mind,
such a drastic departure from existing frameworks. Traversal (pre-
view lookup) is limited object dispatch using __getitem__ instead of
__getattr__. Woot. ;P The Paste components are identical, Beaker and
SA are popular, etc. For people migrating from TurboGears/Pylons or
any other framework derived from Paste, things should be /relatively/
comfortable.
When Python makes a language change, the criteria is, "Is it obviously
the best way? Do the advantages significantly outweigh the bother of
changing? Both for the users and for the developers?" It takes time
for everybody to try out new libraries, and for a consensus to form
that one of them is obviously the best way and is a significant
advantage.
I see it as less of a technological "best solution" war than a
marketing one. WebCore has been API stable for a year and a half and
critical bug-free for a year. Over 50 commercial projects have been
created and launched using it, spread between three primary users in as
many countries. Why hasn't it caught on with other users? For the
most part, no-one knows it exists despite my view that it trounces
other frameworks in simplicity, usability, and performance. (And uses
the exact same underlying Paste, WebOb, Beaker, SA, etc. stack w/ only
~300 lines of glue.)
What one might consider "best" is purely subjective, which is
unfortunate from a "let's make a standard" perspective. Advantage and
disadvantage comparison is also rather subjective. Hell, Django
decided to forego any external reusable dependencies…
Yes, those are a few of the problems with Paste*. But we (Pyramid) need
to stop and think awhile about what we want to replace it with.
I'd love to see a wiki page for each of these things with discussion,
requirements exploration, and pros/cons of different approaches.
You say that Marrow users don't have to worry about any of these.
Not quite. m.s.http (the preferred way to abbreviate these modules,
since Paste isn't just an HTTP server, either ;) users need to choose
the options that best fit their requirements:
:: Base: Development, IO-bound or otherwise speedy execution.
:: Threading: CPU-bound or otherwise slow execution.
:: +Multi-Process: Scaling out instead of up.
If you need to debug things, nothing helps quite like only doing one
thing at a time. Having these options means properly understanding the
consequences of a developer decision: threading means you need to be
thread-safe. A base server means you need to be careful about blocking.
As an aside, that RPC service I mentioned uses its own internally
managed thread pool (Futures again) to defer/parallelize tasks away
from the request/response cycle and avoid blocking. Additionally, you
only get IO-bound benefit if you make use of marrow.io for your
communication, which will re-use/integrate with the marrow.server
reactor. (I avoid monkey-patching /anything/, but in theory it can be
done.)
In that case, suitable documentation may already be written.
This is the documentation so far, and will be expanded upon in the
future. (E.g. adding a 'design / rationale' section.)
https://github.com/marrow/marrow.server.http/blob/draft/README.textile
I'm probably sounding redundant here, but only those who are especially
motivated to use Marrow will follow all those references and figure out
the correspondence between those examples and Pyramid. Others will
move on unless there's a Pyramid-specific HOWTO.
I'm posting on the Pyramid/Pylons *developer* list, not the user list,
so I'd expect the "open-mindedness"/curiosity level to be somewhat
higher, as I would also expect the tolerance to non-Pyramid-specific
content to be higher. Unfortunately, the majority of the Marrow
projects that could benefit Pyramid would require core changes, thus a
fork and a number of branches to explore the options, not just add-on
packages or adaptive HOWTOs.
Of course, it may not be worth your while to write such a thing,
depending on how important Pyramid is to you.
At the current time, Pyramid as a framework is not important to me. I
both do not use it and do not agree with a number of fundamental design
decisions. This may change in the future depending on how much of my
new job involves working on Pyramid-powered applications.
A lack of interest (or tolerance to reading code when HOWTOs aren't
present) from the Pyramid group on finding and integrating third-party
modules (Marrow or other, now or in the future) isn't really *my*
problem. Getting the Marrow suite operational, released, and polished
for my own projects is! ^_^
— 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.
