<begin file apps/welcome/main.py>import timefrom web3py import DAL, Field, expose, Form, DALForm, IS_NOT_EMPTY, HTTP, tagdb = DAL('sqlite://storage.test')db.define_table('person',Field('name',requires=IS_NOT_EMPTY()))@expose() # /appname/indexdef index(current):form = Form(Field('name',requires=IS_NOT_EMPTY())).process(current)if form.submitted and form.processed and form.accepted: print form.varselif form.submitted: print form.errorsmessage = form.vars.name or ''return locals()@expose('/test_args/<str:a>(/<int:b>)?') # /appname/test_args/hello/1def test_args(current,a,b=9): # args are parsed, validated and passed to actionreturn repr(dict(a=a,b=b))@expose(template='index.html')def test_form(current):form = DALForm(db.person, record_id = None).process(current)message = tag.div(tag.h1(form.vars.name))return locals()@expose(cache_expire=10)def timer(current):return time.ctime()@expose()def try_redirect(current):HTTP.redirect(current.url('index')) # does reverse routing<end>
Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this in my mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for example parsing of url, headers, accept_languages, etc) and make everything lazy.2) eliminate request, response, session, T, cache objects and have a single "current" object. It should not be a thread local to avoid locking issues, but it should be passed around.
3) eliminate all the exec/execfiles but preserve some version of the current multi-applications folder structures. Each app will have an entry point (main.py) where actions are registered to allow a freer structure at the app level.4) A global routes to configure "only" application prefixes. Then each app is in charge of its own internal routing, perhaps using decorators as Flask does.
5) No more global environment. Apps will do "from web3py import *" (see below)6) No more file-system write unless to install/edit apps. We store session in cookies (if small) or db (if large) and tickets always in db (so they can be searched and cleared more easily). They will not go in the app db but in a dedicated common ticket db.7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamed them tag, cat, safe, beautify, menu (with simpler logic)8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They will have a simpler logic that separates the HTML representation from the input processing, thus it will be faster and will be able to handle non-html form submission (ajax, xml) while using a syntax similar to the current one.9) No more appadmin. There should be a global application to manage the databases of all the apps.10) should work with python 2.7 and 3.x11) A compatibility layer that will allow to run most existing web2py applications when using python 2.7.12) no more cache.disk but better cache.ram (renamed as cache) with actual expiration (current cache.ram only expires when accessed).13) automatic reverse routing14) keep only dal.py and template.py from existing web2py.
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
On 25 Oct 2012, at 9:21 AM, Massimo DiPierro <massimo....@gmail.com> wrote:Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this in my mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for example parsing of url, headers, accept_languages, etc) and make everything lazy.2) eliminate request, response, session, T, cache objects and have a single "current" object. It should not be a thread local to avoid locking issues, but it should be passed around.Are there locking issues? My impression is that there are not. The object is locked very briefly, but the lock is released immediately, is it not? I'm doubtful that there would be a measurable performance gain from avoiding the lock altogether, and it's a considerable PITA to have to pass an extra argument everywhere.A single object for sure.Related: maybe a well-defined persistent global per-application state.
3) eliminate all the exec/execfiles but preserve some version of the current multi-applications folder structures. Each app will have an entry point (main.py) where actions are registered to allow a freer structure at the app level.4) A global routes to configure "only" application prefixes. Then each app is in charge of its own internal routing, perhaps using decorators as Flask does.Routing by decorator could be a real rat's nest in a big app. At the very least it should be possible to do central (per-app) routing.
5) No more global environment. Apps will do "from web3py import *" (see below)6) No more file-system write unless to install/edit apps. We store session in cookies (if small) or db (if large) and tickets always in db (so they can be searched and cleared more easily). They will not go in the app db but in a dedicated common ticket db.7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamed them tag, cat, safe, beautify, menu (with simpler logic)8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They will have a simpler logic that separates the HTML representation from the input processing, thus it will be faster and will be able to handle non-html form submission (ajax, xml) while using a syntax similar to the current one.9) No more appadmin. There should be a global application to manage the databases of all the apps.10) should work with python 2.7 and 3.x11) A compatibility layer that will allow to run most existing web2py applications when using python 2.7.12) no more cache.disk but better cache.ram (renamed as cache) with actual expiration (current cache.ram only expires when accessed).13) automatic reverse routing14) keep only dal.py and template.py from existing web2py.15) First-class support for RPC-oriented apps or functions, including proper error handling (no redirecting of a JSON request to an HTML error page).
16) Built-in support for long-running processes of some kind, independent of requests. Not sure what--maybe the current scheduler model, or the GAE task model?
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
Routing by decorator could be a real rat's nest in a big app. At the very least it should be possible to do central (per-app) routing.Basically expose (in the example below) is the app-level router. It stores info in expose.routes_in and expose.routes_out. We can add an interface to pre-define them all in main.py. You would still need to use the @expose decorator, although no needs to parse arguments. Would this be ok?
On 25 Oct 2012, at 10:07 AM, Massimo DiPierro <massimo....@gmail.com> wrote:Routing by decorator could be a real rat's nest in a big app. At the very least it should be possible to do central (per-app) routing.Basically expose (in the example below) is the app-level router. It stores info in expose.routes_in and expose.routes_out. We can add an interface to pre-define them all in main.py. You would still need to use the @expose decorator, although no needs to parse arguments. Would this be ok?I think so, yes.Two more things.* Have you given any thought to a non-blocking event-driven structure?
* Ajax. Are we satisfied with the current mechanisms for interacting with client-side JavaScript?
* Ajax. Are we satisfied with the current mechanisms for interacting with client-side JavaScript?No. What do you propose?
on 12) .... an LRU cache is quite fine, and it's ready in standard library (functools) . We'd need also something like cache.update(key) to close the deal off the "thundering herd" problem (lock is used to avoid that right now, but, e.g. I'd like to compute the most 10 new articles on my blog and cache that info, and recalculate that only when I insert a new article, current cache kinda of gets in the way (need to clear() and cache(), where I'd really like to serve the stale object instead as long as the fresh one is not in there)).
Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this in my mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for example parsing of url, headers, accept_languages, etc) and make everything lazy.
2) eliminate request, response, session, T, cache objects and have a single "current" object. It should not be a thread local to avoid locking issues, but it should be passed around.
3) eliminate all the exec/execfiles but preserve some version of the current multi-applications folder structures. Each app will have an entry point (main.py) where actions are registered to allow a freer structure at the app level.
4) A global routes to configure "only" application prefixes. Then each app is in charge of its own internal routing, perhaps using decorators as Flask does.
5) No more global environment. Apps will do "from web3py import *" (see below)6) No more file-system write unless to install/edit apps. We store session in cookies (if small) or db (if large) and tickets always in db (so they can be searched and cleared more easily). They will not go in the app db but in a dedicated common ticket db.
7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamed them tag, cat, safe, beautify, menu (with simpler logic)
8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They will have a simpler logic that separates the HTML representation from the input processing, thus it will be faster and will be able to handle non-html form submission (ajax, xml) while using a syntax similar to the current one.
9) No more appadmin. There should be a global application to manage the databases of all the apps.
10) should work with python 2.7 and 3.x
11) A compatibility layer that will allow to run most existing web2py applications when using python 2.7.
12) no more cache.disk but better cache.ram (renamed as cache) with actual expiration (current cache.ram only expires when accessed).
13) automatic reverse routing
14) keep only dal.py and template.py from existing web2py.
--
Hi Massimo + all,Forgive me if what I write is old. I started replying, but I was interrupted many times so my reply is old since it is not update with all the other's replies.mic2012/10/25 Massimo DiPierro <massimo....@gmail.com>Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this in my mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for example parsing of url, headers, accept_languages, etc) and make everything lazy.I'd look into something to add interceptors or something similar to the WSGI shells, but cleaner, dynamic and simpler.
2) eliminate request, response, session, T, cache objects and have a single "current" object. It should not be a thread local to avoid locking issues, but it should be passed around.What about using Borg(s)? Maybe looking in multiprocessing module could bring fresh ideas.
I see why you're busy now!!!
some random thoughts....
- session handling with cookies or db is a good idea, but locking must be considered for the single session (or we drop the idea of locking the session?). having a separate db just for session is ok, I guess (I use it already), but a sqlite db will choke sooner than file-based sessions (as long as WAL isn't activated by default http://code.google.com/p/web2py/issues/detail?id=984). A single session creation (insert or update) will block reads for every other session, that is, the entire site blocked for a while.
- LOAD is good, given that almost all modern apps seems to support some kind of "component" reloading instead of reloading all the page. the only bit missing is pjax-style history management, in order to let only a part of the page to be reloaded and have consistent urls.
- what I find in every project really really hard is some kind of "shared" initialization of my own classes and modules. Having something persistent that is not related to cache.ram is hard (managed right now with singletons, but that logic is not linear). e.g., for w2p_tvseries I'd like to use the same requests object (the "modern" urllib) to interact with various webservices, without istantiating a connection everytime. For another project, e.g. storing fixtures and/or settings to be executed on load or at the 1st request only is a PITA. Yes, there is cache, but not everything is serializable.
- I think the main "difference" in web2py vs others is the ability to have everything re-executed at run-time. Pros: faster development, cons: slower in production. Since I see a "move" towards having all loaded at start and never read again, I'm eager to see what will come up (restarting webserver each time is not really nice).
Scheduler can benefit from a rewrite, for sure: e.g. now it's just a web2py shell executing all over again whatever the code is. Pros: you can change all your app and never stop the scheduler, cons: slower in production. Other implementations load everything at the start and execute only the function (faster). The main example is, you have to send an email. You could easily skip large chunks of code of your app just to send that email, and currently is faster to run the Scheduler in "external" mode than having all modules reloaded for every mail you'd like to send. However, keeping execution environment "separated" and pass all the objects in multiprocessing.Queues can be painful (i.e., db connections objects)
- new routing: I like the flexibility right now, but the code is cumbersome, and users just can't face it (don't know why, django urls are not that different). Don't know if flask syntax is more understandable, but it seems to grip better into users heads (not in mine, though, I'll learn )
- I like 8) a lot. All the "moves" between sqlhtml, validators, dal, html is hard to understand. I got a grip on that just after a few rounds of debugging. Idea to consider: a simple way to code widgets, with html, js, validation, presentation layers separated but with a "linear" flow logic. I recently had to come up with handling different timezones and had to write more code than I expected: then I realized it was better to pack it as a plugin, then I quit the idea because web2py plugins are really not first class citizens... I don't think that currently many users watch them
- 12) in multiprocessing environments cache.disk is the only "embedded" cache a user can lean towards. I use redis a lot and I'm happy with that, but memcache and redis are not really spread amongst Windows developers.
- adding a remote 17)... supporting nosql dbs is hard, but current implementation lacks for any hope of stability in the future (needs more testers without doubts). Any "internal" module (auth, scheduler, wiki, sessions) needs some "hook" to intercept store/retrieve in a de-normalized form. If we're going to rewrite them from scratch (in Italy we say, "fatto 30, facciamo 31", in English I think is "in for a penny, in for a pound"), we should avoid implicit foreign keys
- a remote 18) that is a wish for DAL: support for nested transactions (or contexts, we're talking about 2.7 to 3.0, where context are available for a while). I found contexts in python really useful for handling transactions.... Right now to be safe a developer is "forced" to do a db.commit() to save the current status, update/insert/delete and then again db.commit().
About cache I like the way of wheezy.web in CacheProfile. http://packages.python.org/wheezy.http/userguide.html#cache-profile
--
http://martinmulone.com.ar
On Thu, Oct 25, 2012 at 1:21 PM, Massimo DiPierro
<massimo....@gmail.com> wrote:Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this inmy mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for exampleparsing of url, headers, accept_languages, etc) and make everything lazy.
web2py will be a microframework?
2) eliminate request, response, session, T, cache objects and have a single"current" object. It should not be a thread local to avoid locking issues,but it should be passed around.
nice but "current" wording can be misleading, why not a more explicit
request and response?
(like now…)
3) eliminate all the exec/execfiles but preserve some version of the currentmulti-applications folder structures. Each app will have an entry point(main.py) where actions are registered to allow a freer structure at the applevel.
how will it manage "in-the-fly" modifications?
are you saying good by to the online IDE?
that kind of dynamism is what makes web2py different and easy to learn/use
4) A global routes to configure "only" application prefixes. Then each appis in charge of its own internal routing, perhaps using decorators as Flaskdoes.
this will be hard to explain to beginners and can cause a mess in the
app structure
a standard directory layout about where to put each file (MVC) is a
good approach now
yes, it is rigid, but it works for the majority of webapps made with web2py
5) No more global environment. Apps will do "from web3py import *" (seebelow)
for the permormance perspective, this is equal or worse than the
current approach
also, import * should be discouraged as it chokes IDE and static checkers
a shorter namespace would be useful, like
import w3p
db = w3p.DAL(....)
or better:
from web2py import dal
db = dal.DAL(
dal.Field('foo', dal.STRING,
requires=dal.IS_IN_SET([])
)
(btw, I think this is currently achievable nowadays)
6) No more file-system write unless to install/edit apps. We store sessionin cookies (if small) or db (if large) and tickets always in db (so they canbe searched and cleared more easily). They will not go in the app db but ina dedicated common ticket db.
nice, but a better fine-grained ticket system should be necessary to
further enhance performance and avoid some pitfalls in production
(a bunch of tickets without enough detail was not very useful in my experience)
in development, a more interactive inspection would be better than
storing the error snapshot, like paste.evalexception.middleware
http://tools.cherrypy.org/wiki/PasteEvalException7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamedthem tag, cat, safe, beautify, menu (with simpler logic)
why not a namespace?
from web2py import tag
tag.DIV
or better:
from web2py.tag import A, IMG, ...
IMHO helpers are part of web2py differentiation for easiness, why
remove or complicate them?
8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They willhave a simpler logic that separates the HTML representation from the inputprocessing, thus it will be faster and will be able to handle non-html formsubmission (ajax, xml) while using a syntax similar to the current one.
good
again, namespaces maybe useful here
why this cannot be backported to web2py?9) No more appadmin. There should be a global application to manage thedatabases of all the apps.
good10) should work with python 2.7 and 3.x
bad, wasn't web3py py3k only?
having two active versions could create confusion in users, be a
maintenance nightmare and will not enable to take some advantages from
python 3 new features
or are you planing to discontinue web2py?
11) A compatibility layer that will allow to run most existing web2pyapplications when using python 2.7.
ah, ok, you are planning to discontinue web2py...
IMHO they should be two different projects to avoid any misunderstanding12) no more cache.disk but better cache.ram (renamed as cache) with actualexpiration (current cache.ram only expires when accessed).
cache.disk is useful in some places, surely I'm missing why this is evil
13) automatic reverse routing14) keep only dal.py and template.py from existing web2py.
why not separate them as proper packages?
what about gluino?
return repr(dict(a=a,b=b))@expose(template='index.html')def test_form(current):form = DALForm(db.person, record_id = None).process(current)message = tag.div(tag.h1(form.vars.name))
div is a function, method or a class here?
it should be Div() ?
why not DIV ?
anyway, we'll suffer from explicit boilerplate code :-)return locals()@expose(cache_expire=10)def timer(current):return time.ctime()@expose()def try_redirect(current):HTTP.redirect(current.url('index')) # does reverse routing<end>As you can see the syntax is similar for an easier transition. To benefitfrom speed apps will have to be rewritten.Legacy web2py welcome app, without tools and session also works. I will addtools and session support asap.The error tickets also need work but I just discovered inspect.stack and hadan epiphany!Am I on the right track?
maybe from the pythonic standpoint, but who will care?
we'll become a common framework like everyone else
why will anyone use web3py instead flask+sqlachemy, django or whatever?
Want to help?
no, as I say in earlier mails, I don't see the point here, so sorryComments suggestions?
IMHO stick with web2py, split it in standalones modules and add
alternative implementations with current structure, so it can be
comparable in minimal benchmarks :-)What can we do better?
enhance web2py to a better 3.0 version
When should apps be reloaded (since they are no longer executed we must trigger reload)?
you can't, you'll have to restart the whole server
reload is one of the missing pieces in py3k
What would you like to see changed?
not much, I'm quite happy with web2py
I think we should have more complex app to do a deeper analysis
I've learned a lot of things this year with web2conf for PyCon
Argentina 2012 conference, it is "advanced" as Pinax Symposion (and
even it may have more features), and still it is simple (in the web2py
sense), easy to understand and it could be optimized to reach
acceptable performance without compromising dynamism.
Should we preserve validators as they are?
we should preserve as most as possible to not break backward compatibility
Should we have a built-in realtime event handling for websockets in everyapp? What do we do with the LOAD helper? what do we do with web2py.js? Do westill need response.files of should we make more use of template {{block…}}to inject stuff in <head/>? Should we backport some of new stuff (Form,cache, helpers) to web2py?
yes to them all (excepting the complex {{block}} thing and the
realtime event handling)If we take this route, we need to have a permanent feature freeze on web2py,except on DAL and Template which are the only shared modules.
this is the part I dislike
I think we can keep improving web2py and make alternatives or further
works possible
I will share my code next week, as soon as I get sessions to work.You will appreciate the clarity compare with the current web2py. Inparticular the helpers and form handling logic.
IMHO that we should clean up the code is not a reason to start a
massive rewrite from scratch.
I argued in previous discussions that this seems like the second
system effect (and according the literature, it has not been good for
any project...):
http://en.wikipedia.org/wiki/Second-system_effect
This is a nice article explaining why:
http://www.joelonsoftware.com/articles/fog0000000069.html
For example, DAL has more important problems like the id/keyed table
and could be optimized in the id/sequence/autonumeric handling, bool
logic, left joins, etc.
Fixed that it should be taken more seriously to be used in standalone,
gui and other web applications/frameworks.
They are in my TODO list, or wish list as this year I didn't have enough time :(
About the odd benchmark, please read the discussion in django-dev about this.
For me, just because web2py isn't faster that ever
minimicrosmallpythonframework out in the wild is not a an enough
excuse for a big re-design.
That's why I think gluino idea was amazing, if we could take the best
of both worlds (full-stack and micro-framework), why not?
Sorry for my lack of optimism
class expose(object):
def __init__(self, cleaners=[]):
self.cleaners = cleaners
class expose(object):
def __init__(self, cleaners=None):
if not cleaners:
self.cleaners = []
Just one thing, I do not know the py3k but in py2k the code likeclass expose(object):
def __init__(self, cleaners=[]):
self.cleaners = cleaners
can be really nasty. cleaners=[] is computed only one time. So all expose instances have cleaners pointing to the some address. If there is a goal than ok.
I'm not a big python programmer just had a bad day once with this problem :-o
I used to doclass expose(object):
def __init__(self, cleaners=None):
if not cleaners:
self.cleaners = []
now.
On 26 Oct 2012, at 12:25 AM, szimszon <szim...@gmail.com> wrote:Just one thing, I do not know the py3k but in py2k the code likeclass expose(object):
def __init__(self, cleaners=[]):
self.cleaners = cleaners
can be really nasty. cleaners=[] is computed only one time. So all expose instances have cleaners pointing to the some address. If there is a goal than ok.The problem isn't so much that they're pointing to the same object as that the object they're pointing to is mutable. If an expose object mutates its self.cleaners, they all get mutated (well, the ones that aren't otherwise initialized, anyway).
I'm not a big python programmer just had a bad day once with this problem :-o
I used to doclass expose(object):
def __init__(self, cleaners=None):
if not cleaners:
self.cleaners = []
now.self.cleaners = [] if cleaners is None else cleanersorself.cleaners = cleaners or []
@expose('/index/<str:a>(/<int:b>)?')def index(a,b=3)
Do you like better:@expose('/index/<str:a>(/<int:b>)?')def index(a,b=3)or this@expose('/index)def index(a = Arg('str'), b = Arg('int',default=3))we cannot use the python 3 notation because it would not work with 2.7 and it not reach enough to specify validators for args.
1st stone, then it's bed-time, sorry.... there's no runme.py in the repo :P
I see little holes here and there (but I acknowledge the "work in progress" status, don't mind) but I'm amazed nonetheless by the readability of the flow logic. Will take very little time tomorrow to fully grasp all the bits.
Running with Python 3.3 getting this ...c:\java\web3py>c:\python3\python.exe runme.pyTraceback (most recent call last):File "runme.py", line 2, in <module>from web3py import runFile "c:\java\web3py\web3py\__init__.py", line 1, in <module>from .wsgi import runFile "c:\java\web3py\web3py\wsgi.py", line 9, in <module>from .cleaners import smart_tracebackFile "c:\java\web3py\web3py\cleaners.py", line 52def __init__(self): print 'connecting'^SyntaxError: invalid syntax
On Fri, Oct 26, 2012 at 12:33 AM, Massimo DiPierroDoes it make any difference if its create 1 object instead of three?
<massimo....@gmail.com> wrote:
>
> On Oct 25, 2012, at 9:13 PM, Mariano Reingart wrote:
>
> On Thu, Oct 25, 2012 at 1:21 PM, Massimo DiPierro
> <massimo....@gmail.com> wrote:
>
> Hello everybody,
>
>
> Time to start thinking about web3py. And as I think about it, I hear this in
>
> my mind: http://www.youtube.com/watch?v=HofoK_QQxGc
>
>
> Here is what I have in mind and I am building a prototype:
>
>
> 1) eliminate every computation done when the request arrives (for example
>
> parsing of url, headers, accept_languages, etc) and make everything lazy.
>
>
> web2py will be a microframework?
>
>
> No. Just faster. Also smaller because better code.
>
>
>
> 2) eliminate request, response, session, T, cache objects and have a single
>
> "current" object. It should not be a thread local to avoid locking issues,
>
> but it should be passed around.
>
>
> nice but "current" wording can be misleading, why not a more explicit
> request and response?
> (like now…)
>
>
> There will be a compatibility layer so you can still use it as now.
> I just think there should be a single thread local. Anther issue is to
> minimize the number of objects being created for speed.
It should be faster if we use python dicts directly (or namedtuples)
This could speed up a micro-benchmark, but I doubt it would be helpful
in a real-world app.
I don't know if it would be possible without restarting the whole
>
> 3) eliminate all the exec/execfiles but preserve some version of the current
>
> multi-applications folder structures. Each app will have an entry point
>
> (main.py) where actions are registered to allow a freer structure at the app
>
> level.
>
>
> how will it manage "in-the-fly" modifications?
>
>
> Not sure hot to implement it. But it will work as today from user
> prospective.
server as django and others do when they detect a file modification.
Using decorators and removing exec will have a side-effect that apps
would have to be initialized, maintaining some state/settings in the
imported modules.
This will not be easy to follow and a minimal syntax error could down
the entire application or have secondary nasty effects (i.e. weird
import errors)
I doubt it will work like today from the user perpective, I think that
it would require a more standard python "command-line" approach
Yes, mostly because of python, but we could address the issues instead
> are you saying good by to the online IDE?
>
>
> Not at all but I think it should be simpler.
>
> that kind of dynamism is what makes web2py different and easy to learn/use
>
>
> I agree. We will keep it. But there are some hurdles.
of moving to a different approach.
Ok
>
> 4) A global routes to configure "only" application prefixes. Then each app
>
> is in charge of its own internal routing, perhaps using decorators as Flask
>
> does.
>
>
> this will be hard to explain to beginners and can cause a mess in the
> app structure
>
> a standard directory layout about where to put each file (MVC) is a
> good approach now
>
> yes, it is rigid, but it works for the majority of webapps made with web2py
>
>
> This is what I have in mind:
>
> apps/
> myapp/
> main.py # entry point for some app all they need
> templates/
> static/
> databases/
> uploads/
> languages/
> plugins/
> modules/
>
> Legacy apps will also have
>
> controllers/
> views/
>
> This is negotiable.
>
plugins will have a statics folder too?
The main.py approach is similar to what I've been thinking ;-)
You could use almost the same code as today just
- encapsulating the models in a def
- passing around request, response, and so on (or using current)
For example, in main.py:
from controllers.default import index
def main(request, response, session, ...):
return response.render(index(request, response))
in models/db.py
def get_db(request, response, session):
db = DAL(...)
db.define_table("my_table", Field("my_field"))
return db
in controllers/default.py
def index(request, response, session):
from models.db import ANY_OTHER_CONSTANT, my_function, get_db
db = get_db(request, response, session)
return dict(...)
I think this will be a minor cosmetic change compared with the web3py approach.
In fact, most of the changes in models and in controllers (like adding
defs or adding parameters to functions) can be automatically
implemented (like a 2to3 tool)
The other advantage is that we could implement an alternative way if
no main.py is present (the current exec behaviour)
That is, the "compatibilty layer" would be very simple and
straightforward to create (even without the 2to3-like tool, I think)
So, this approach would be useful for advanced user that need
performance, and it will simple enough for begginers
It will be cleaner and pythonic ;-)
we could generate them on demand and importing them as usual
> 5) No more global environment. Apps will do "from web3py import *" (see
>
> below)
>
>
> for the permormance perspective, this is equal or worse than the
> current approach
>
> also, import * should be discouraged as it chokes IDE and static checkers
>
> a shorter namespace would be useful, like
>
> import w3p
>
> db = w3p.DAL(....)
>
> or better:
>
> from web2py import dal
>
> db = dal.DAL(
> dal.Field('foo', dal.STRING,
> requires=dal.IS_IN_SET([])
> )
>
> (btw, I think this is currently achievable nowadays)
>
>
> I agree. It was just an example.
>
>
> 6) No more file-system write unless to install/edit apps. We store session
>
> in cookies (if small) or db (if large) and tickets always in db (so they can
>
> be searched and cleared more easily). They will not go in the app db but in
>
> a dedicated common ticket db.
>
>
> nice, but a better fine-grained ticket system should be necessary to
> further enhance performance and avoid some pitfalls in production
> (a bunch of tickets without enough detail was not very useful in my
> experience)
>
> in development, a more interactive inspection would be better than
> storing the error snapshot, like paste.evalexception.middleware
>
> http://tools.cherrypy.org/wiki/PasteEvalException
>
> 7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamed
>
> them tag, cat, safe, beautify, menu (with simpler logic)
>
>
> why not a namespace?
>
> from web2py import tag
>
> tag.DIV
>
> or better:
>
> from web2py.tag import A, IMG, ...
>
> IMHO helpers are part of web2py differentiation for easiness, why
> remove or complicate them?
>
>
> Because we do not need them. tag would generate them on demand.
they cause a bit of namespace pollution but it has been nice to work
with tags directly, without too much explanation or OO knowledge
also, creating them on deman will choke with IDE and static checkers,
and I no see a huge improvement in performance
Creating a class on the fly is not faster than just import it
(maybe I'm missing the new implementation...)
but it will not be web2py :-)
> 8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They will
>
> have a simpler logic that separates the HTML representation from the input
>
> processing, thus it will be faster and will be able to handle non-html form
>
> submission (ajax, xml) while using a syntax similar to the current one.
>
>
> good
> again, namespaces maybe useful here
> why this cannot be backported to web2py?
>
> 9) No more appadmin. There should be a global application to manage the
>
> databases of all the apps.
>
>
> good
>
> 10) should work with python 2.7 and 3.x
>
>
> bad, wasn't web3py py3k only?
> having two active versions could create confusion in users, be a
> maintenance nightmare and will not enable to take some advantages from
> python 3 new features
> or are you planing to discontinue web2py?
>
>
> I am planning to freeze web2py. web3py should have one version that works on
> both 2.7 and 3.x. On 2.7 will run also the compatibility layer.
>
>
> 11) A compatibility layer that will allow to run most existing web2py
>
> applications when using python 2.7.
>
>
> ah, ok, you are planning to discontinue web2py...
>
> IMHO they should be two different projects to avoid any misunderstanding
>
> 12) no more cache.disk but better cache.ram (renamed as cache) with actual
>
> expiration (current cache.ram only expires when accessed).
>
>
> cache.disk is useful in some places, surely I'm missing why this is evil
>
>
> I agree. We can have is an option along with memcache and redis. I would
> just not make it primary citizen as cache.ram.
>
>
> 13) automatic reverse routing
>
> 14) keep only dal.py and template.py from existing web2py.
>
>
> why not separate them as proper packages?
>
>
> That is a distribution issue. We can distribute them separately as well as
> combined. I still want the binary versions.
>
> what about gluino?
>
>
> Nobody uses it. Has no reason to exist. web3py should be usable as gluino.
>
>
> I have most of this done and the code is smaller and cleaner than current
>
> web2py is. If is 20x faster on hello world. The compatibility layer is
>
> imperfect as I am still working on BEAUTIFY, MENU, sessions, db
>
> transactions, and a many nasty details. Tools.py (auth) is missing.
>
>
> Here is an example of code I got working:
>
>
> <begin file apps/welcome/main.py>
>
> import time
>
> from web3py import DAL, Field, expose, Form, DALForm, IS_NOT_EMPTY, HTTP,
>
> tag
>
>
> db = DAL('sqlite://storage.test')
>
> db.define_table('person',Field('name',requires=IS_NOT_EMPTY()))
>
>
> @expose() # /appname/index
>
>
> decorators, although not an easy thing to explain to beginners, may be
> a good idea, but sometimes they are hard to understan/follow
> if this simple case should be explained, it may be not so good
> explicit is better than implicit ;-)
> maybe they could have more info about URL, or are they limited to
> function names?
>
> def index(current):
>
> form = Form(Field('name',requires=IS_NOT_EMPTY())).process(current)
>
> if form.submitted and form.processed and form.accepted: print form.vars
>
> elif form.submitted: print form.errors
>
> message = form.vars.name or ''
>
> return locals()
>
>
> @expose('/test_args/<str:a>(/<int:b>)?') # /appname/test_args/hello/1
>
> def test_args(current,a,b=9): # args are parsed, validated and passed to
>
> action
>
>
> arggh, regex or whatever it looks like... :(
>
> why not use python 3 annotations?
>
> def test_args(current,a: str, b: int=9):
>
> http://www.python.org/dev/peps/pep-3107/
>
>
> I had not thought about it. It would rule out 2.7. I am not sure we can
> handle it.
>
>
> return repr(dict(a=a,b=b))
>
>
> @expose(template='index.html')
>
> def test_form(current):
>
> form = DALForm(db.person, record_id = None).process(current)
>
> message = tag.div(tag.h1(form.vars.name))
>
>
> div is a function, method or a class here?
>
> it should be Div() ?
> why not DIV ?
>
>
> tag.ANYTHING is <ANYTHING….>. tag is the same as web2py TAG.
> You can make tag.Div, tag.DIV, tag.diV, etc.
>
> anyway, we'll suffer from explicit boilerplate code :-)
>
> return locals()
>
>
> @expose(cache_expire=10)
>
> def timer(current):
>
> return time.ctime()
>
>
> @expose()
>
> def try_redirect(current):
>
> HTTP.redirect(current.url('index')) # does reverse routing
>
> <end>
>
>
>
> As you can see the syntax is similar for an easier transition. To benefit
>
> from speed apps will have to be rewritten.
>
>
> Legacy web2py welcome app, without tools and session also works. I will add
>
> tools and session support asap.
>
>
> The error tickets also need work but I just discovered inspect.stack and had
>
> an epiphany!
>
>
> Am I on the right track?
>
>
> maybe from the pythonic standpoint, but who will care?
> we'll become a common framework like everyone else
> why will anyone use web3py instead flask+sqlachemy, django or whatever?
>
>
> I think it will still look a lot like web2py but faster.
Surely, in fact I do not use nor teach many of the new improvements.
>
> Want to help?
>
>
> no, as I say in earlier mails, I don't see the point here, so sorry
>
> Comments suggestions?
>
>
> IMHO stick with web2py, split it in standalones modules and add
> alternative implementations with current structure, so it can be
> comparable in minimal benchmarks :-)
>
> What can we do better?
>
>
> enhance web2py to a better 3.0 version
>
>
> You vision is not much different than mine. I want to simply the source
> code. It is messy.
> Moreover there are so many caveats that it is getting hard to teach.
> I also learned many new Python APIs that web2py is not taking advantage of.
Maybe if we list all the known issues and workaronund it is easier to
get convinced about such big change.
I don't know, internally there will be many changes (mostly because
> In my view the final product should be 95% compatible with current web2py.
> We have to break backward compatibility anyway to go to python 3.x.
unicode), but for the end user most code could be run with minimal
changes
I don't see any new py3k killer feature that worth to justify this
(beside annotations, that are not available in py2)
Python 3 has no reload because it is evil :-)
> When should apps be reloaded (since they are no longer executed we must
> trigger reload)?
>
>
> you can't, you'll have to restart the whole server
>
>
> reload is one of the missing pieces in py3k
>
>
> Are you saying python 3 has no reload?
> http://docs.python.org/dev/py3k/library/imp.html?highlight=reload#imp.reload
>
However, it has been moved to the imp library, and could be emulated
with some python internals (with some care because it has more nasty
secondary effects than exec...)
In fact, AFAIK the import machinery will be / is a pure python
implementation in py3.3 (importlib), you can talk with Brett Cannon in
PyCon Argentina about that ;-)
Me too
> What would you like to see changed?
>
>
> not much, I'm quite happy with web2py
> I think we should have more complex app to do a deeper analysis
>
> I've learned a lot of things this year with web2conf for PyCon
> Argentina 2012 conference, it is "advanced" as Pinax Symposion (and
> even it may have more features), and still it is simple (in the web2py
> sense), easy to understand and it could be optimized to reach
> acceptable performance without compromising dynamism.
>
>
>
> Should we preserve validators as they are?
>
>
> we should preserve as most as possible to not break backward compatibility
>
>
> Should we have a built-in realtime event handling for websockets in every
>
> app? What do we do with the LOAD helper? what do we do with web2py.js? Do we
>
> still need response.files of should we make more use of template {{block…}}
>
> to inject stuff in <head/>? Should we backport some of new stuff (Form,
>
> cache, helpers) to web2py?
>
>
> yes to them all (excepting the complex {{block}} thing and the
> realtime event handling)
>
> If we take this route, we need to have a permanent feature freeze on web2py,
>
> except on DAL and Template which are the only shared modules.
>
>
> this is the part I dislike
> I think we can keep improving web2py and make alternatives or further
> works possible
>
>
> I am not saying "the only shared APIs". In the compatibility mode, the APIs
> will be the same and it will use exec as it does not. The actual modules
> will be rewritten and organized better.
>
>
> I will share my code next week, as soon as I get sessions to work.
>
> You will appreciate the clarity compare with the current web2py. In
>
> particular the helpers and form handling logic.
>
>
> IMHO that we should clean up the code is not a reason to start a
> massive rewrite from scratch.
> I argued in previous discussions that this seems like the second
> system effect (and according the literature, it has not been good for
> any project...):
>
> http://en.wikipedia.org/wiki/Second-system_effect
>
>
> Excellent point.
>
> This is a nice article explaining why:
>
> http://www.joelonsoftware.com/articles/fog0000000069.html
>
> For example, DAL has more important problems like the id/keyed table
> and could be optimized in the id/sequence/autonumeric handling, bool
> logic, left joins, etc.
> Fixed that it should be taken more seriously to be used in standalone,
> gui and other web applications/frameworks.
> They are in my TODO list, or wish list as this year I didn't have enough
> time :(
>
> About the odd benchmark, please read the discussion in django-dev about
> this.
>
> For me, just because web2py isn't faster that ever
> minimicrosmallpythonframework out in the wild is not a an enough
> excuse for a big re-design.
> That's why I think gluino idea was amazing, if we could take the best
> of both worlds (full-stack and micro-framework), why not?
>
>
> Sorry for my lack of optimism
>
>
> I understand the skepticism. I am glad we will be able to talk more about
> this in person in two weeks.
BTW, for the web2py sprint, there are around 25 people registered!!!!!!
(right now, more than any other sprint in the conference)
http://ar.pycon.org/2012/schedule
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
+1 for name change
web2py is cool but i don't like web3py
Hello everybody,Time to start thinking about web3py. And as I think about it, I hear this in my mind: http://www.youtube.com/watch?v=HofoK_QQxGcHere is what I have in mind and I am building a prototype:1) eliminate every computation done when the request arrives (for example parsing of url, headers, accept_languages, etc) and make everything lazy.
2) eliminate request, response, session, T, cache objects and have a single "current" object. It should not be a thread local to avoid locking issues, but it should be passed around.
3) eliminate all the exec/execfiles but preserve some version of the current multi-applications folder structures. Each app will have an entry point (main.py) where actions are registered to allow a freer structure at the app level.
4) A global routes to configure "only" application prefixes. Then each app is in charge of its own internal routing, perhaps using decorators as Flask does.
5) No more global environment. Apps will do "from web3py import *" (see below)
6) No more file-system write unless to install/edit apps. We store session in cookies (if small) or db (if large) and tickets always in db (so they can be searched and cleared more easily). They will not go in the app db but in a dedicated common ticket db.
7) Remove all the helpers except TAG, CAT, XML, BEAUTIFY, MENU and renamed them tag, cat, safe, beautify, menu (with simpler logic)
8) Replace SQLFORM.factory with Form and SQLFORM with DALForm. They will have a simpler logic that separates the HTML representation from the input processing, thus it will be faster and will be able to handle non-html form submission (ajax, xml) while using a syntax similar to the current one.
9) No more appadmin. There should be a global application to manage the databases of all the apps.
10) should work with python 2.7 and 3.x
11) A compatibility layer that will allow to run most existing web2py applications when using python 2.7.
12) no more cache.disk but better cache.ram (renamed as cache) with actual expiration (current cache.ram only expires when accessed).
13) automatic reverse routing14) keep only dal.py and template.py from existing web2py.
I have most of this done and the code is smaller and cleaner than current web2py is. If is 20x faster on hello world. The compatibility layer is imperfect as I am still working on BEAUTIFY, MENU, sessions, db transactions, and a many nasty details. Tools.py (auth) is missing.Here is an example of code I got working:
<begin file apps/welcome/main.py>import timefrom web3py import DAL, Field, expose, Form, DALForm, IS_NOT_EMPTY, HTTP, tagdb = DAL('sqlite://storage.test')db.define_table('person',Field('name',requires=IS_NOT_EMPTY()))@expose() # /appname/index
def index(current):form = Form(Field('name',requires=IS_NOT_EMPTY())).process(current)if form.submitted and form.processed and form.accepted: print form.varselif form.submitted: print form.errorsmessage = form.vars.name or ''return locals()@expose('/test_args/<str:a>(/<int:b>)?') # /appname/test_args/hello/1def test_args(current,a,b=9): # args are parsed, validated and passed to action
return repr(dict(a=a,b=b))@expose(template='index.html')def test_form(current):form = DALForm(db.person, record_id = None).process(current)message = tag.div(tag.h1(form.vars.name))
return locals()@expose(cache_expire=10)def timer(current):return time.ctime()@expose()def try_redirect(current):HTTP.redirect(current.url('index')) # does reverse routing<end>
As you can see the syntax is similar for an easier transition. To benefit from speed apps will have to be rewritten.Legacy web2py welcome app, without tools and session also works. I will add tools and session support asap.The error tickets also need work but I just discovered inspect.stack and had an epiphany!Am I on the right track?
Want to help? Comments suggestions? What can we do better? When should apps be reloaded (since they are no longer executed we must trigger reload)? What would you like to see changed? Should we preserve validators as they are? Should we have a built-in realtime event handling for websockets in every app? What do we do with the LOAD helper? what do we do with web2py.js? Do we still need response.files of should we make more use of template {{block…}} to inject stuff in <head/>? Should we backport some of new stuff (Form, cache, helpers) to web2py?
If we take this route, we need to have a permanent feature freeze on web2py, except on DAL and Template which are the only shared modules.
I will share my code next week, as soon as I get sessions to work.You will appreciate the clarity compare with the current web2py. In particular the helpers and form handling logic.
Massimo
Two questions in regards to web3py/web2py subject in general:
- what will happen with experimental features in web2py? Having web2py in feature freeze seems logical, but what are the plans for existing experimental features and their documentation?
- web3py will require python 3.3 and 2.7 as a minimum, no 2.6 support..? I'm not saying I'm for or against this, just want to confirm I'm understanding correctly…
Regards,
Ales
On Tuesday, October 30, 2012 4:51:06 AM UTC+1, Jonathan Lundell wrote:On 29 Oct 2012, at 7:40 PM, Massimo DiPierro <massimo....@gmail.com> wrote:
>
> Isn't session also part of the request. Isn't current what we mean by request?
Logically, the lifetime of a session extends across multiple requests, while the lifetime of a response corresponds exactly to a request.
And yes, my first choice of a name for 'current' was 'request', but it was already taken...
Updated from git but still having the problem, this is what I can see on console when accessing index action:INFO:Rocket.Requests:127.0.0.1 - "GET /favicon.ico HTTP/1.1" - 200 14welcome.main.indexERROR:root:Traceback (most recent call last):File "c:\java\web3py\web3py\wsgi.py", line 64, in error_handlerreturn static_handler(environ, start_response)File "c:\java\web3py\web3py\wsgi.py", line 50, in static_handlerdata = dynamic_handler(environ, start_response)File "c:\java\web3py\web3py\wsgi.py", line 25, in dynamic_handlerexpose.run_dispatcher()File "c:\java\web3py\web3py\expose.py", line 163, in run_dispatcheroutput = obj.func(**match.groupdict())File "c:\java\web3py\web3py\cleaners.py", line 20, in goutput = cleaner.wrap_call(f)(*a,**b)File "c:\java\web3py\web3py\cleaners.py", line 19, in gcleaner.on_start()File "c:\java\web3py\web3py\session.py", line 11, in on_startrequest_cookies = current.request_cookiesFile "c:\java\web3py\web3py\current.py", line 94, in request_cookiesself._request_cookies.load(self.environ.get('HTTP_COOKIE',''))File "c:\python27\lib\Cookie.py", line 632, in loadself.__ParseString(rawdata)File "c:\python27\lib\Cookie.py", line 665, in __ParseStringself.__set(K, rval, cval)File "c:\python27\lib\Cookie.py", line 585, in __setM.set(key, real_value, coded_value)File "c:\python27\lib\Cookie.py", line 460, in setraise CookieError("Illegal key value: %s" % key)CookieError: Illegal key value: ti:mid
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
class BaseController:
def __init__(self, fn=''):
## loads some vars
self.request = current.request
....
## load the function requested by url
self.__getattribute__(fn)()
class MyController(BaseController):
def index(self):
## some actions
def user(self):
## some other actions
--
-- mail from:GoogleGroups "web2py-developers" mailing list
make speech: web2py-d...@googlegroups.com
unsubscribe: web2py-develop...@googlegroups.com
details : http://groups.google.com/group/web2py-developers
the project: http://code.google.com/p/web2py/
official : http://www.web2py.com/
---
You received this message because you are subscribed to the Google Groups "web2py-developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to web2py-develop...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.