Thanks, Mike. But as I said, I cannot become a maintainer. I would like to, but just cannot do it for now.
On Thursday, June 21, 2012 6:20:19 PM UTC+4, mike bayer wrote: > > hey Max - > > The Pyramid devs agree that it should accept a tuple argument. I think > it's a good idea too. They're just looking for someone to provide a patch > at this point. > > - mike > > > On Jun 21, 2012, at 10:18 AM, Max Avanov wrote: > > What are you talking about? This is not just my stupid ideological > behavior. My current project has 30+ different subpackages, each of thes > has view-modules. For now, I have to make 30+ extra imports just > because.... hmm... I still don't get why I have to. > > On Thursday, June 21, 2012 6:10:07 PM UTC+4, Chris Rossi wrote: >> >> Don't let the perfect be the enemy of the good. >> >> Chris >> >> On Thu, Jun 21, 2012 at 9:59 AM, Max Avanov <[email protected]> >> 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, ...)) >> > >> > >> > >> > 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 >> >> > - 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> >> - >> >> > 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. >> >> > 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/-/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/-/uf3n-nRpxvYJ. > 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/-/UJqnIwjm24sJ. 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.
