I am happy for the efforts being made in web2py. I think we should have
a better way to file a bug or request a feature. But after buying the
book, I am very happy documentation wise.
On Mon, 2009-08-03 at 06:18 -0700, Pynthon wrote:
> I'm reading this topic for a time and it really makes me doubt about
> web2py =[. Hopefully Massimo can fix this =].
>
> On 3 aug, 02:46, Bottiger <bottig...@gmail.com> wrote:
> > I haven't had time to verify the other findings, but there are
> > definitely file handle leakages. I can never delete an application if
> > I just visited it once.
> >
> > On Aug 2, 12:21 pm, mdipierro <mdipie...@cs.depaul.edu> wrote:
> >
> > > I am about to catch a plane so I will be short. We can talk more about
> > > this in a couple of days.
> >
> > > > > First a word of warning. I send you this mail in private because I
> > > > > want
> > > > > to share my thoughts on the web2py code and because I hope I can help
> > > > > with that somehow. You're free to publish this mail if you want.
> >
> > > This is constructive criticism so I appreciate it.
> >
> > > > > As you might remember I came in contract with web2py a long ago when
> > > > > you
> > > > > were evaluating pygments as a syntax highlighter for the web2py
> > > > > documentation or something and you decided to implement your own
> > > > > because
> > > > > you were unable to "ship" pygments as part of web2py. As far as I
> > > > > remember py2app or py2exe were not able to pick up the on-demand
> > > > > imports
> > > > > in the lexer module.
> >
> > > > > I have been watching the development ever since because (And please
> > > > > don't think bad of me because of that) it appeared to me that web2py
> > > > > was
> > > > > a joke. I remember reading some very early revisions of your PDF
> > > > > documentation where I remember a code that looks something like that:
> >
> > > > > db.define_table('something', db.Field('meh', 'date',
> > > > > default=date.today()))
> >
> > > > > That line freaked me out. This line alone showed me that web2py is
> > > > > doing something very, very weird. From this line I could see that it
> > > > > means one of the following two things:
> >
> > > > > - either the code has a bug for long running applications (in this
> > > > > case
> > > > > when the application code runs longer than a day in which case the
> > > > > default would have to change dynamically)
> >
> > > > > - or the global scope has different semantics and is reevaluated each
> > > > > request.
> >
> > > > > Turns out the latter is what happens in web2py.
> >
> > > Correct.
> >
> > > > There still is a race
> > > > > condition but only a small one.
> >
> > > No there is not. Why do you think there is a race condition?
> >
> > > > The bigger problem with this
> > > > > however is
> > > > > that this means the (not so) static definitions are reevaluated each
> > > > > request.
> >
> > > Correct. A small price to pay for a lot of flexibility.
> > > We are working on lazy evaluation of tables.
> > > There is also a speedup if you press the "compile" button in admin.
> >
> > > > > Especially for the database table definitions (which cause many
> > > > > function
> > > > > calls) this means an enormous per-request penality if you have many of
> > > > > them. I even remember reading a case like this in the web2py
> > > > > newsgroup
> > > > > about someone who had twenty table definitions or something and the
> > > > > majority of the request time was spent setting up the tables.
> >
> > > There was a slow down problem that has been fixed by Alexey. I agree
> > > there is still room for improvement.
> >
> > > > > However that also means another thing. Standard Python
> > > > > optimizations no
> > > > > longer apply. In Python usually modules are cached in an interpreter
> > > > > bound dictionary for reusing. This of course does not apply for
> > > > > web2py.
> > > > > However the second problem here is that only the local scope gets
> > > > > certain optimizations in cpython such as fast-local lookup. Instead
> > > > > of
> > > > > storing the variables in a dictionary they are instead stored in an an
> > > > > object where items are looked up by index (fast locals) rather than
> > > > > by a
> > > > > string.
> >
> > > > > Now of course one can argue that this is the way it's intended.
> > > > > That's
> > > > > nice but for that, the documentation is lacking.
> >
> > > Yes it is true that documentation is lacking.
> >
> > > > There is no
> > > > > explanation of what implications this has on the code. And in
> > > > > comparison with "enterprise ready" that gives me a strange feeling
> > > > > about
> > > > > the project.
> >
> > > > > I'm not even exactly sure what kills web2py for me in the end, but I'm
> > > > > pretty sure that part of the reason is the way the project is
> > > > > advertised.
> >
> > > We prefer to talk about "advocating" not "advertising" since we do not
> > > sell it.
> > > Mistakes were made on my side.
> >
> > > > > web2py does not have worse code than many popular libraries out there.
> >
> > > Thanks. I take is as a compliment.
> >
> > > > > BeautifulSoup comes to mind. That library does some really ugly
> > > > > things
> > > > > there including monkeypatching of the standard library. It does
> > > > > different things depending on the version of Python it's running on
> > > > > and
> > > > > in the code are some really ugly idioms like a unicode subclass that
> > > > > has
> > > > > a reference to the parsed tree that results in memory leaks very
> > > > > easily
> > > > > because it's nearly impossible to get rid of the reference (actually
> > > > > just by exploiting some weird Python internals that are mostly
> > > > > undocumented). But the author of BeautifulSoup does not advertise
> > > > > it as
> > > > > a backwards-compatible, enterprise ready HTML parser.
> >
> > > > > The web2py code on the other hand has some really problematic idioms
> > > > > as
> > > > > well. The execution of models, views and whatnot in a made-up
> > > > > namespace
> > > > > comes to mind.
> >
> > > Yes. It was a design decision to be closer to Rails than Django in
> > > this respect. I think this is what is making web2py popular, more than
> > > anything else.
> >
> > > > Due to the decision of being backwards compatible it
> > > > > will be nearly impossible to "fix" those things.
> >
> > > We think of them as features, not bugs.
> >
> > > > However there are so
> > > > > many implications nobody yet knows about which is terribel for large
> > > > > projects.
> >
> > > > > For example the database table redfinition problem cited above. Of
> > > > > course that particular problem can be worked around with making the
> > > > > definition code internally lazy or something but there can be more
> > > > > nobody yet knows about.
> >
> > > Alexey has already done this. It achieves a 10-20% speedup. I am
> > > rewriting the DAL completely to make it easier to port on other
> > > backends and faster. The new one may support lazy evaluations of
> > > tables. Time permitting,
> >
> > > > > Especially side-effects of code execution can do some terrible damage.
> > > > > Decorators that would register code would instantly leak for example.
> > > > > And some libraries provide auto-registration that you would not
> > > > > instantly know about.
> >
> > > Can you provide an example of what you mean? I am pretty sure there is
> > > no leak.
> >
> > > > > Also libraries like pickle do not support weird situations like this.
> > > > > So I guess in the end I'm not (only) complaining about the web2py code
> > > > > or decisions there, but mainly how web2py is advertised as enterprise
> > > > > ready when nobody knows how these idioms scale or behave.
> >
> > > I disagree with "nobody knows how these idioms scale or behave"?
> > > We have been doing this for 2 years. We know very well how it works
> > > and scales.
> > > It actually works very well because as soon as a request is completed
> > > the environment is deleted, this is clean, avoids conflicts when
> > > multiple apps are running, and prevents memory leaks.
> >
> > > > > Another part is that web2py (and this is something web2py has in
> > > > > common
> > > > > with so many other web frameworks) is the craze to reimplement
> > > > > everything. I know you don't want to pull depedencies in but from
> > > > > what
> > > > > I can see you're providing one-click installers for the framework
> > > > > which
> > > > > could ship external dependencies. Both py2exe and py2app provide
> > > > > support for external dependencies and I can't see what "not
> > > > > depending on
> > > > > webob/werkzeug" gives you there.
> >
> > > web2py started as a teaching tool. It was important (and still is)
> > > that I can go over every line of code with my students know exactly
> > > why it is there.
> >
> > > > > The reason why I'm addressing this is that there are so many
> > > > > limitations, problems and weird aspects in WSGI and HTTP that are hard
> > > > > to tackle and many people get wrong.
> >
> > > I agree.
> >
> > > > I'm not saying you're getting it
> > > > > wrong, I haven't even studied the code in question, but I'm pretty
> > > > > sure
> > > > > it would make sense to collaborate on that.
> >
> > > I like the idea. Some conditions have to be met:
> > > 1) we have a new contributor license agreement on web2py-developers
> > > 2) patches must not break backward compatibility
> > > 3) patches must either make the code smaller/faster, or add a needed
> > > functionality.
> >
> > > > > About the code quality itself, not the (IMO) broken concepts I picked
> > > > > some of the snippets I found quickly searching with the help of ack:
> >
> > > > > - Missing `close()` calls with files (ignored matches from
> > > > > compileapp):
> >
> > > > > gluon/fileutils.py:160: f.write(open(tarname, 'rb').read())
> > > > > gluon/fileutils.py:246: data = open(filename, 'rb').read()
> > > > > gluon/highlight.py:313: data = open(sys.argv[1]).read()
> > > > > gluon/languages.py:37: lang_text = open(filename, 'r').read()...
> > > > > gluon/languages.py:153: data = open(file, 'r').read()
> > > > > gluon/main.py:107:web2py_version = open(os.path.join(web2py_path, ...
> > > > > gluon/rewrite.py:26: exec open('routes.py', 'r').read() ...
> > > > > gluon/template.py:104: text = open(os.path.join(path, ...
> > > > > gluon/template.py:118: parent = open(t, 'rb').read()
> > > > > gluon/template.py:134: child = open(t, 'rb').read()
> > > > > gluon/tools.py:1934: return urllib.urlopen(url).read()
> > > > > gluon/widget.py:55:ProgramVersion = open('VERSION', ...
> >
> > > > > - Same in
> >
> > ...
> >
> > meer lezen »
> >
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
