Suggestion for Request namespace provisioning

[Jonathan Vanasco]

The past few updates to Pyramid have had a few changes around the
Request object - new attributes, new functionality to add attributes,
etc.

With that, combined with the best-practice of passing the Request
object around during the request lifecycle, I wanted to suggest
creating a 'project' and 'plugin' namespace under request , so that
(moving forward) as people develop plugins or write app specific
request attributes there is no issue for collision against each other
or future Pyramid releases.

The general idea would be this:
request.project = reserved for your app ( or
request.projects.project_name ). do what you want.
request.plugins = reserved for plugins that need to attach data to
the request object. ex: request.plugins.sqlalchemy

The main idea is that instead of using 'set_property', you'd use
'set_project_property' or similar. Not suggesting that we drop the
current scenario, just that
- the request object has a lot of stuff in it now
- i can see the request object's attributes/methods growing as Pyramid
matures
- i fear namespace collision.

[Michael Merickel]

On Tue, Oct 30, 2012 at 1:17 PM, Jonathan Vanasco <jona...@findmeon.com> wrote:
> With that, combined with the best-practice of passing the Request
> object around during the request lifecycle, I wanted to suggest
> creating a 'project' and 'plugin' namespace under request , so that
> (moving forward) as people develop plugins or write app specific
> request attributes there is no issue for collision against each other
> or future Pyramid releases.
>

> - i fear namespace collision.

No doubt this is a concern. Fortunately request properties do fall
under Pyramid's conflict resolution mechanism. A good convention is
already possible by creating an object on request that exposes your
methods.

class RequestExtensions(object):
def __init__(self, request):
self.request = request

@reify
def some_cached_property(self):
return 'foo'

def some_method(self, **kw):
return 'bar'

config.add_request_method(RequestExtensions, 'myplugin', reify=True)

will allow

request.myplugin.some_api
request.myplugin.some_method()

I'm not sure Pyramid needs any sugar over top of this pattern.

[Jonathan Vanasco]

That pattern / functionality is great. I'm just talking about
proactively saying "this name space is reserved for plugins, this
namespace for projects - you can rest assured that as Pyramid grows
and new functionality is added, you will not be affected as long as
you stay within that container". Right now, request.foo is a bit of a
lottery -- from my perspective, chances are you won't add anything to
Pyramid over there, but its not an explicit/futureproof property.

[Michael Merickel]

I think it's cool that Pyramid provides a way to do it, but I don't
think layering that opinion on top belongs in the core.

[Chris McDonough]

Also, FWIW, even if people add some namespacey thing, those namespacey
things themselves are subject to conflict. So telling folks to bundle
up everything into a namespace isn't a complete solution either. The
only true solutions are untenable without ridicule (UUIDs, Java-style
"com.pyramid.myplugin" style namespaces).

I'd rather just let the chips fall where they may here and instruct
folks to create plugins that don't supply unduly generic request
properties. If they supply one, so be it; the system will let the user
know there's a conflict, and they can work it out with the authors.

Note that this is how Emacs plugins have worked for many years, and
Emacs has a *lot* more plugins than does Pyramid. ;-) And they don't
even have conflict detection.

- C

[Jonathan Vanasco]

these are all good points.