Pyramid 2 ideas
Mike Orr
it became clear that we might want to do some other changes at the
same time, enough to warrant a new major version, aka Pyramid 2. I've
outlined the ideas on the following wiki page:
https://github.com/Pylons/pyramid/wiki/Pyramid-2-Brainstorm
These are just some ideas for discussion; we're not committing to any
of them at this point. If you have other ideas let's get them on the
list. Part of the reason for doing this is to determine which projects
we might want to offer to Google Summer of Code students.
Here's a summary of the ideas on the wiki page:
- Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
- Replace Paste, PasteDeploy, and PasteScript with "something".
- "paster create" can be extracted to a new utility, either a
top-level script or a subcommand.
The code could do with some modernization.
- "paster create" can likewise be extracted to a new utility.
- Rename "application templates" to "application skeletons" to avoid
confusion with file templates.
- Possible new names for Paster and its components: glue ("Glue is the
new Paste!"), Create, Serve, karnak.
- Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
code and give better names.
- Replace the INI file with an YAML file?
- Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
Pyramid. Some of these are more properly dependencies of the specific
applications which are using them.
--
Mike Orr <slugg...@gmail.com>
Michael Merickel
Michael
--
You received this message because you are subscribed to the Google Groups "pylons-devel" group.
To post to this group, send email to pylons...@googlegroups.com.
To unsubscribe from this group, send email to pylons-devel...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Thomas G. Willis
Alice Bevan–McGregor
> - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
This is not just a good idea, it's the slaw; with the ratification of
PEP 3333 there finally exists a standard protocol for Python 3 support.
> - Replace Paste, PasteDeploy, and PasteScript with "something".
> - "paster create" can be extracted to a new utility, either a
> top-level script or a subcommand.
> The code could do with some modernization.
> - Rename "application templates" to "application skeletons" to avoid
> confusion with file templates.
> - Possible new names for Paster and its components: glue ("Glue is the
> new Paste!"), Create, Serve, karnak.
> - Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
> code and give better names.
> - Replace the INI file with an YAML file?
Marrow is my namespaced meta-framework rewrite of Paste, WebOb, and
other utilities. It includes:
* marrow.blueprint (paster create) agnostic to underlying template
lingua via alacarte, advanced interactive and command-line
interrogation including secure password entry.
* marrow.script (paste script) using Python's powerful introspection features.
* marrow.wsgi.objects (WebOb) request/response/exceptions
* marrow.util (a lot of stuff including 2.6->3.1 forward compatibility)
* marrow.tags (12K page generations per second pure Python templating)
* marrow.server.http (C10K capable fully HTTP/1.1 compliant server)
* marrow.config (paste deploy) YAML-based configuration
The HTTP server would need a little bit of work to get it to speak PEP
3333 and not 444, but the amount of work would be minimal.
A few of these already have released versions, though marrow.config is
mostly just sketched p-code so far.
The requirements for release are:
* Complete documentation.
* Multiple examples.
* 100% unit test coverage.
Only marrow.util doesn't abide by this, though the package is far older
than the others and will be brought up to the above standard within a
few releases.
At PyCon Atlanta 2011 I'll be running a sprint to port TurboMail to
Py3K and work on Marrow — search for Marrow on
http://us.pycon.org/2011/sprints/projects/.
It would likely be worthwhile to cohabitate with the Pyramid sprint as
Marrow doesn't compete, it just offers the underlying portable support
libraries.
> - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
> Pyramid. Some of these are more properly dependencies of the specific
> applications which are using them.
There exists a package called alacarte which offers a back-end agnostic
templating interface. It already supports Mako, Jinja2, and a handful
of others, including serialization formats like JSON, Bencode, and
YAML. It was built to replace the ancient (and crufty) TurboGears 1
"buffet" API.
— Alice.
Alice Bevan–McGregor
> brainstorming at this point, but is there any killer feature of yaml or
> something?
Consider:
[server:main]
host = 127.0.0.1, ::1
port = 80, 8080
How do you get a list of ports as integers?
server:
host: [127.0.0.1, ::1]
port: [80, 8080]
In YAML, lists, integers, and more are automatically handled for you.
You can also use simple extensions to the YAML parser to allow
multiple-file inclusions, define new datatypes, etc.
— Alice.
Thomas G. Willis
Mike Orr
There's nothing fatal about INI but it has three limitations:
- Can't express types other than strings. Can't express dicts/lists.
External routines have to parse these (asbool,
sqlalchemy.engine_from_config).
- Rigid two-level structure, can't express hierarchies.
- It's not really a multi-language standard as it claims to be: there
is no formal definition of which characters are allowed. I was
surprised when Paste started using keys containing ':'.
- Sucky ConfigParser (although it's improved in Python 2.7/3.2)
Its main advantages are:
- Less verbose than a Python module of scalar assignments, where you
have to quote the strings and can't have sections (unless you use
classes for them, but then you have the "class" keyword).
- Easier for sysadmins who don't know Python to maintain the file;
they don't have to learn Python quoting rules.
There's a feeling among some developers and many (but not all) users
that INI's disadvantages may be outweighing its advantages. YAML can
express all the things ppl wish the config file had. It can also
express a full ZCA configuration, which would allow the same file to
do app configuration, logging, and component configuration without
using ZCML. That's what Marco was, a YAML-based version of
PasteDeploy. Its development was halted but parts of it could be
revived for a new tool.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
<al...@gothcandy.com> wrote:
> Howdy!
>
>> - Port to Python 3.2 and 2.7. Drop compatibility with 2.5 and below.
>
> This is not just a good idea, it's the slaw; with the ratification of PEP
> 3333 there finally exists a standard protocol for Python 3 support.
>
>> - Replace Paste, PasteDeploy, and PasteScript with "something".
>> - "paster create" can be extracted to a new utility, either a
>> top-level script or a subcommand.
>> The code could do with some modernization.
>> - Rename "application templates" to "application skeletons" to avoid
>> confusion with file templates.
>> - Possible new names for Paster and its components: glue ("Glue is the
>> new Paste!"), Create, Serve, karnak.
>> - Extract PasteDeploy, loadapp, loadserver, BetterConfigParser; refine
>> code and give better names.
>> - Replace the INI file with an YAML file?
>
> Marrow is my namespaced meta-framework rewrite of Paste, WebOb, and other
> utilities.
I'll add it to the list. Although I'm hoping to move away from
namespace packages, as Paste as done. They have already caused
practical problems in that you can't install part of a namespace
package as OS packages and part as virtualenv packages. We can't get
away from Zope's namespace package but I think we can avoid it where
it's unnecessary. Nevertheless I'll add Marrow to the list in case it
turns out to be the best meta-framework otherwise.
> * marrow.wsgi.objects (WebOb) request/response/exceptions
These are fully WebOb compatible? WebOb has become essentially the
only multi-framework Request/Response, so I dont' want to interfere
with it becoming a standard. It's easier to program in WebOb than raw
WSGI.
>> - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
>> Pyramid. Some of these are more properly dependencies of the specific
>> applications which are using them.
>
> There exists a package called alacarte which offers a back-end agnostic
> templating interface. It already supports Mako, Jinja2, and a handful of
> others, including serialization formats like JSON, Bencode, and YAML. It
> was built to replace the ancient (and crufty) TurboGears 1 "buffet" API.
Does it require an entry point for each templage engine as Buffet
does? That's what we ultimately removed from Pylons because it was a
level of indirection and complexity that wasn't really necessary.
--
Mike Orr <slugg...@gmail.com>
Mike Orr
had two concerns:
- 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.
- 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.)
- 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.
--
Mike Orr <slugg...@gmail.com>
Andrey Popp
On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
> - Replace the INI file with an YAML file?
YAML is not as good as it can be for config file format:
* It has slow parsers.
* There's risk of bloating YAML file with Python type annotations (tags),
e.g. !!bool, !!python/tuple when dealing with YAML programmatically.
I better suggest looking for something that has syntax similar to Configgy
for Scala.
I propose another idea for GSoC -- generic (persistent agnostic,
pluggable, extensible) admin interface based on Pyramid. It seems Tres
Seaver started doing something like this on github[1], but what about
putting it on GSoC rails? I think this will be the killer feature for
Pyramid itself.
Mike Orr
Added to the list, but can you specify what exactly you want this
admin interface to do? What does "persistent" and "agnostic" mean in
an admin interface?
I assume "pluggable" and "extensible" means extensible with ZCA.
--
Mike Orr <slugg...@gmail.com>
Nathan
> Here's a summary of the ideas on the wiki page:
> ...
> - Possible new names for Paster and its components: glue ("Glue is the new Paste!"), Create, Serve, karnak.
Regarding names: A good name is unique enough that blog posts and discussion on it can be found easily. Searching for "python glue" is going to return a pretty useless set of results, whereas karnak (or something similarly unique) would be much better.
Otherwise all the brainstorming is sounding great. I've been fine with INI config files until now, but YAML sure sounds nicer.
-Nathan
Andrey Popp
> admin interface to do? What does "persistent" and "agnostic" mean in
> an admin interface?
Sorry, I mean persistence-agnostic -- interface should not be targeted to
specific relational databases (like django.contrib.admin do), it should
define some interfaces, like:
class IRepository(Interface):
def list(filters):
""" List items in repository filtered by ``filters``."""
def get(id):
""" Get item by ``id``."""
def save(item):
""" Save ``item``."""
...
Such interfaces should be defined per database engine (or derived
automagically from SQLAlchemy table definitions or etc.) or defined
with respect to application specific needs.
You can see bottlecap, I've already mentioned -- it does this exactly that
way.
> I assume "pluggable" and "extensible" means extensible with ZCA.
Yep, if Pyramid already uses ZCA, so admin interface based Pyramid also should use ZCA for extensibility.
Wichert Akkerman
> i like ini files so much better than yaml.
Same for me.
Wichert.
--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.
Wichert Akkerman
>> i like ini files so much better than yaml. i realize it is
>> brainstorming at this point, but is there any killer feature of yaml
>> or something?
>
> Consider:
>
> [server:main]
> host = 127.0.0.1, ::1
> port = 80, 8080
>
> How do you get a list of ports as integers?
>
> server:
> host: [127.0.0.1, ::1]
> port: [80, 8080]
>
> In YAML, lists, integers, and more are automatically handled for you.
You can also use ISC-style config files to get that, and a lot of people
will already be familiar with their format. I happen to have written a
simple parser for them years ago: http://pypi.python.org/pypi/bicop
Marius Gedminas
> On 2011-3-14 01:53, Thomas G. Willis wrote:
> >i like ini files so much better than yaml.
>
> Same for me.
Are we collecting votes here? Because I'd like to add a +1 for INI and
against YAML.
Marius Gedminas
--
This is the Local Descriptor Table, another weird Intel thingy. Linux only
uses this for some strange applications like Wine. We don't do anything
here, so they'll get an informative and friendly Segmentation Fault.
-- lguest source code
Alice Bevan–McGregor
> On Sun, Mar 13, 2011 at 1:40 PM, Andrey Popp
> <8ma...@gmail.com> wrote:
>> Hello,
>>
>> On Mar 13, 2011, at 3:29 PM, Mike Orr wrote:
>>> - Replace the INI file with an YAML file?
>>
>> YAML is not as good as it can be for config file format:
>>
>> * It has slow parsers.
>>
>> * There's risk of bloating YAML file with Python type annotations (tags),
>> e.g. !!bool, !!python/tuple when dealing with YAML programmatically.
>>
>> I better suggest looking for something that has syntax similar to Configgy
>> for Scala.
YAML is available, configurations can be expressed as pure JSON in
addition to the more expanded YAML syntax, and I don't really see a
reason to completely deprecate INI ± XML for configuration, either.
It's good to have a default that is the most expressive of the
syntaxes, though.
>> I propose another idea for GSoC -- generic (persistent agnostic,
>> pluggable, extensible) admin interface based on Pyramid. It seems Tres
>> Seaver started doing something like this on github[1], but what about
>> putting it on GSoC rails? I think this will be the killer feature for
>> Pyramid itself.
>>
>> [1]: https://github.com/Pylons/bottlecap
>
> Added to the list, but can you specify what exactly you want this
> admin interface to do? What does "persistent" and "agnostic" mean in
> an admin interface?
>
> I assume "pluggable" and "extensible" means extensible with ZCA.
Chris Perkins extracted the TurboGears administration interface and
object dispatch mechanism (to support admin) into separate packages:
* https://github.com/GothAlice/crank - dispatch
* https://github.com/GothAlice/web.admin - admin
While the code is rough (and templates un-styled), the code was
demonstrable at last year's ConFoo.
— Alice.
Alice Bevan–McGregor
> - 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.
Alice Bevan–McGregor
> On Sun, Mar 13, 2011 at 11:08 AM, Alice Bevan–McGregor
> <al...@gothcandy.com> wrote:
>> * marrow.wsgi.objects (WebOb) request/response/exceptions
>
> These are fully WebOb compatible? WebOb has become essentially the only
> multi-framework Request/Response, so I dont' want to interfere with it
> becoming a standard. It's easier to program in WebOb than raw WSGI.
No, it is not directly WebOb compatible, though conversion shouldn't be
too difficult. Right now m.w.objects contains a complete templatable
exception collection (care of Alex Grönholm) and enough of the
request/responses to get working, if simplified data in and out. (The
examples using Response objects, @wsgify decorator, etc. are all
functional.)
I aim to correct some perceived (by me) flaws in the API; things like
multiple body accessor methods (how many people honestly assign a file
then read back the unicode?), etc.
>>> - Remove formal dependencies on Chameleon, Mako, and PasteDeploy in
>>> Pyramid. Some of these are more properly dependencies of the specific
>>> applications which are using them.
>>
>> There exists a package called alacarte which offers a back-end agnostic
>> templating interface. It already supports Mako, Jinja2, and a handful of
>> others, including serialization formats like JSON, Bencode, and YAML. It
>> was built to replace the ancient (and crufty) TurboGears 1 "buffet" API.
>
> Does it require an entry point for each templage engine as Buffet does?
> That's what we ultimately removed from Pylons because it was a level of
> indirection and complexity that wasn't really necessary.
It is if you want the onus on supporting frameworks to be on the
template engine author and not on the over-worked framework developers.
;) The Buffet API was terrible, the alacarte API is extremely simple,
and you can even register template engines imperatively.
— Alice.
Alice Bevan–McGregor
marrow account name (which was previously parked), so urls starting
with:
Should now reference:
Thank you,
— Alice.
Stephen Lacy
Why fuss over "how does this support lists" and other similar issues?
And, for me, the most important issue is that when I see code like this:
I know that I can just say something like "from config import PORTS" and access the values right in my code. That means that I can put anything I want in there (application-specific debug/logging parameters, nonstandard database connection parameters, whatever) and not have to fuss over "what the heck does the parser do with this, how do I get the parsed data, and what if the values I want aren't supported?" That means more documentation, more "accessor" code, etc.
danj...@gmail.com
concern here is that moving to Pyramid 2 so quickly is a bit premature
given the paint is barely dry on Pyramid 1.
Should we not wait until there are some actual projects built with
Pyramid, and we get feedback from real world usage ? The danger is
that this ends up like TG2 - a continually moving target moving from
one dependency to the next, depending on what's flavour of the month,
with a small core of developers continually making changes but leaving
behind those who need a stable framework to work on.
I would suggest that any major changes to Pyramid should depend on
what users actually want or need. Yes, YAML may be better than INI.
But it's not something that people using Pyramid have any issues with
at this point. Ditto moving bits hither and thither from Paste. People
coming to Pyramid are already having issues understanding differences
between URL dispatch and traversal, authentication, testing etc.
That's OK as Pyramid is a low-level framework and the higher-level
stuff is still being built on top of it. But to add yet another slew
of huge and fundamental changes will confuse and turn away people from
Pyramid altogether.
Vlad K.
Personally, I vote against YAML if that means yet another dependency to
Pyramid. INI works fine if you have only or mostly scalar types, json is
ugly and pure Python code should work too, however I believe importing a
config module would bring a lot of grief and dependency on globals, so
it should be reflected into the already present settings registry.
I would however vote for a Python config module because it preserves
data types. Take the already mentioned ports for example:
ports = 80, 8080, 12345
Then in the code you need something like:
ports = [int(p.strip()) for p in settings["ports"].split(",")]
which is more or less required for any config file except pure Python
module. Also, perhaps there should be a hook for early configuration
parsing so that any config mistakes (for instance a noninteger in the
above sequence) are caught at application launch and not days into
production when that particular piece of code gets executed for the
first time.
In other words, I vote for Python config module, reflected into the
settings registry, with an optional (for the developer) app startup hook
for config parsing and validation.
.oO V Oo.
Mike Orr
<danj...@gmail.com> wrote:
> Migration to Python 3 aside (which has to happen, sooner or later) my
> concern here is that moving to Pyramid 2 so quickly is a bit premature
> given the paint is barely dry on Pyramid 1.
We aren't moving quickly but just capturing people's ideas onto a list
so that we can see if an architectural pattern emerges, so that we
don't forget anything, and to disclose our potential long-term
direction to both users and framework-makers (TurboGearsSuccessor,
Khufu). We will have to choose GSOC tasks in a month or so, and we
want to make sure they're consistent with our general direction so
they don't turn into dead ends. A GSOC task will not be all of this,
it would be one small part. It would also depend on what the student
is interested in.
The takeaway seems to be that PasteDeploy and PasteScript are not part
of the permanent core but are "blessed" add-ons (formal dependencies),
as Mako is. You can already configure a Pyramid app imperatively -- IN
PYTHON -- by instantiating the app passing in the desired settings.
This is hopefully emphasized in the Pyramid manual to a greater extent
than is for Pylons; or at least that was the intention. The Paster
templates with INI files are just a convenience to get you started.
Paste* need a maintainer as Ian moves on to other things. That de
facto falls to use because we use them most. The consensus seems to be
that PasteDeploy and PasteScript could be cleaned up with their
current active features rather easily, but Paste itself is more
difficult, so it may be better to take what we need and leave the rest
to die.
So there are three different issues: moving Paste out of the Pyramid
core, rewriting PasteDeploy/PasteScript with their current features
(possibly merging them), and adding/moving to YAML
This comes back to porting to Python 3 in that, how much effort do we
want to put into porting the existing Paste* code to Python 3, if
we're not sure we want to keep it long-term.
> Should we not wait until there are some actual projects built with
> Pyramid, and we get feedback from real world usage ? The danger is
> that this ends up like TG2 - a continually moving target moving from
> one dependency to the next, depending on what's flavour of the month,
> with a small core of developers continually making changes but leaving
> behind those who need a stable framework to work on.
Reluctance noted. We do need more Pyramid applications and experience,
and we don't want to be flightly like TurboGears has seemed. Perhaps
we can just think about it for six months, and if there's anything
somebody think is especially cool they can make an add-on for it.
--
Mike Orr <slugg...@gmail.com>
Daniel Holth
In other words, the required and documented dependency should be extraordinarily boring and simple. Its author will hang his head in shame at releasing such a banal package. Instead, the awesome YAML SQL ZODB database-/dev/null fairy dust driven configuration tool can reuse 'baster' and its load_wsgi_server() function in a way that is not pleasant with Paste.
Vlad K.
Speaking of asynchronous... what is the future of WSGI regarding
asynchronous serving? With websockets (or whatever the standard will
emerge out of it) coming fully supported in the next generation of
browsers (what, within a year? two?), is this even a possibility for
WSGI and with that Pyramid? Returning iterators as response objects?
Gevent integration?
.oO V Oo.
Mike Orr
Twisted about how to be more compatible. The upshot is that
asynchronous servers need some kind of token in the output stream that
means "I'm not ready; come back later." Other middlewares would have
to pass this token through unchanged. And of course, the application
would have to use non-blocking libraries such as non-blocking database
executors. I'm not sure if ordinary file access is "blocking" enough
to require that too.
The upshot has been that Twisted runs WSGI applications in a thread
anyway because it can't be sure they won't block. And there hasn't
been enough interest from WSGI developers to actually pursue using it
with asynchronous servers.
I think Python has a future object now which standardizes Twisted's
Deferred and the equivalent in other asynchronous servers. So that's a
start.
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-devel" group.
> To post to this group, send email to pylons...@googlegroups.com.
> To unsubscribe from this group, send email to
> pylons-devel...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/pylons-devel?hl=en.
>
>
--
Mike Orr <slugg...@gmail.com>
Vlad K.
As far as I know there are at least two (major) db systems that support
asynchronicity, PostgreSQL via psycopg2 and MongoDB via pymongo, and
that's good. If WSGI is capable of being asynchronous (I'm not very
familiar with the internals of the protocol), even if that only requires
the ready state token (or the fd identifier in environ for requests),
that's good news.
I hope the interest among wsgi devs will rise as websockets become
standardized, though. While websockets would have very specific use
(also replacing current "semi-duplex" implementations via, say, Comet),
there would still have to be single interface specification for
integration with "traditional" web applications, because running two
inherently incompatible systems within the context of a single web
application is an integration nightmare.
Oh, btw, and let's not forget the infrastructure required with the
advent of WebGL. Somehow I'm convinced that async-only web apps and
interface specification should become the norm, rendering traditional
(wsgi?) apps obsolete just like fastcgi, scgi and wsgi obsoleted cgi.
It would be nice if we didn't have to build entirely new frameworks from
scratch because WSGI can't fit the async paradigm.
.oO V Oo.
oO
Please be careful not to use a single generic name like "glue"
"marrow" and others... As developers and users, we are completely
dependent on search engine results, and guess what there are already
valid prior use for these words...
I already have to search for "pylons pyramid framework" to get any
meaningful results, because for some reason "pyramid" keeps returning
all kinds of stuff about early Egyptian architecture. I can only
imagine that "Pyramid Glue" would return interesting theories about
binding agents that these early Egyptian architects were using. and
I'm guessing that "Pyramid Marrow" would teach me about embalming
techniques.
oO
Joe Dallago
What Pyramid really needs is more female contributors ;).
That said, I thought that this would be an appropriate place to notify the community that the ball is rolling on revamping PasteScript/PasteDeploy. Whit Morriss and I have created three repos on GitHub entitled HTTPPaste(standalone http web server), WSGIServe(replica of loadwsgi.py in paste), and Skeletor(the new paste create). If anyone else is interested in helping just contact one of us. You can view all of the repos or help contribute at www.github.com/postpaste.
On Mar 15, 2011 7:38 PM, "oO" <oli...@ozoux.com> wrote:
Yes on the naming.
Please be careful not to use a single generic name like "glue"
"marrow" and others... As developers and users, we are completely
dependent on search engine results, and guess what there are already
valid prior use for these words...
I already have to search for "pylons pyramid framework" to get any
meaningful results, because for some reason "pyramid" keeps returning
all kinds of stuff about early Egyptian architecture. I can only
imagine that "Pyramid Glue" would return interesting theories about
binding agents that these early Egyptian architects were using. and
I'm guessing that "Pyramid Marrow" would teach me about embalming
techniques.
oO
On Mar 13, 2:41 pm, Nathan <nat...@simplestation.com> wrote:
> On 2011-03-13, at 5:29 AM, Mike Orr ...
Ben Bangert
> What Pyramid really needs is more female contributors ;).
Working on that, its actually part of the reason for having an explicit Code of Conduct for the community. Pylons has historically had rather good diversity in contributors both in geography and gender, and I hope to retain that in the Pylons Project community. I am happy to note that historically the sprint room for Pylons has usually had more females in it than Django, which is odd given that they have a pink pony for a mascot.
Great to hear about the work on some small packages of just the essentials we use. Don't we still need a command runner replacement for 'paster serve'? Also, when extracting HTTPPaste, it'd prolly be a good time to include the Nagle algorithm removal patch as an option to it which results in a decent through-put increase and less latency (generally starts to match CherryPy's server then):
http://groups.google.com/group/paste-users/browse_thread/thread/b2afc88a86caade1
http://stackoverflow.com/questions/1781766/paste-httpserver-and-slowdown-with-http-1-1-keep-alive-tested-with-httperf-and-a
Cheers,
Ben
Joe Dallago
WSGIServe will replace 'paster serve'. I will definitely look into removing the Nagle algorithm. Seems as though we have an opportunity to really improve the speed of paste.
On Mar 15, 2011 9:14 PM, "Ben Bangert" <b...@groovie.org> wrote:
On Mar 15, 2011, at 5:27 PM, Joe Dallago wrote:
> What Pyramid really needs is more female contribu...
--
You received this message because you are subscribed to the Google Groups "pylons-devel" group....
Ben Bangert
> WSGIServe will replace 'paster serve'. I will definitely look into removing the Nagle algorithm. Seems as though we have an opportunity to really improve the speed of paste.
Without Nagles algorithm, it's pretty close to CherryPy's, which is great considering it does a bit more to avoid memory leaks, stuck threads, etc.
- Ben
Thomas G. Willis
Alice Bevan–McGregor
> WSGIServe will replace 'paster serve'.
For the love of humanity, anyone writing a new web server, or
performing substantial work to modernize an existing one, needs to read
O'Reilly's "HTTP: The Definitive Guide"[1], James Marshall's "HTTP Made
Really Easy"[2], and Apache's "Known Problems in Clients"[3], but this
is by no means an exhaustive list. These should pretty much cover
everything, including many edge cases and gotchas.
(These also happen to be the resources used during the construciton of
marrow.server.http.)
— Alice.
[1] http://oreilly.com/catalog/9781565925090
[2] http://www.jmarshall.com/easy/http/
[3] http://bit.ly/h6sP1G
Alice Bevan–McGregor
> and others... As developers and users, we are completely dependent on
> search engine results, and guess what there are already valid prior use
> for these words...
Despite WebCore being, unbeknownst to me at the time, a component of
WebKit, searching for WebCore results in my web framework being the 5th
result, which isn't bad considering I've done very, very little
marketing and a sum total of zero SEO optimization on the site.
WebCore has been called that for just over a year. (Previously: YAPWF
— searching for YAPWF, WebCore is the 4th result!)
Generic names, or ones with large existing conflict pools, matter less
than one might think. A search for marrow does have a result on the
first page, and although it's not as high as I'd like, it is "above the
fold" on my display. Pyramid, OTOH, is nowhere to be found.[1] :(
Google seems to have a bias towards technical sites.
> I already have to search for "pylons pyramid framework" to get any
> meaningful results, because for some reason "pyramid" keeps returning
> all kinds of stuff about early Egyptian architecture. I can only
> imagine that "Pyramid Glue" would return interesting theories about
> binding agents that these early Egyptian architects were using. and I'm
> guessing that "Pyramid Marrow" would teach me about embalming
> techniques.
Well, Pyramid and Marrow are (currently) completely unrelated projects,
though by no means does that need to hold true in the future! :)
Marrow suffers the same issue that Pylons or Repoze do as a generic
name for a collection of projects, not a specific package, though
Repoze at least has a very unique name.
— Alice.
[1] I lied; found it just prior to sending this message… the very last
link on the first page of results. :/