vinjvinj wrote:
> I'm building an application with cherrypy and have started using
> decorators quite extensively. A lot of my exposed functions look like:
>
> @expose
> @startTransactrionAndBuildPage
> @partOfTabUi(tabId)
> @convert(arg1=int, arg2=str)
> def do_main_page(self, arg1, arg2):
>
vinjvinj <[EMAIL PROTECTED]> wrote:
> >>what exactly made you think that Python would be able to run your
> >>code *without* calling your function ?
>
> I was hoping that when the compiler finds decorators with wrapers that
> have the same signature it can some how "magically" combine them into
>
Diez B. Roggisch <[EMAIL PROTECTED]> wrote:
...
> begin()
> try:
> pass
> commit()
> finally:
> if not comitted():
> rollback()
Feels like a natural for 2.5's 'with' statement -- as has been the case
for 2.3 and 2.4, 2.5 won't have many language-level changes, but what
little there IS
vinjvinj schrieb:
>>> That sounds like something for the templating engine, and _certainly_ not
>>> for a decorator that otherwise deals with transactions.
>
> The actual code for the page layout is in a preppy template. But the
> calls to the template engine are made in the
> startTransactrionAnd
>>what exactly made you think that Python would be able to run your
>>code *without* calling your function ?
I was hoping that when the compiler finds decorators with wrapers that
have the same signature it can some how "magically" combine them into
one function (which gets called at run time) and
"vinjvinj" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I'm building an application with cherrypy and have started using
> decorators quite extensively. A lot of my exposed functions look like:
>
> @expose
> @startTransactrionAndBuildPage
> @partOfTabUi(tabId)
> @convert(arg1=int
"vinjvinj" wrote:
> I was fearing that. The expose decorator is the only one that comes
> with cherrypy. The other ones are mine and are of the format:
>
> def decorator(func):
> def wrapper(self, *args, **kwargs)
> some code
> return wrapper
what exactly made you think that Pyth
>>That sounds like something for the templating engine, and _certainly_ not
>>for a decorator that otherwise deals with transactions.
The actual code for the page layout is in a preppy template. But the
calls to the template engine are made in the
startTransactrionAndBuildPage decorator
>>Templat
"vinjvinj" wrote:
> I'm building an application with cherrypy and have started using
> decorators quite extensively. A lot of my exposed functions look like:
>
> @expose
> @startTransactrionAndBuildPage
> @partOfTabUi(tabId)
> @convert(arg1=int, arg2=str)
> def do_main_page(self, arg1, arg2):
>
> @expose -> cherrypy decorator
> @startTransactrionAndBuildPage -> starts a db transaction, populates
> the user in the session.
I guess that is ok - transaction handling is a "classic" for decorator-like
concepts. After all, you don't want
begin()
try:
pass
commit()
finally:
if not comitt
>> solution. I'm not going to tell you that decorators aren't the answer to
>>all programming problems, because you already know that in your heart :-
I was fearing that. The expose decorator is the only one that comes
with cherrypy. The other ones are mine and are of the format:
def decorator(fu
vinjvinj wrote:
> I'm building an application with cherrypy and have started using
> decorators quite extensively. A lot of my exposed functions look like:
>
> @expose
> @startTransactrionAndBuildPage
> @partOfTabUi(tabId)
> @convert(arg1=int, arg2=str)
> def do_main_page(self, arg1, arg2):
>s
vinjvinj <[EMAIL PROTECTED]> wrote:
> I'm building an application with cherrypy and have started using
> decorators quite extensively. A lot of my exposed functions look like:
>
> @expose
> @startTransactrionAndBuildPage
> @partOfTabUi(tabId)
> @convert(arg1=int, arg2=str)
> def do_main_page(self
13 matches
Mail list logo
