web2py used to be called Gluon so it is new but not too new. The main reason for bytecode compiling in web2py is that, for each page, the template+layout+included views are converted into a single bytecode compiled file. That means that when serving the page there is no parsing of the template, no pattern matching, no text replacement and therefore it is much faster than the alternative.
web2py is an open source full-stack Enterprise Web Framework written in Python and programmable in Python, designed for agile development of secure database-driven web-based applications.
I couldn't help but chuckle at that description. It has so many buzzwords in one sentence that the word "Python" really seems to clash. "Java" would have seemed more appropriate.
If we want python to take over java, we need to speak "their" language. Seriously, why don't you give it a try and tell me your impression? It takes 10 minutes.
Looks like some features include being able to byte-compile for closed source distribution and easy packaging (.app, .exe, or .py). That's pretty interesting for people who want to make and distribute python web apps.
byte compiling offers little protection against an even slightly motivated adversary; services like http://depython.net turn bytecode into readable source for a nominal fee.
True: compiling is obfuscation, not encryption but, the same argument applies to Java, VB, etc. Even compiled C++ can be disassembled. Anyway, web2py inlines some stuff before bytecode compiling so if you decompile a compiled web2py app you do not get a valid web2py app (because there is no one to one match between modules) unless you tweak it. In most of the cases it is not worth the task.
If your goal is to deny the competition free code, then, yes. But too often people think that they're successfully hiding some trade secret when they're not.
I agree. I do not get why he has chosen to emphasise the ticketing system instead. It seems like a pretty trivial thing to implement in most frameworks.
