Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > mixing statements into J2

Thread Tools

mixing statements into J2

Robert Brewer
Posts: n/a
> > > Can we insert conditional expressions in the
> decorator list ?
> >
> > Not with the current patch; however, that option may be

> allowed in the future.
> "In the future" means "post-2.4, when we have an idea of what people
> are doing with it". Right now, there's not a whole lot of use cases
> for more complex expressions in the decorator area, and there's more
> potential for horror. Guido made this call on a gut feeling, not on
> any technical grounds. His gut is usually good on this.
> > The order of operation would have to be reversed,

> I don't see why.

It's not a requirement, but it seems reasonable to me. If you're going
to set off a decorator suite and then mix in normal Python statements,
the two models collide over order of operation:

if test:
def foo(self, *args):

The statements get evaluated top-to-bottom, but the decorators get
applied bottom-to-top. It would be one more confusing issue in an
already-confusing syntax. Not to mention that the current patch pushes
decorators onto the stack at compile-time, and then pops them off after
the function def. Mixing statements into the suite would move decorators
from compile-time to runtime (at least, I don't see any way to avoid
that without introducing a whole new layer of pragmas).

If I felt it were possible, I would have recommended that application
order in J2 be the opposite of A1. But I figured that would cause
another two weeks of debate, which we don't have. I certainly see that
"using:" provides a case for top-to-bottom, where "@decorator" implies
the opposite.

> > so *IF* Guido votes yes,
> > then you need to bring this up again immediately.

> God no. Please don't. Work with the syntax that's chosen, then we can
> revisit this for 2.5.

Waiting until then guarantees the question won't be addressed, due to
backward-compatibility issues which we will have then which we do not
have now. Which I'm willing to concede to be a foregone conclusion at
this point. Perhaps it would be enough just to say (to Guido), "this is
still an open issue (one of many)"?

Robert Brewer
Amor Ministries Removed)
Reply With Quote
Jeremy Bowers
Posts: n/a
On Thu, 26 Aug 2004 10:36:08 -0700, Robert Brewer wrote:
> using:
> if test:
> memoize
> else:
> synchronize
> classmethod
> def foo(self, *args):
> stuff(args)

Others have pointed out the illegality of this, I would point out there is
a legal way for those who may not realize it:

if test:
myDec = memoize
myDec = syncronize

def foo(self, *args):

I quite frequently do this to create modules that adapt to the environment
they are in... e.g., I don't require Zope support but if you have it I
will dynamically derive a class from Persistant, or object otherwise:

base = object
import ZODB
base = ZODB.Persistant
# one of those rare cases where a bare except doesn't matter

class Whatever(base):

(I don't actually do this anywhere but I do the equivalent elsewhere in my

This is one of those things that keeps me from ever wanting to go back to
C++; you shouldn't make a habit out of this but when you need it there is
no substitute.

Reply With Quote

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off

Similar Threads
Thread Thread Starter Forum Replies Last Post
if statements and case statements questions John Crichton Ruby 6 07-12-2010 06:17 PM
Prepare Statements VS Statements Vince Java 12 01-21-2008 01:18 PM
component statements within architecture statements Neil Zanella VHDL 8 10-20-2006 09:05 AM
Mixing Constants into objects gabriele renzi Ruby 10 08-15-2005 09:31 PM
if statements with or w/o else statements Harry George Python 6 02-23-2004 06:48 PM