Sorry about making so many replies, I'm still getting used to the
Google Groups forums, but here is another response:
> I am not talking about parsing Python files. I am talking about parsing
> {{extend 'layout.html'}}{{for i in range(3)}}<h1>{{=i}}</h1> {{pass}} and
> turning this into a python file. My benchmarks show a big difference on
> complex pages. If you dig on the list they were published once.
I don't know if Django still does not do that, but I know for sure
that Mako, which is used in Pylons, does. It automatically produces
PYCs in that manner. From the direct comparisons from Django's
templating language and a compiled template engine like Mako (I
couldn't find a benchmark for the Web2Py templating engine anywhere),
the differences were 2:1 at most, and usually closer.
http://markmail.org/message/46opofod6ixwgill
On Jul 17, 3:13 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> On Jul 17, 4:54 pm, Bottiger <bottig...@gmail.com> wrote:
>
> > > It parses all views and collapses the three structure associated to each
> > > action into one byte-code compiled view. that means there is no
>
> > parsing and minimal file IO when executing a view in a bytecode
> > compiled app.
>
> > I don't think this makes a large difference in practice from the
> > benchmarks I have seen. In Django the code is automatically compiled
> > to a pyc upon running it. These pycs are likely to be cached in memory
> > on the OS level because they are not that big. So the difference
> > really is between 1 big disk cache lookup and 3 smaller ones. Even if
> > this does make a difference, it is arguably not big enough for the
> > common programmer to warrant switching. This is why web programming
> > has shifted to dynamic languages like Python and Ruby even though
> > there are people still doing C++, Java, and C#.
>
> I am not talking about parsing Python files. I am talking about
> parsing {{extend 'layout.html'}}{{for i in range(3)}}<h1>{{=i}}</h1>
> {{pass}} and turning this into a python file. My benchmarks show a big
> difference on complex pages. If you dig on the list they were
> published once.
>
> > > Also do not forget the licensing issues. Web2py executes applications and
> > > applications (generally) do not import web2py modules (with some
> > > exceptions). Instead Django applications import Django modules...
>
> > Actually this is not an issue at all. All the 3 major frameworks:
> > Pylons, Django, and Rails, do not use GPL (unlike Web2Py). They
> > instead use a freer BSD-style license that does not come with the
> > definition of "derivatives" which is so often a problem in GPL.
>
> The issue is freer for who. BSD is designed so that a business can
> take over a project and close source its derivative work. The "freer"
> part of BSD protects these kind of companies, not the actual project
> or its original developers.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"web2py-users" group.
To post to this group, send email to web2py@googlegroups.com
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en
-~----------~----~----~----~------~----~------~--~---
