from __future__ import decorators

[Jacek Generowicz]

I have some code, which makes copious use of the @decorator syntax
which was introduced in Python2.4. Now I find myself in a situation
where I have to run the code under Python 2.3. However, I would like
to keep developing the code with the new syntax.

How could I best automate the process of making the syntax digestible
by Python2.3 ?

 

[Thomas Heller]

I have some code, which makes copious use of the @decorator syntax
which was introduced in Python2.4. Now I find myself in a situation
where I have to run the code under Python 2.3. However, I would like
to keep developing the code with the new syntax.

How could I best automate the process of making the syntax digestible
by Python2.3 ?

The only way that I know of is this, although you have to rewrite your
code somewhat:

http://dirtsimple.org/2004/11/using-24-decorators-with-22-and-23.html

Thomas

 

[Peter Otten]

I have some code, which makes copious use of the @decorator syntax
which was introduced in Python2.4. Now I find myself in a situation
where I have to run the code under Python 2.3. However, I would like
to keep developing the code with the new syntax.

How could I best automate the process of making the syntax digestible
by Python2.3 ?

Have a look at Bill Mill's redecorate utility:

http://llimllib.f2o.org/files/redecorate.py

Peter

 

[Jacek Generowicz]

The only way that I know of is this, although you have to rewrite your
code somewhat:

The whole point would be to keep on developing perfectly normal
Python2.4 code, but have some means of getting it to run on 2.3,
without modification.

http://dirtsimple.org/2004/11/using-24-decorators-with-22-and-23.html

Certainly an interesting approach. Perhaps this can be combined with a
simple textual transformation of the source code which simply replaces
@decorator with add_assignment_advisor(decorator) ... or something
along those lines.

Still, I'd prefer to find a solution on the AST level, but I guess
that's not possible without re-writing the praser.

Crazy idea ... would it be possible to shadow 2.3's parser with one
stolen from 2.4 ?

 

[Jacek Generowicz]

Have a look at Bill Mill's redecorate utility:

http://llimllib.f2o.org/files/redecorate.py

Heh, this is exactly the sort of thing I wanted do avoid writing, as
it would be difficult to get right. Looks like it's author has similar
feelings. However, it could well be the most pragmatic solution in my
case.

Thanks.

 

[Skip Montanaro]

Jacek> Crazy idea ... would it be possible to shadow 2.3's parser with
Jacek> one stolen from 2.4 ?

If you're willing to go to that much trouble, why not just upgrade to 2.4?

Skip

 

[Jacek Generowicz]

Jacek> Crazy idea ... would it be possible to shadow 2.3's parser with
Jacek> one stolen from 2.4 ?

If you're willing to go to that much trouble, why not just upgrade to 2.4?

*I* upgraded to 2.4 sometime when it was in alpha.

 

[Tim Roberts]

I have some code, which makes copious use of the @decorator syntax

I'm very curious to know what kind of application you are writing in which
"copious use of the @decorator syntax" actually solved a problem
productively.

 

[Jacek Generowicz]

I'm very curious to know what kind of application you are writing in which
"copious use of the @decorator syntax" actually solved a problem
productively.

An application in which, before python2.4, I used to have lots of code
that looked like

def somefun(...):
...
somefun = somedecorator(somefun)




It's not interesting to discuss what "somedecorator" actually
represents. But being able to see that the function is decorated right
next to the "def", as opposed to having to look beyond the end of the
definition certianly makes a significant difference to me.