0.9a5 on python2.3 - anyone have working?
hal
However, there's at least one "obvious" bug in a 0.9a5 quickstart
generated project (2.4. decorator, rather than 2.3 compatible syntax)
which hasn't been reported, so it doesn't feel like anyone is using it.
Before I start going through lots of issues - can anyone report
success?
Is there still demand for this? (My shop is stuck on py2.3 for a while
yet....)
Thanks,
--Hal
Kevin Dangoor
The official stance is that 2.3 is supported, but it's not the
encouraged platform. By that, I mean that all code in the turbogears.*
package is 2.3 compatible, but the examples and the quickstart
templates are geared toward 2.4 users.
Luckily, 0.9a5 includes a convenient syntax for decorators, which
should make changing a quickstart project a piece of cake.
@expose(template="...")
becomes
[expose(template="...")]
We have Phillip Eby and Simon Belak to thank for that little bit of magic.
The standard 2.3 way to use a decorator is:
index = expose(template="...")(index)
which is far less pleasant, and that's the reason why it's not the
default for quickstart.
Kevin
Simon Belak
Cheers,
Simon
--
Simon Belak
vodja projektnih skupin
e: simon...@hruska.si
---------------------------------------------------------------------
Hruska d.o.o., agencija za nove medije
Ilirska 21, SI-1000 Ljubljana
t: +386 1 430 25 86 f: +386 1 430 25 87
s: http://www.hruska.si
s: http://akademija.hruska.si (izobrazevalni portal)
s: http://www.elor.si (kadrovski sistem letnih razgovorov)
------------------------------------------------------------------------
Hruska.si - socne resitve
To elektronsko sporocilo in vse morebitne priloge so poslovna skrivnost
in namenjene izkljucno naslovniku. Ce ste sporocilo prejeli pomotoma,
Vas prosimo, da obvestite posiljatelja, sporocilo pa takoj unicite.
Kakrsnokoli razkritje, distribucija ali kopiranje vsebine sporocila je
strogo prepovedano.
This e-mail and any attachments may contain confidential and/or
privileged information and is intended solely for the addressee. If you
are not the intended recipient (or have received this e-mail in error)
please notify the sender immediately and destroy this e-mail. Any
unauthorized copying, disclosure or distribution of the material in
this e-mail, or any action taken or omitted to be taken in reliance on
it, is strictly prohibited.
Alberto Valverde
On 06/05/2006, at 12:55, Simon Belak wrote:
>
> Although we could be nice and make quickstart gnostic about Python
> versions.
You mean generating different content for each version? In this case
I think it'd be better to "templatize" the [] syntax to make sure
quickstarted apps work in both versions.
my .2€
Alberto
Kevin Dangoor
Ick. As cool a hack as it is, I wouldn't want to put the non-standard
[] syntax into a Python 2.4 project. Simon's point is valid, though:
we can easily make the template wise to the Python version in use.
It's worth opening a ticket on.
Kevin
Simon Belak
Opened as #837.
Cheers,
Simon
Jorge Vargas
Although we could be nice and make quickstart gnostic about Python versions.
#if python23
index = expose(template="...")(index)
@expose(template="...")
that's really ugly for a template :)
Cheers,
Simon
Kevin Dangoor
#if python23
[expose(template="...")]
#else
@expose(template="...")
#end
And that's not *that* bad.
Kevin
Jorge Vargas
this wont get nonstd python code in 2.4 templates.
Yes your right it's not that bad but with this and the identity, later the provider code. those templates will end up being spagetti :)
Jorge Godoy
>
> Yes your right it's not that bad but with this and the identity, later the
> provider code. those templates will end up being spagetti :)
Yes, finding out where is each part is a bit messy indeed... And the more
variations the worse it will get. On the other hand, we're trading this for
user friendliness. I prefer spending a bit more of my time to make users
happy.
What we need to have, then, is documentation for those templates: where is
each thing, how to change it, etc.
--
Jorge Godoy <jgo...@gmail.com>
Robin Haswell
> I prefer spending a bit more of my time to make users
> happy.
Good to know you'll never write for the gnome project then ;-)
(Sorry)
On a more constructive note, this might sound silly but can't we just do this by performing a
regular expression on quickstarted source?
Try this:
$ cat controllers.py|sed -r 's/^(\s+)@([a-z_]+\(.*\))\s*$/\1[\2]/i'
It only works on single-line decorators (multiline might be a little beyond my regexp skill) but it
seems to do the job. I think the experession for a python symbol - [a-z_] - is a little off, but
someone can easily sort that out. You could even replace it with [^(] .
Of course that regexp is fine to just dump in to re.compile() -
re.compile(r's/^(\s+)@([a-z_]+\(.*\))\s*$/\1[\2]/', re.I)
Quick question - why does the "[expose(...)]" work?
Cheers
-Rob
Jorge Godoy
> Jorge Godoy wrote:
> > I prefer spending a bit more of my time to make users
> > happy.
>
> Good to know you'll never write for the gnome project then ;-)
>
> (Sorry)
Why? I won't indeed. ;-)
> On a more constructive note, this might sound silly but can't we just do
> this by performing a regular expression on quickstarted source?
>
> Try this:
>
> $ cat controllers.py|sed -r 's/^(\s+)@([a-z_]+\(.*\))\s*$/\1[\2]/i'
>
> It only works on single-line decorators (multiline might be a little beyond
> my regexp skill) but it seems to do the job. I think the experession for a
> python symbol - [a-z_] - is a little off, but someone can easily sort that
> out. You could even replace it with [^(] .
>
> Of course that regexp is fine to just dump in to re.compile() -
> re.compile(r's/^(\s+)@([a-z_]+\(.*\))\s*$/\1[\2]/', re.I)
>
> Quick question - why does the "[expose(...)]" work?
I prefer maintaining an English template -- even though English is not my
primary language -- than working with regular expressions (and I have a Perl
(!!!) background... ;-)).
I believe that there's some way to declare it like this:
#if python23
#def expose_decorator
[turbogears.expose()]
#end def
#def identity_decorator
[identity.require(...)]
#end def
#else if python24
#def expose_decorator
@turbogears.expose()
#end def
#def identity_decorator
@identity.require(...)
#end def
#end if
and then use it like:
#expose_decorator
or
#insert expose_decorator
Something like this looks much more maintainable to me and it is easy to
use...
BUT, I don't know the syntax for this template, so...
--
Jorge Godoy <jgo...@gmail.com>
Alberto Valverde
Robin Haswell
> Em Segunda 08 Maio 2006 17:16, Robin Haswell escreveu:
>> Jorge Godoy wrote:
>>> I prefer spending a bit more of my time to make users
>>> happy.
>> Good to know you'll never write for the gnome project then ;-)
>>
>> (Sorry)
>
> Why? I won't indeed. ;-)
Oh, my pet hate about GNOME is that their idea of "user friendliness" is drastically slashing
features and functionality that users are crying out for (and ignoring pleas for re-inclusion). I
swear most of the checkins to GNOME must be on the lines of
@@ 100 @@
+ /* Our users don't need this
@@ 1500
+ */
I don't think this scales.. if decorators transformations really are as simple as my regular
expression, then using an intermediate syntax for a decorator and then doing the appropriate
substitutions would be better. Just as an example, something like:
class Something(controller.Root):
$[[[expose(template="...")]]]
def index(self):
""" ... """
pass
Then when we write the template we can change those to the correct form.
... with a regular expression ;-)
-Rob
Kevin Dangoor
> class Something(controller.Root):
> $[[[expose(template="...")]]]
> def index(self):
> """ ... """
> pass
>
> Then when we write the template we can change those to the correct form.
Here's a simple solution. Define b (for begin) as "@" or "[" and e
(for end) as "" or "]".
${b}expose(template="..")${e}
def index(self):
....
The templates aren't pretty, but they're quite easily maintained, no
multiline weirdness, no regex pain.
Kevin
Jorge Vargas
On 5/8/06, Robin Haswell <r...@digital-crocus.com> wrote:
> class Something(controller.Root):
> $[[[expose(template="...")]]]
> def index(self):
> """ ... """
> pass
>
> Then when we write the template we can change those to the correct form.
Here's a simple solution. Define b (for begin) as "@" or "[" and e
(for end) as "" or "]".
good thinking +1
${b}expose(template="..")${e}
def index(self):
....
The templates aren't pretty, but they're quite easily maintained, no
multiline weirdness, no regex pain.
and we'll needs docs to write templates hehe. :)
Kevin
hal
> The official stance is that 2.3 is supported, but it's not the
> encouraged platform. By that, I mean that all code in the turbogears.*
> package is 2.3 compatible, but the examples and the quickstart
> templates are geared toward 2.4 users.
I'm not sure anyone is actually using it - no one has stepped forward
to state they have :(
Yes, the decorator syntax is well documented and an easy adjustment.
However there are other issues. (I suspect that there are no tests
being run on a 2.3 install by the dev team :))
I just opened trac ticket #853 with a patch - at least now I can get
the basic quickstart to run.
I'll do the wiki tutorial next. I note that there are several methods
in FormEncode that use decorators as well. I may not bump into them, or
need them for my work.
I'll try to get an svn checkout going, so I can run the nosetests under
2.3....
--Hal