I don't want to become a maintainer, for now. I'm a user. If I could provide a patch, I would have done it without any argument. On the other hand, you're already a maintainer. But you decline to accept that the current API is incomplete and leave me alone with my problem. I'd like to use the chained snippet if you ensure me that the API will be completed in the following releases.
On Thursday, June 21, 2012 6:14:10 PM UTC+4, Chris McDonough wrote: > > On 06/21/2012 09:59 AM, Max Avanov wrote: > > But I want to. I really do. And view_config doesn't allow me to do so. > > You should understand me. I don't want to have extra imports in my > project. > > I want transparent support from the framework. This example makes sense > > for me: > > > > from pyramid.view import view_config > > @view_config(decorator=(decorator1, decorator2, ...)) > > > > But this is not: > > from pyramid.view import view_config > > # Why should I do this for each of my view modules? > > from somewhere import chain_decorators > > > > @view_config(decorator=chain_decorators(decorator1, decorator2, ...)) > > I've already noted that if you want to not have to import the > chain_decorators thing from someplace, you should supply a patch to > Pyramid that allows it to handle a sequence of decorators passed to > decorator=. The patch should contain tests and docs. I've actually > noted that three times now, I'm just not sure what else to say about it. > Is it unclear? > > In the meantime, you can already get what you want by just using the > recipe. > > - C > > > > > > > > On Thursday, June 21, 2012 4:21:24 PM UTC+4, Chris McDonough wrote: > > > > On 06/21/2012 07:29 AM, Max Avanov wrote: > > > > No! View callable functions must accept at least a request > > argument. > > > There will never be something this that will work as a view > > callable: > > > > > > This is my typo. I was talking about a regular generic view > > callable. > > > I still don't get how to rewrite these @authenticate_form and > > @https (as > > > an example) - > > > > > > https://github.com/Pylons/pylons/blob/master/pylons/decorators/secure.py > > < > https://github.com/Pylons/pylons/blob/master/pylons/decorators/secure.py> > > > > > - to be able to do the common: > > > > > > @view_config() > > > @https() > > > @autnenticate_form > > > def view(request) - or - def view(context, request) - or - def > > view(self) > > > > > > without passing it to view_config > > > > Why you don't want to pass the decorator to view_config via > > decorator= I > > have no idea, given that dealing with the differences is the entire > > purpose of that machinery and the code to support a chain of > decorators > > is entirely boilerplate. > > > > But assuming you didn't, and assuming this isn't an entirely > > theoretical > > exercise which we're beating to death, you could write a decorator > that > > assumed *one* signature which also set __module__, and __doc__ and > on > > the function returned from the decorator: > > > > from functools import wraps > > > > def adecorator(wrapped): > > def inner(request): > > print request.url > > return wrapped(request) > > return wraps(wrapped, ('__module__', '__doc__'))(decorator) > > > > @view_config(....) > > @adecorator > > def view(request): > > .... > > > > - C > > > > > > > > > > > > > > > On Thursday, June 21, 2012 2:39:57 AM UTC+4, Chris McDonough > wrote: > > > > > > On 06/20/2012 06:13 PM, Max Avanov wrote: > > > > > So I'm lost as to what > > > > you mean by "no other way to get access to request object" > > > > > > > > Because I must > > > > - either to follow the official approach provided by Michael (" > a > > > > consistent signature no matter whether the actual view is a > > > method, or a > > > > function > > > > that accepts either (context, request) or just (request)...") > > > with the > > > > consequent @view_config(decorator=...) and the chained code > > snipped. > > > > - or use the "classic" way: > > > > @decorator1 > > > > @decorator2 > > > > @decoratorN > > > > @view_config > > > > def func() > > > > > > > > For classic way I use the decorator package - > > > > http://micheles.googlecode.com/hg/decorator/documentation.html > > <http://micheles.googlecode.com/hg/decorator/documentation.html> > > > <http://micheles.googlecode.com/hg/decorator/documentation.html > > <http://micheles.googlecode.com/hg/decorator/documentation.html>> - > > > But the > > > > classic way allows me only one generic approach to get the > request > > > > object - via get_current_request, right? > > > > > > No! View callable functions must accept at least a request > argument. > > > There will never be something this that will work as a view > > callable: > > > > > > def func(): > > > ... > > > > > > It just wont work. A view callable must be: > > > > > > def func(request): > > > ... > > > > > > An alternate view callable signature optionally accepts > "(context, > > > request)" but if your code doesn't use that signature for any of > > your > > > view callables, you won't care. Pyramid view callables can also > be > > > methods of classes, but if your code doesn't use view classes, > you > > > won't > > > care about that either. > > > > > > If you *do* care about reusing a decorator across all of these > view > > > callable conventions, however, you can use the decorator= > > argument to > > > view_config. The point of the decorator= argument to view_config > > is to > > > provide genericness by accepting a decorator that can use a > single > > > common call signature for a decorator ("(context, request)"). So > you > > > can use the following decorator: > > > > > > def adecorator(viewcallable): > > > def inner(context, request): > > > print request.url > > > return viewcallable(context, request) > > > return inner > > > > > > .. against this kind of view configuration ... > > > > > > class AView(object): > > > def __init__(self, request): > > > self.request = request > > > > > > @view_config(decorator=adecorator) > > > def aview(self): > > > return Response('OK') > > > > > > .. or this kind ... > > > > > > @view_config(decorator=adecorator) > > > def aview(request): > > > return Response('OK') > > > > > > ... or this kind ... > > > > > > @view_config(decorator=adecorator) > > > def aview(context, request): > > > return Response('OK') > > > > > > ... or this kind ... > > > > > > @view_config(decorator=adecorator) > > > class AView(object): > > > def __init__(self, request): > > > self.request = request > > > > > > def __call__(self): > > > return Response('OK') > > > > > > ... or this kind ... > > > > > > class AView(object): > > > def __init__(self, context, request): > > > self.context = context > > > self.request = request > > > > > > @view_config(decorator=adecorator) > > > def aview(self): > > > return Response('OK') > > > > > > You get the point. The *same decorator* will work against any > view > > > callable you define, even though the place it gets used differs: > > > against a method of a class, against a class object, against a > > function > > > object, and the associated callable may have different arguments. > It > > > will still work in all scenarios. > > > > > > Since a decorator is just a callable that returns a callable, > > whether > > > you use the package you linked to or not to produce one is > > irrelevant. > > > Even the "@" syntax is just sugar. Instead of: > > > > > > @decorator1 > > > @decorator2 > > > def func(): > > > ... > > > > > > it could just be: > > > > > > def func(): > > > ... > > > > > > func = decorator2(decorator1(func)) > > > > > > If you're decorating functions or methods that you don't know the > > > argument list for, just make the decorator accept *arg, **kw and > > pass > > > those along to the wrapped function from your wrapper function > > defined > > > inside the decorator. That will work for any sort of wrapped > > function, > > > even those for a view callable. > > > > > > If you mean you want to create some sort of omniscient decorator > > that > > > can be used for both a view callable *and any other kind of > > function*, > > > but which in both cases requires a request to.. do something.., > > then, > > > yes, you could use get_current_request inside the decorator > > logic. It'd > > > be insane to try to define such a decorator, when you could just > > create > > > one that expected the decorated function to supply the (context, > > > request) signature, but you could do it. > > > > > > If this all boils down to "why dont you support a sequence rather > > > than a > > > single function as a valid decorator= argument" because you need > > to mix > > > and match logic in your decorators, please either submit some > > code that > > > makes it so or use the recipe for chained decorators. > > > > > > - C > > > > > > -- > > > You received this message because you are subscribed to the > Google > > > Groups "pylons-discuss" group. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msg/pylons-discuss/-/fhyzewf5dfkJ > > <https://groups.google.com/d/msg/pylons-discuss/-/fhyzewf5dfkJ>. > > > To post to this group, send email to > > [email protected] > > <mailto:[email protected]>. > > > To unsubscribe from this group, send email to > > > [email protected] > > <mailto:pylons-discuss%[email protected]>. > > > For more options, visit this group at > > > http://groups.google.com/group/pylons-discuss?hl=en > > <http://groups.google.com/group/pylons-discuss?hl=en>. > > > > -- > > You received this message because you are subscribed to the Google > > Groups "pylons-discuss" group. > > To view this discussion on the web visit > > https://groups.google.com/d/msg/pylons-discuss/-/vp2QABR9sV0J. > > To post to this group, send email to [email protected]. > > To unsubscribe from this group, send email to > > [email protected]. > > For more options, visit this group at > > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To view this discussion on the web visit https://groups.google.com/d/msg/pylons-discuss/-/4aJ4-Jyuqw4J. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
