Re: Yet another comparison of Python Web Frameworks
Gluon was made at my school? I seriously gotta start talking to the CTI department. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
johnbraduk a écrit : > Thomas, > Like many others I have been going round the same loop for months. > > I have struggled with most of the Python solutions, including > TurboGears and have given up and gone back to ColdFusion. I am not > trying to kick of a religious war about the pros and cons of > ColdFusion as a scripting langauge, but IMHO, as a development > environment (Dreamweaver), it is unbeatable. Won't talk about opinion here. Enough to say that Dreamweaver is IMHO a bloated piece of crap. > In one product, "out of > the box" I can integrate database access and web design, Which are totally orthogonal aspects, and as such are better kept seperate. In my current shop - as well as in the previous one, programmers deal with database access, designers deal with design, and integrators deal with html and templates. > including > AJAX, in one GUI IDE. I don't want a "GUI IDE", I want my code editor. Using which I can edit (x)html, css, any template language, javascript, python, php, sql, whatever... > Ok, the IDE is on Windows, but the servers run > on Linux. No way I'm going to inflict myself the pain of using Windows. Sorry. > This seems to be an aspect of web design that has been totally > ignored in the Python community. (snip rant about having too much choice) > Am I asking too much to have a Python product "X" which is a fully > self-contained web development framework? Have you tried Django ? One of the main criticism against it is that it's a bit too much "self-contained" !-) But anyway, since all these are free softwares - freely written and contributed by mostly benelovent contributors -, yes, you *are* "asking" too much. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Thomas, Like many others I have been going round the same loop for months. I have struggled with most of the Python solutions, including TurboGears and have given up and gone back to ColdFusion. I am not trying to kick of a religious war about the pros and cons of ColdFusion as a scripting langauge, but IMHO, as a development environment (Dreamweaver), it is unbeatable. In one product, "out of the box" I can integrate database access and web design, including AJAX, in one GUI IDE. Ok, the IDE is on Windows, but the servers run on Linux. This seems to be an aspect of web design that has been totally ignored in the Python community. Developers have been falling over each other to come up with yet another web development framework ( about 15 at the last count!), but they are all a collection of bits and pieces from all over the place. Turbogears is attempting to pull it all together, but that is like trying to hit a moving target. As soon as you get something working they move to a different level of one of the components and it all falls apart. For example, you might try widgets and get them working with Kid Templates. Then you read that they want you to move to Genshi Templates and after wasting hours, you find the small print and discover you need different widgets to work with Genshi. Some may think it is a strength of Python to have so many options, but I think it is a weakness and putting people off using Python for Web development, driving them to products like PHP, Rails or ColdFusion. When I develop a web application, I don't want to have to decide whether to use mod-python, Cherrypy, Django, Pylons... for my server. Then I have to decide whether to access my database with basic SQL or learn the quirky options available with SQLObjects or SQLAlchemy, with or without, Elixir. Finally, I have to decide which of umpteen templating systems to use and hope that it will work with the rest of the components. Am I asking too much to have a Python product "X" which is a fully self-contained web development framework? John B On 6 Oct, 11:44, Thomas Wittek <[EMAIL PROTECTED]> wrote: > Michele Simionato: > > > At work we are shopping for a Web framework, so I have been looking at > > the available options > > on the current market. > > At least, you missed Turbo Gears :)http://turbogears.org/ > For me, it feels more integrated than Pylons. > > -- > Thomas Wittek > Web:http://gedankenkonstrukt.de/ > Jabber: [EMAIL PROTECTED] > GPG: 0xF534E231 -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
I have posted a new version of Gluon and some slides. I am hoping to have a draft manual soon. I believe I have fixed all of the issues that have been addressed but, if not, please let me know. Massimo Did you try gluon? http://mdp.cti.depaul.edu/examples On Oct 13, 2007, at 12:17 AM, Kay Schluehr wrote: > On Oct 13, 4:23 am, Massimo Di Pierro <[EMAIL PROTECTED]> > wrote: >> Hello everybody, >> >> I just joined this mailing list. Thanks for your comments about >> gluon. >> >> I have posted a short video about it and I am planning to make more >> over the week-end. >> >> http://www.youtube.com/watch?v=VBjja6N6IYk >> >> About some of your comments: >> - the most complex modules (like html and sql ones) have doctests. >> - the executable versions (win and mac) come with python2.5. Running >> from source code does not require 2.5 but you probably want sqlite3. >> - so far I support sqlite3 and postgresql, not mysql (just because I >> do not use it and had no time for testing it). >> - yes, there are typos in the documentation. Please point them out to >> me so that I can fix them. >> - I am sure there are some minor bugs I am not aware of but as far I >> tested, it work. >> - If you report bugs to me I promise to fix them in 48hrs. >> - please make sure you have the latest version. >> >> I very much appreciate comments about gluon (good and bad). Please >> send me more so that I can improve it. >> >> There will be two talks in chicago about gluon next week: at DePaul >> Linux Users Group on Thursday evening and at the Chicago Linux Users >> Group on Saturday afternoon. I will try record them and post them. >> >> Massimo > > Massimo, it's just a style matter but could you please unmix tabs and > blanks in Gluon? > > Since Gluon is pure Python I can try backtranslating the Python 2.5 > code to Python 2.4. This requires following tool of mine: > > http://www.fiber-space.de/EasyExtend/doc/Py25Lite/Py25Lite.html > > The Python 2.4 source code can then be used by people like Michele who > have 2.4 lecagies. Note that the conversion process is fully automated > ( it requires just a little conversion script targetting Gluon ) and > can be reiterated. The conversion however needs tests to be confirmed. > It would also be a nice little project for Py25Lite in the real-world. > > Kay > > > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Paste and WSGI 2.0 [WAS: Yet another comparison of Python Web Frameworks]
On Oct 14, 3:46 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > I think we do agree entirely, it is just that the application we have > in > mind is more a collection of web services than a traditional Web > application. > Now, since you are here, there is an unrelated question that I want to > ask you, concerning the future of Paste with respect to WSGI 2.0. > I do realize that at this stage WSGI 2.0, is only a draft, still I > would > like to know: > > 1. if you think that WSGI 2.0 is good idea (I expect you will say > "yes") Yeah. WebOb's functions have made me feel less of a need for that change, and it normalizes some of the parts of WSGI that WSGI 2 removes. But I think it would generally help. > 2. if you plan to support it in Paste and if yes when (I mean, in a > month, >in a year, in three years?) > 3. if you already have thought of a migration plan and, in that case, >what your strategy would likely be. This I'm really not sure about. A middleware could wrap any WSGI application to make it support both WSGI 1 and 2. However, on the server side it's unclear how to do the transition (including middleware that calls WSGI applications). If WSGI 2 included some marker that I could look for, then it would be relatively easy too -- I'd always just call applications with a library function that knew how to deal with both kinds of applications. Without that... well, maybe I'll just have to be sure that there's a clear upgrade path for the spec in general. Of course, as Graham says, WSGI 2 is just talk at this point; there's not a ton of momentum toward actually delivering a new spec. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Paste and WSGI 2.0 [WAS: Yet another comparison of Python Web Frameworks]
On Oct 14, 6:46 pm, Michele Simionato <[EMAIL PROTECTED]> wrote: > Now, since you are here, there is an unrelated question that I want to > ask you, concerning the future of Paste with respect to WSGI 2.0. > I do realize that at this stage WSGI 2.0, is only a draft Hmmm, not sure where people keep getting this idea that there exists a WSGI 2.0 draft. The only thing that exists that I know of is: http://www.wsgi.org/wsgi/WSGI_2.0 This is at this point merely a collection of ideas for change, or areas where the existing WSGI 1.0 is deficient. There are a various things around this where decisions would need to be made or solutions developed before one could even consider calling it a draft. I certainly wouldn't necessarily go off making decisions based on what may or may not be in WSGI 2.0. :-) Graham -- http://mail.python.org/mailman/listinfo/python-list
Paste and WSGI 2.0 [WAS: Yet another comparison of Python Web Frameworks]
On Oct 14, 2:52 am, Ian Bicking <[EMAIL PROTECTED]> wrote: > That said, going without a framework (which at least in his article is > what Michele seems to be comparing Pylons against) isn't always so > bad. I started writing an Atompub server in Pylons, but felt like I > was spending too much time navigating around what the framework setup > and not enough time just paying attention to what Atompub really is. > So I ended up writing it (as FlatAtomPub), effectively without a > framework (though developing it at the same time as WebOb, so I leaned > on that quite a bit). The development went quite well, and for a web > service like Atompub that's probably what I'd recommend (at least to > experienced developers -- you might find yourself left to drift > otherwise without a clear idea of where to start). > > But for writing a traditional web application, I'd still use Pylons. > The choices Pylons have made are with that in mind, and it doesn't at > all exclude other forms of development in the process. You could > actually drop a FlatAtomPub instance right into a Pylons app, for > instance. Pylons is a small enough framework that it really is quite > reasonable to pick and choose and use a very minimal style with it. I think we do agree entirely, it is just that the application we have in mind is more a collection of web services than a traditional Web application. Now, since you are here, there is an unrelated question that I want to ask you, concerning the future of Paste with respect to WSGI 2.0. I do realize that at this stage WSGI 2.0, is only a draft, still I would like to know: 1. if you think that WSGI 2.0 is good idea (I expect you will say "yes") 2. if you plan to support it in Paste and if yes when (I mean, in a month, in a year, in three years?) 3. if you already have thought of a migration plan and, in that case, what your strategy would likely be. Thanks for sharing, Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:13 am, Bruno Desthuilliers wrote: > Well... Last year, I had a look at Pylons, then played a bit with wsgi > and building my own framework over it. I finally dropped that code and > went back to Pylons, which I felt could become far better than my own > efforts. Now since then I had way too much to do at work (using other > technos) and didn't find the time to work on my own projects, so I still > don't know how well Pylons will pass the "real world" test, but it seems > to me that it's rapidly progressing and mostly in the right direction. I > still wait for an opportunity to check this out !-) This would be my general suggestion too. It's fine to write your own, and not that hard, but you'll be missing out on the momentum and help from the community. You'll be maintaining your own code instead of having other people work on maintenance -- which actually isn't that much more work, except that you'll be doing it alone and without that collective experience at hand. That said, going without a framework (which at least in his article is what Michele seems to be comparing Pylons against) isn't always so bad. I started writing an Atompub server in Pylons, but felt like I was spending too much time navigating around what the framework setup and not enough time just paying attention to what Atompub really is. So I ended up writing it (as FlatAtomPub), effectively without a framework (though developing it at the same time as WebOb, so I leaned on that quite a bit). The development went quite well, and for a web service like Atompub that's probably what I'd recommend (at least to experienced developers -- you might find yourself left to drift otherwise without a clear idea of where to start). But for writing a traditional web application, I'd still use Pylons. The choices Pylons have made are with that in mind, and it doesn't at all exclude other forms of development in the process. You could actually drop a FlatAtomPub instance right into a Pylons app, for instance. Pylons is a small enough framework that it really is quite reasonable to pick and choose and use a very minimal style with it. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 8:29 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > Do you (or something else) have something to say about Beaker? > I looked at the source code and it seems fine to me, but I have > not used it directly, not stressed it. I need a > production-level WSGI session middleware and I wonder what the > players are (for instance how Beaker does compare with flup?) Beaker is the only seriously maintained WSGI session at the moment -- flup isn't, AFAIK, very actively maintained or improved. paste.session is a particularly naive implementation of sessions. So as a result, Beaker is kind of the only game in town. Incidentally, it's not really related to SQLAlchemy; it came out of Myghty. Same author, of course, but fairly different domains. Ian -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
> ... I almost forgot ... > > another difference between Gluon and Django,TG is that in Gluon if > you write controllers without view you automatically get generic view > that render and BEAUTIFY() the variables returned by the controllers. > That means you can develop the logic of your application without > writing one line of HTML and you have a working prototype. > > Massimo > > > Hi Daniel, > > > > in many respects Gluon is similar to Django and was greatly inspired > > by Django. Some differences are: > > > > Gluon is easier to install - you never need to use the shell, there > > are no configuration files. > > > > Gluon is a web app. You can do all development via a web interface. > > > > You can compile Gluon apps and distribute them in byte-code compiled > > form. > > > > Each Gluon app comes with a ticketing system. If an error occurrs it > > is logged and a ticket is issed. you can then search and retrieve > > errors by date or client-ip. > > > > Making forms is easier than in Django. For example given a db table > > called db.table you can do: > >form=SQLForm(db.table) > >if form.accepts(request.vars,session): pass > > these two lines will do everything, including generating the form > > from the table, validating input, inserting in database or modifying > > the form with error messages. This also prevents multiple submission > > of the same form because each form has a unique one-time key. > > > > The template language is pure python but without indentation > > requirements. Django has restrictions on what can go in templates. > > > > The output in the views is escaped by default. In Django it is not. > > > > You can manage internationalization (add language and write > > translations) from the web interface. > > > > Each app has an automatically generated database administrative > > interface. The Django one is cooler then Gluon's, but the Gluon one > > allows complicated joins in the filter field. > > > > Gluon supports migrations: you just change the definition of a table > > and it ALTERs the table accordingly (drop works in postgres only). > > For example if you change a field from boolean to string, the > > database is altered and the values are converted from boolean to > > string for existing records. > > > > Gluon has a sql.log console to see what changes are made to the > > database. > > > > In Gluon you do not need to import modules. The gluon modules you > > need already imported for you. > > > > Gluon has a top-down design. This means that the Gluon APIs are not > > under development. They are 100% stable. There may be bugs and they > > will be fixed but the syntax and signature of functions is not > > subject to change. This is why I started making Gluon, I am teaching > > a class on web frameworks and the API of Django and TG are not as > > stable as I wish they were. Moreover they have a too steep learning > > curve when compared to Gluon. > > > > Please try it, it is no that time consuming, and send me you comments > > (good or bad)! > > > > Massimo > > > > > >>> Hello everybody, > >>> > >>> I just joined this mailing list. Thanks for your comments about > >>> gluon. > >>> > >>> I have posted a short video about it and I am planning to make more > >>> over the week-end. > >>> > >>> http://www.youtube.com/watch?v=VBjja6N6IYk > >>> > >>> About some of your comments: > >>> - the most complex modules (like html and sql ones) have doctests. > >>> - the executable versions (win and mac) come with python2.5. Running > >>> from source code does not require 2.5 but you probably want sqlite3. > >>> - so far I support sqlite3 and postgresql, not mysql (just because I > >>> do not use it and had no time for testing it). > >>> - yes, there are typos in the documentation. Please point them > >>> out to > >>> me so that I can fix them. > >>> - I am sure there are some minor bugs I am not aware of but as far I > >>> tested, it work. > >>> - If you report bugs to me I promise to fix them in 48hrs. > >>> - please make sure you have the latest version. > >>> > >>> I very much appreciate comments about gluon (good and bad). Please > >>> send me more so that I can improve it. > >>> > >>> There will be two talks in chicago about gluon next week: at DePaul > >>> Linux Users Group on Thursday evening and at the Chicago Linux Users > >>> Group on Saturday afternoon. I will try record them and post them. > >>> > >>> Massimo > >>> > >>> P.S. Michele Simionato. I have heard your name before? Is it > >>> possible > >>> we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist > >>> and there is not many of us. > >> > >> > >> Hi Massimo, > >> > >> In what way is gluon different from existing frameworks most notably > >> django and turbogears? What do you think are the advantages to using > >> gluon over these two? > >> > >> Cheers, > >> Daniel Massimo, thanks a lot for the reply, I'll give gluon a try. I've just started to use TG about 3 months ago and although I like it it would be f
Re: Yet another comparison of Python Web Frameworks
... I almost forgot ... another difference between Gluon and Django,TG is that in Gluon if you write controllers without view you automatically get generic view that render and BEAUTIFY() the variables returned by the controllers. That means you can develop the logic of your application without writing one line of HTML and you have a working prototype. Massimo On Oct 13, 2007, at 10:44 AM, DiPierro, Massimo wrote: > Hi Daniel, > > in many respects Gluon is similar to Django and was greatly inspired > by Django. Some differences are: > > Gluon is easier to install - you never need to use the shell, there > are no configuration files. > > Gluon is a web app. You can do all development via a web interface. > > You can compile Gluon apps and distribute them in byte-code compiled > form. > > Each Gluon app comes with a ticketing system. If an error occurrs it > is logged and a ticket is issed. you can then search and retrieve > errors by date or client-ip. > > Making forms is easier than in Django. For example given a db table > called db.table you can do: >form=SQLForm(db.table) >if form.accepts(request.vars,session): pass > these two lines will do everything, including generating the form > from the table, validating input, inserting in database or modifying > the form with error messages. This also prevents multiple submission > of the same form because each form has a unique one-time key. > > The template language is pure python but without indentation > requirements. Django has restrictions on what can go in templates. > > The output in the views is escaped by default. In Django it is not. > > You can manage internationalization (add language and write > translations) from the web interface. > > Each app has an automatically generated database administrative > interface. The Django one is cooler then Gluon's, but the Gluon one > allows complicated joins in the filter field. > > Gluon supports migrations: you just change the definition of a table > and it ALTERs the table accordingly (drop works in postgres only). > For example if you change a field from boolean to string, the > database is altered and the values are converted from boolean to > string for existing records. > > Gluon has a sql.log console to see what changes are made to the > database. > > In Gluon you do not need to import modules. The gluon modules you > need already imported for you. > > Gluon has a top-down design. This means that the Gluon APIs are not > under development. They are 100% stable. There may be bugs and they > will be fixed but the syntax and signature of functions is not > subject to change. This is why I started making Gluon, I am teaching > a class on web frameworks and the API of Django and TG are not as > stable as I wish they were. Moreover they have a too steep learning > curve when compared to Gluon. > > Please try it, it is no that time consuming, and send me you comments > (good or bad)! > > Massimo > > > On Oct 13, 2007, at 5:01 AM, Daniel Fetchinson wrote: > >>> Hello everybody, >>> >>> I just joined this mailing list. Thanks for your comments about >>> gluon. >>> >>> I have posted a short video about it and I am planning to make more >>> over the week-end. >>> >>> http://www.youtube.com/watch?v=VBjja6N6IYk >>> >>> About some of your comments: >>> - the most complex modules (like html and sql ones) have doctests. >>> - the executable versions (win and mac) come with python2.5. Running >>> from source code does not require 2.5 but you probably want sqlite3. >>> - so far I support sqlite3 and postgresql, not mysql (just because I >>> do not use it and had no time for testing it). >>> - yes, there are typos in the documentation. Please point them >>> out to >>> me so that I can fix them. >>> - I am sure there are some minor bugs I am not aware of but as far I >>> tested, it work. >>> - If you report bugs to me I promise to fix them in 48hrs. >>> - please make sure you have the latest version. >>> >>> I very much appreciate comments about gluon (good and bad). Please >>> send me more so that I can improve it. >>> >>> There will be two talks in chicago about gluon next week: at DePaul >>> Linux Users Group on Thursday evening and at the Chicago Linux Users >>> Group on Saturday afternoon. I will try record them and post them. >>> >>> Massimo >>> >>> P.S. Michele Simionato. I have heard your name before? Is it >>> possible >>> we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist >>> and there is not many of us. >> >> >> Hi Massimo, >> >> In what way is gluon different from existing frameworks most notably >> django and turbogears? What do you think are the advantages to using >> gluon over these two? >> >> Cheers, >> Daniel >> -- >> http://mail.python.org/mailman/listinfo/python-list > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Hi Daniel, in many respects Gluon is similar to Django and was greatly inspired by Django. Some differences are: Gluon is easier to install - you never need to use the shell, there are no configuration files. Gluon is a web app. You can do all development via a web interface. You can compile Gluon apps and distribute them in byte-code compiled form. Each Gluon app comes with a ticketing system. If an error occurrs it is logged and a ticket is issed. you can then search and retrieve errors by date or client-ip. Making forms is easier than in Django. For example given a db table called db.table you can do: form=SQLForm(db.table) if form.accepts(request.vars,session): pass these two lines will do everything, including generating the form from the table, validating input, inserting in database or modifying the form with error messages. This also prevents multiple submission of the same form because each form has a unique one-time key. The template language is pure python but without indentation requirements. Django has restrictions on what can go in templates. The output in the views is escaped by default. In Django it is not. You can manage internationalization (add language and write translations) from the web interface. Each app has an automatically generated database administrative interface. The Django one is cooler then Gluon's, but the Gluon one allows complicated joins in the filter field. Gluon supports migrations: you just change the definition of a table and it ALTERs the table accordingly (drop works in postgres only). For example if you change a field from boolean to string, the database is altered and the values are converted from boolean to string for existing records. Gluon has a sql.log console to see what changes are made to the database. In Gluon you do not need to import modules. The gluon modules you need already imported for you. Gluon has a top-down design. This means that the Gluon APIs are not under development. They are 100% stable. There may be bugs and they will be fixed but the syntax and signature of functions is not subject to change. This is why I started making Gluon, I am teaching a class on web frameworks and the API of Django and TG are not as stable as I wish they were. Moreover they have a too steep learning curve when compared to Gluon. Please try it, it is no that time consuming, and send me you comments (good or bad)! Massimo On Oct 13, 2007, at 5:01 AM, Daniel Fetchinson wrote: >> Hello everybody, >> >> I just joined this mailing list. Thanks for your comments about >> gluon. >> >> I have posted a short video about it and I am planning to make more >> over the week-end. >> >> http://www.youtube.com/watch?v=VBjja6N6IYk >> >> About some of your comments: >> - the most complex modules (like html and sql ones) have doctests. >> - the executable versions (win and mac) come with python2.5. Running >> from source code does not require 2.5 but you probably want sqlite3. >> - so far I support sqlite3 and postgresql, not mysql (just because I >> do not use it and had no time for testing it). >> - yes, there are typos in the documentation. Please point them out to >> me so that I can fix them. >> - I am sure there are some minor bugs I am not aware of but as far I >> tested, it work. >> - If you report bugs to me I promise to fix them in 48hrs. >> - please make sure you have the latest version. >> >> I very much appreciate comments about gluon (good and bad). Please >> send me more so that I can improve it. >> >> There will be two talks in chicago about gluon next week: at DePaul >> Linux Users Group on Thursday evening and at the Chicago Linux Users >> Group on Saturday afternoon. I will try record them and post them. >> >> Massimo >> >> P.S. Michele Simionato. I have heard your name before? Is it possible >> we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist >> and there is not many of us. > > > Hi Massimo, > > In what way is gluon different from existing frameworks most notably > django and turbogears? What do you think are the advantages to using > gluon over these two? > > Cheers, > Daniel > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
> Hello everybody, > > I just joined this mailing list. Thanks for your comments about gluon. > > I have posted a short video about it and I am planning to make more > over the week-end. > > http://www.youtube.com/watch?v=VBjja6N6IYk > > About some of your comments: > - the most complex modules (like html and sql ones) have doctests. > - the executable versions (win and mac) come with python2.5. Running > from source code does not require 2.5 but you probably want sqlite3. > - so far I support sqlite3 and postgresql, not mysql (just because I > do not use it and had no time for testing it). > - yes, there are typos in the documentation. Please point them out to > me so that I can fix them. > - I am sure there are some minor bugs I am not aware of but as far I > tested, it work. > - If you report bugs to me I promise to fix them in 48hrs. > - please make sure you have the latest version. > > I very much appreciate comments about gluon (good and bad). Please > send me more so that I can improve it. > > There will be two talks in chicago about gluon next week: at DePaul > Linux Users Group on Thursday evening and at the Chicago Linux Users > Group on Saturday afternoon. I will try record them and post them. > > Massimo > > P.S. Michele Simionato. I have heard your name before? Is it possible > we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist > and there is not many of us. Hi Massimo, In what way is gluon different from existing frameworks most notably django and turbogears? What do you think are the advantages to using gluon over these two? Cheers, Daniel -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 13, 4:23 am, Massimo Di Pierro <[EMAIL PROTECTED]> wrote: > Hello everybody, > > I just joined this mailing list. Thanks for your comments about gluon. > > I have posted a short video about it and I am planning to make more > over the week-end. > > http://www.youtube.com/watch?v=VBjja6N6IYk > > About some of your comments: > - the most complex modules (like html and sql ones) have doctests. > - the executable versions (win and mac) come with python2.5. Running > from source code does not require 2.5 but you probably want sqlite3. > - so far I support sqlite3 and postgresql, not mysql (just because I > do not use it and had no time for testing it). > - yes, there are typos in the documentation. Please point them out to > me so that I can fix them. > - I am sure there are some minor bugs I am not aware of but as far I > tested, it work. > - If you report bugs to me I promise to fix them in 48hrs. > - please make sure you have the latest version. > > I very much appreciate comments about gluon (good and bad). Please > send me more so that I can improve it. > > There will be two talks in chicago about gluon next week: at DePaul > Linux Users Group on Thursday evening and at the Chicago Linux Users > Group on Saturday afternoon. I will try record them and post them. > > Massimo Massimo, it's just a style matter but could you please unmix tabs and blanks in Gluon? Since Gluon is pure Python I can try backtranslating the Python 2.5 code to Python 2.4. This requires following tool of mine: http://www.fiber-space.de/EasyExtend/doc/Py25Lite/Py25Lite.html The Python 2.4 source code can then be used by people like Michele who have 2.4 lecagies. Note that the conversion process is fully automated ( it requires just a little conversion script targetting Gluon ) and can be reiterated. The conversion however needs tests to be confirmed. It would also be a nice little project for Py25Lite in the real-world. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 12, 10:23 pm, Massimo Di Pierro <[EMAIL PROTECTED]> wrote: > > P.S. Michele Simionato. I have heard your name before? Is it possible > we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist > and there is not many of us. That is definitely possible, even if I don't remember your name right know. But let us keep this off list ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Massimo Di Pierro wrote: > happy to hear that. > you may want take a loot at http://mdp.cti.depaul.edu/vqcd > It is mostly python stuff and will post the code soon. Ah, memories :) I'm not working on QCD anymore, but I did write a bunch of code a while back to script Mayavi (the old one, not the new Mayavi2) to auto-generate webpages slicing through topological charge configurations, looking for instanton molecules. Your images are a bit small for me to tell what toolkit you're using (Mayavi is VTK based), but if you want, I'd be happy to send you that old code. It probably won't do anything you don't already have, but it was handy. It would slice in any direction (typically t) and generate one PNG per value, with the remaining 3 variables displayed, and isosurfaces computed at 1/4 and 3/4s of the total distribution of values, to conveniently see the instanton/anti-instanton pairs. By spitting out one webpage per field configuration, I could let it run overnight and then the next day quickly have an overview of all the configurations I had (or show them to my advisor). The code was written to read the MILC v5 binary lattice formats, which is what I was using. Just drop me a line if you happen to want any of that code. Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
happy to hear that. you may want take a loot at http://mdp.cti.depaul.edu/vqcd It is mostly python stuff and will post the code soon. Massimo On Oct 12, 2007, at 10:47 PM, Fernando Perez wrote: > Massimo Di Pierro wrote: > >> P.S. Michele Simionato. I have heard your name before? Is it possible >> we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist >> and there is not many of us. > > More than you think, it seems. Some of us were even using python > to process > Lattice QCD computations years ago ;-) > > Cheers, > > f > > -- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Massimo Di Pierro wrote: > P.S. Michele Simionato. I have heard your name before? Is it possible > we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist > and there is not many of us. More than you think, it seems. Some of us were even using python to process Lattice QCD computations years ago ;-) Cheers, f -- http://mail.python.org/mailman/listinfo/python-list
Yet another comparison of Python Web Frameworks
Hello everybody, I just joined this mailing list. Thanks for your comments about gluon. I have posted a short video about it and I am planning to make more over the week-end. http://www.youtube.com/watch?v=VBjja6N6IYk About some of your comments: - the most complex modules (like html and sql ones) have doctests. - the executable versions (win and mac) come with python2.5. Running from source code does not require 2.5 but you probably want sqlite3. - so far I support sqlite3 and postgresql, not mysql (just because I do not use it and had no time for testing it). - yes, there are typos in the documentation. Please point them out to me so that I can fix them. - I am sure there are some minor bugs I am not aware of but as far I tested, it work. - If you report bugs to me I promise to fix them in 48hrs. - please make sure you have the latest version. I very much appreciate comments about gluon (good and bad). Please send me more so that I can improve it. There will be two talks in chicago about gluon next week: at DePaul Linux Users Group on Thursday evening and at the Chicago Linux Users Group on Saturday afternoon. I will try record them and post them. Massimo P.S. Michele Simionato. I have heard your name before? Is it possible we have met in Pisa in 1990-1996? I am also a Quantum Field Theorist and there is not many of us. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 10, 8:15 pm, Peter Otten <[EMAIL PROTECTED]> wrote: > Kay Schluehr wrote: > >>http://mdp.cti.depaul.edu/examples > > > The delivered sourcecode is syntactically broken. Tabs and whitespaces > > were mixed and when I open a file like gluon/global.py I find sections > > like this: > > > class Request(Storage): > > """ > > defines the request object and the default values of its members > > """ > > def __init__(self): > > self.env=Storage() # this line is incorrect syntax in Python > > You may have configured your editor to use a tabwidth of four spaces > (Python always uses 8). > > Peter You are right! I looked at the tokenizer.py module and the default value for tabsize is 8. Now I feel stupid since I believe everyone knew this for at least a decade and it is somewhere between page 1 and 10 of the Python tutorial I didn't look at for 5 years or so. Now I get the following class definition: class Request(Storage): def __init__(self): self.env=Storage() self.cookies=Storage() self.get_vars=Storage() self.post_vars=Storage() self.vars=Storage() self.application=None self.function=None self.args=[] pass This is syntactically correct but the "pass" at the end makes me worry about understanding even less about yet unknown language conventions ( setting pass as an endmarker of a block ) or the programmers intentions or both. It's very scary in either way and I might need a few days of recovering. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Kay Schluehr wrote: >> http://mdp.cti.depaul.edu/examples > > The delivered sourcecode is syntactically broken. Tabs and whitespaces > were mixed and when I open a file like gluon/global.py I find sections > like this: > > class Request(Storage): > """ > defines the request object and the default values of its members > """ > def __init__(self): > self.env=Storage() # this line is incorrect syntax in Python You may have configured your editor to use a tabwidth of four spaces (Python always uses 8). Peter -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 10, 5:57 am, [EMAIL PROTECTED] wrote: > Since you are starting a new project you may want to look into > something new and different > > http://mdp.cti.depaul.edu/examples The delivered sourcecode is syntactically broken. Tabs and whitespaces were mixed and when I open a file like gluon/global.py I find sections like this: class Request(Storage): """ defines the request object and the default values of its members """ def __init__(self): self.env=Storage() # this line is incorrect syntax in Python self.cookies=Storage() self.get_vars=Storage() Moreover there aren't any indications that the code was tested. Kay -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 10, 5:57 am, [EMAIL PROTECTED] wrote: > Since you are starting a new project you may want to look into > something new and different > > http://mdp.cti.depaul.edu/examples Requiring Python 2.5 may not be a good idea for the time being. For instance, I am forced to use Python 2.4 because of some C libraries I need, so I cannot even consider a framework based on Python 2.5 for the moment :-( Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 9, 11:57 pm, [EMAIL PROTECTED] wrote: > Since you are starting a new project you may want to look into > something new and different > > http://mdp.cti.depaul.edu/examples This is actually a neat framework! I'm a somewhat of fan of web- frameworks and I used most major ones and I like to poke around. Here is a mini review: Gluon seems to be modeled with the web.py mentality, everything in one package, very simple but covering all essentials templating, database, sessions and server. It reminds me of a content management system, you start with a working server, then you add your components to it. It also implements a Zope-like through-the-web interaction, everything can be modified in the administration interface, templates, databases, code, media. This sort of functionality is sometimes frowned upon but can be a very convenient way to make small changes. Honestly the framework field is a bit crowded so it is an uphill battle to get a framework accepted, but it is nice to see something different. i. ps. fix the typos in the docs and get people's names right, it makes a bad impression otherwise -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Michele, > At work we are shopping for a Web framework, so I have been looking at > the available options on the current market. just because you were involved in creating an own version of Python does NOT free you from the social obligation to create your own Python web framework. So stop shopping and start announcing your own pwf like all other Python programmers do. Harald -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 10, 5:57 am, [EMAIL PROTECTED] wrote: > Since you are starting a new project you may want to look into > something new and different > > http://mdp.cti.depaul.edu/examples Well, the name is certainly appealing to an old gauge field theorist like myself ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Since you are starting a new project you may want to look into something new and different http://mdp.cti.depaul.edu/examples -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Michele Simionato wrote: > I wait with > impatience the time when Web programming will become a solved > problem with a standard built-in solution that works. That will probably come from Microsoft. At least for all-Microsoft environments. They're the only player who controls enough of the pieces. John Nagle -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 7, 6:14 pm, Istvan Albert <[EMAIL PROTECTED]> wrote: > On Oct 7, 12:24 pm, Michele Simionato <[EMAIL PROTECTED]> > wrote: > > > Here we disagree: I think that a programmer should know what he > > is using. > > My point was that they should not *need* to know. Too much information > can be detrimental. Actually, in principle I *do* agree with you. For instance, when I type 1+1, I have no idea of what exactly Python is doing, but I don't need to know, because adding two integers is a problem which is well understood and has been solved by others years ago, I don't need to care about it. I wait with impatience the time when Web programming will become a solved problem with a standard built-in solution that works. Unfortunately, that time is not near in the future and for the moment I am forced to know how all the pieces work if I want to build a reliable application. I don't like it, since I am not particularly interested in the low levels and in the plumbings myself, but this is the way it is. > ... truth to > be told I was just curious of how they would go about integrating a > database and still keep it "pluggable". > > Because it would either need to know about the way the server handles > the database connections (which makes it application specific) or it > has to create new database connections in which case it would be > duplicating the functionality leading to all kinds of headaches. > > So there, even a simple requirement exposes the fallacy of building > anything complex out of "pluggable" components. I suppose Beaker rely on SQLAlchemy since it comes from the same mind, but I don't see the issue: a component may well depend from another one, partially or totally, but this does not detract at all from the usefulness of the component approach. If I don't need persistent on a database, for instance, I like to have the choice between a full-fledged component and a poor man component that satisfies my basic requirements and nothing more. I don't want to be forced to use a monolithic-good-for-everybody solution. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 7, 12:24 pm, Michele Simionato <[EMAIL PROTECTED]> wrote: > Here we disagree: I think that a programmer should know what he > is using. My point was that they should not *need* to know. Too much information can be detrimental. > > Where is the session data stored: in memory, files, database and so > > on. > > Of course Beaker has all these features Well their main page does not say anything about database based storage: http://beaker.groovie.org/ but then a Pylons wiki says it does, but I could not find any information on out how to set up beaker with a database ... truth to be told I was just curious of how they would go about integrating a database and still keep it "pluggable". Because it would either need to know about the way the server handles the database connections (which makes it application specific) or it has to create new database connections in which case it would be duplicating the functionality leading to all kinds of headaches. So there, even a simple requirement exposes the fallacy of building anything complex out of "pluggable" components. i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 7, 11:31 am, Istvan Albert <[EMAIL PROTECTED]> wrote: > IMO this is not as much a framework comparison rather than an > evaluation of the individual components that make up Pylons. More in general let's say that I am interested in the evaluation of WSGI-compatible components. > The framework is the sum of all its parts. Programmers should not need > to know that that a package named Beaker is used for sessions, Routes > for url mapping, PasteDeploy for whatever. This is the weakness of all > glue-type frameworks i.e. TG and Pylons. It makes them look like they > are duct-taped together. Here we disagree: I think that a programmer should know what he is using. Moreover I think that composability is good since you can understand the components one at the time and replace one component with another according to your needs. OTOH, it is true that duct-taped framework have some weak points, I am the first to recognize that. But I also think the issues will be less and less relevant as time goes by and the culture of composable frameworks will become more widespread in the community. > The more important question are whether the sessions actually work > properly: i.e does session data persist through a server restart? > Where is the session data stored: in memory, files, database and so > on. Of course Beaker has all these features and I have no reasons to believe they will not work. > The choice of templating language should be a non issue. Any half > decent framework should allow you to use any other templating engine > with ease. > ... even python as you seem to prefer > Yes, the choice of templating language is a non-issue. Maybe I should have removed my considerations on the subject in my essay, just to avoid the bikeshed effect. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
IMO this is not as much a framework comparison rather than an evaluation of the individual components that make up Pylons. The framework is the sum of all its parts. Programmers should not need to know that that a package named Beaker is used for sessions, Routes for url mapping, PasteDeploy for whatever. This is the weakness of all glue-type frameworks i.e. TG and Pylons. It makes them look like they are duct-taped together. The more important question are whether the sessions actually work properly: i.e does session data persist through a server restart? Where is the session data stored: in memory, files, database and so on. The choice of templating language should be a non issue. Any half decent framework should allow you to use any other templating engine with ease. ... even python as you seem to prefer i. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 7, 8:36 am, Bruno Desthuilliers > Indeed. But AFAICT, Lawrence and Michele problems is not to port an > existing web application, but to choose a web framework that will play > well with their existing *system* (RDBMS, existing apps and libs etc). > Which is quite another problem, and may eliminate some otherwise pretty > good frameworks for compatibility reasons (DBMS support and other issues). > > (please Michele or Lawrence correct me if I'm wrong...) Yes, our main concern is compatibility with the existing system: for instance, one constraint is the MS SQL database. Having said that, we would like to port parts of a Zope application to the new framework, but I do not expect this to be particularly difficult for the parts we want to migrate since they are not really using Zope features. Other parts instead would require a very substantial rewrite so for the moment I think they will stay in Zope. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Steve Holden a écrit : > Lawrence Oluyede wrote: (snip) >> We (Michele, myself and our colleagues) have a series of stuff we need >> to stick to so the choosing of a web framework ain't that easy. Most of >> the frameworks are a vision of the author of how to do things from >> scratch but a framework (by definition an evolution of a library) is not >> always meant to be used when the scratch is far from your starting >> point. >> > Porting existing web applications to new architectures requires more > than just transliteration, since you lose some metaphors available only > in the donor system and may therefore need to take advantage of new > idioms in the new environment to compensate. > > I spent some time trying to re-architect the code from "Python Web > Programming" in TurboGears. That was difficult not because TG is a bad > system but because there was an impedance mismatch between the original > code's framework and the way TG does things. > > I guess I would have similar problems with Django. Indeed. But AFAICT, Lawrence and Michele problems is not to port an existing web application, but to choose a web framework that will play well with their existing *system* (RDBMS, existing apps and libs etc). Which is quite another problem, and may eliminate some otherwise pretty good frameworks for compatibility reasons (DBMS support and other issues). (please Michele or Lawrence correct me if I'm wrong...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Lawrence Oluyede wrote: > Jorge Godoy <[EMAIL PROTECTED]> wrote: >> What is good, since a lot of good things from Pylons will work with TG and a >> lot of good TG things will remain (and possibly be compatible with Pylons). >> If you take a better look at "the next version", you'll also see that the >> major concern was with WSGI support and reinventing / "rewriting" the wheel >> (what TG developers don't want to do all the time). > > Not reinventing the wheel just don't feel as a universal dogma to me. I > developed quite a bit with Django and I was glad they started from > scratch. On the paper reusing different and existing projects is great > but not always is good or done the right way. Anyway I don't know TG at > all so I'm speaking in a figurative way. > > We (Michele, myself and our colleagues) have a series of stuff we need > to stick to so the choosing of a web framework ain't that easy. Most of > the frameworks are a vision of the author of how to do things from > scratch but a framework (by definition an evolution of a library) is not > always meant to be used when the scratch is far from your starting > point. > > I'd like to read some commenting of Michele's thoughts, they would be > really useful. > > :-) > Porting existing web applications to new architectures requires more than just transliteration, since you lose some metaphors available only in the donor system and may therefore need to take advantage of new idioms in the new environment to compensate. I spent some time trying to re-architect the code from "Python Web Programming" in TurboGears. That was difficult not because TG is a bad system but because there was an impedance mismatch between the original code's framework and the way TG does things. I guess I would have similar problems with Django. regards Steve -- Steve Holden+1 571 484 6266 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://del.icio.us/steve.holden Sorry, the dog ate my .sigline so I couldn't cat it -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
But the question is when will the cheap hosting company's start to host normal python files! On 10/7/07, genro <[EMAIL PROTECTED]> wrote: > > On Oct 7, 8:35 am, Michele Simionato <[EMAIL PROTECTED]> > wrote: > > On Oct 6, 12:57 pm, Bruno Desthuilliers > > > > > Michele Simionato a écrit : > > > > > > I looked at the source code and it seems fine to me, but I have > > > > not used it directly, not stressed it. I need a > > > > production-level WSGI session middleware and I wonder what the > > > > players are (for instance how Beaker does compare with flup?) > > > > > Can't tell, but I'd trust the Pylons team on this kind of choices. > > > They're doing good job so far AFAICT. > > > > Probably Beaker works well, but it is certainly NOT doing things > > as Eby recommends: > > > > http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html > > > > BTW, I know that Eby is asking opinions about WSGI 2.0 on the > > WSGI SIG and interested people may have a look there. > > > >Michele Simionato > > > I think that Beaker is a Mako dependency. > So if you use Mako, Beaker is not an option :) > > G > > > -- > http://mail.python.org/mailman/listinfo/python-list > -- http://www.goldwatches.com/mens/cufflinks.html http://www.jewelerslounge.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 7, 8:35 am, Michele Simionato <[EMAIL PROTECTED]> wrote: > On Oct 6, 12:57 pm, Bruno Desthuilliers > > > Michele Simionato a écrit : > > > > I looked at the source code and it seems fine to me, but I have > > > not used it directly, not stressed it. I need a > > > production-level WSGI session middleware and I wonder what the > > > players are (for instance how Beaker does compare with flup?) > > > Can't tell, but I'd trust the Pylons team on this kind of choices. > > They're doing good job so far AFAICT. > > Probably Beaker works well, but it is certainly NOT doing things > as Eby recommends: > > http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html > > BTW, I know that Eby is asking opinions about WSGI 2.0 on the > WSGI SIG and interested people may have a look there. > >Michele Simionato I think that Beaker is a Mako dependency. So if you use Mako, Beaker is not an option :) G -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 12:57 pm, Bruno Desthuilliers > Michele Simionato a écrit : > > > I looked at the source code and it seems fine to me, but I have > > not used it directly, not stressed it. I need a > > production-level WSGI session middleware and I wonder what the > > players are (for instance how Beaker does compare with flup?) > > Can't tell, but I'd trust the Pylons team on this kind of choices. > They're doing good job so far AFAICT. Probably Beaker works well, but it is certainly NOT doing things as Eby recommends: http://dirtsimple.org/2007/02/wsgi-middleware-considered-harmful.html BTW, I know that Eby is asking opinions about WSGI 2.0 on the WSGI SIG and interested people may have a look there. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Michele Simionato a écrit : > On Oct 6, 9:13 am, Bruno Desthuilliers [EMAIL PROTECTED]> wrote: >> - talking about routes, you say: >> >> """ >> I have no Ruby On Rails background, so I don't see the advantages of routes. >> """ >> >> I don't have any RoR neither, but as far as I'm concerned, one of the >> big points with routes is url_for(), that avoids having too much >> hard-coded urls. > > Well, url_for is convenient, I would not deny it. Still it is > not compelling to me. To me, yes - but the context probably makes some difference here. Anyway, even for apps I developped with older versions of Django or for Trac plugins, I missed this feature. I like being able to reorganize my url space, and having urls knowldege all over is very bad IMHO. While perhaps not the ultimate solution (is there one), routes does a good job with this IMHO. (snip) >> - about SQLAlchemy : here again, I used this package prior any >> experience with Pylons. FWIW, I used it in the most basic, 'low-level' >> way, ie without any ORM stuff, and I found it to be a pretty good >> alternative to db-api. It's a bit complex, but powerful, and having the >> possibility to handle sql requests as Python objects (instead of raw >> strings) really helps. > > I have wanted to do a serious test of SQLAlchemy for a > couple of years, but never found the time :-( Then rejoice : you'll have a better package to test, with better documentation !-) > Do you (or something else) have something to say about Beaker? Sorry, not so far. As I mentionned, I had to delay serious work with Pylons so far. > I looked at the source code and it seems fine to me, but I have > not used it directly, not stressed it. I need a > production-level WSGI session middleware and I wonder what the > players are (for instance how Beaker does compare with flup?) Can't tell, but I'd trust the Pylons team on this kind of choices. They're doing good job so far AFAICT. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
> I really, really like Django (and its community and the competence of > the developers) and I think it deserves what it has gained and more but > we are not here to decide who's the best (there's always no best). +1 QOTW -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Tim Chase <[EMAIL PROTECTED]> wrote: > Any respectable comparison of Python web frameworks should > include evaluation of at least Django and TG. Or at least give > good reason why the comparison excludes them. I think you didn't read the foreword of the comparison. That is by no means a comprehensive comparison and is not meant to be one. Is a series of thoughts about the frameworks we already tried (we don't have to decide today) and the ones we experimented with. Django is not completely off the radar because I used it extensively this year but the company has certain requirements and the full stackness of Django is not really one of our needs. > Zope is also missing, but I'm not sure Zope qualifies so much as > a framework, but as an answer to the question "If Emacs were a > Python web environment, what would it look like?" Zope2/Plone2 is the one framework they are running away from :-) More KISS less over engineering, that's the mantra. > Django's built-in templating system is one of those things you > either love or you hate. Fortunately, if you're a hater, you can > mindlessly swap it out for your template system of choice with > minimal fuss. I really, really like Django (and its community and the competence of the developers) and I think it deserves what it has gained and more but we are not here to decide who's the best (there's always no best). -- Lawrence, oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Jorge Godoy <[EMAIL PROTECTED]> wrote: > What is good, since a lot of good things from Pylons will work with TG and a > lot of good TG things will remain (and possibly be compatible with Pylons). > If you take a better look at "the next version", you'll also see that the > major concern was with WSGI support and reinventing / "rewriting" the wheel > (what TG developers don't want to do all the time). Not reinventing the wheel just don't feel as a universal dogma to me. I developed quite a bit with Django and I was glad they started from scratch. On the paper reusing different and existing projects is great but not always is good or done the right way. Anyway I don't know TG at all so I'm speaking in a figurative way. We (Michele, myself and our colleagues) have a series of stuff we need to stick to so the choosing of a web framework ain't that easy. Most of the frameworks are a vision of the author of how to do things from scratch but a framework (by definition an evolution of a library) is not always meant to be used when the scratch is far from your starting point. I'd like to read some commenting of Michele's thoughts, they would be really useful. :-) -- Lawrence, oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 9:13 am, Bruno Desthuilliers wrote: > - talking about routes, you say: > > """ > I have no Ruby On Rails background, so I don't see the advantages of routes. > """ > > I don't have any RoR neither, but as far as I'm concerned, one of the > big points with routes is url_for(), that avoids having too much > hard-coded urls. Well, url_for is convenient, I would not deny it. Still it is not compelling to me. > - about FormEncode : that's a package I've used before without Pylons, > and while it has a few dark corners, it's mostly doing TheRightThing for > most current validation/conversion tasks. I'll still use it with or > without Pylons > > - about SQLAlchemy : here again, I used this package prior any > experience with Pylons. FWIW, I used it in the most basic, 'low-level' > way, ie without any ORM stuff, and I found it to be a pretty good > alternative to db-api. It's a bit complex, but powerful, and having the > possibility to handle sql requests as Python objects (instead of raw > strings) really helps. I have wanted to do a serious test of SQLAlchemy for a couple of years, but never found the time :-( Do you (or something else) have something to say about Beaker? I looked at the source code and it seems fine to me, but I have not used it directly, not stressed it. I need a production-level WSGI session middleware and I wonder what the players are (for instance how Beaker does compare with flup?) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Michele Simionato a écrit : > At work we are shopping for a Web framework, so I have been looking at > the available options > on the current market. In particular I have looked at Paste and Pylons > and I have written my > impressions here: > > http://www.phyast.pitt.edu/~micheles/python/yet-another-comparison-of-web-frameworks.html > > I do not speak too well of Pylons, so if you thing I am wrong feel > free to correct me here ;) > Well... Last year, I had a look at Pylons, then played a bit with wsgi and building my own framework over it. I finally dropped that code and went back to Pylons, which I felt could become far better than my own efforts. Now since then I had way too much to do at work (using other technos) and didn't find the time to work on my own projects, so I still don't know how well Pylons will pass the "real world" test, but it seems to me that it's rapidly progressing and mostly in the right direction. I still wait for an opportunity to check this out !-) While we're at it: - talking about routes, you say: """ I have no Ruby On Rails background, so I don't see the advantages of routes. """ I don't have any RoR neither, but as far as I'm concerned, one of the big points with routes is url_for(), that avoids having too much hard-coded urls. - about FormEncode : that's a package I've used before without Pylons, and while it has a few dark corners, it's mostly doing TheRightThing for most current validation/conversion tasks. I'll still use it with or without Pylons - about SQLAlchemy : here again, I used this package prior any experience with Pylons. FWIW, I used it in the most basic, 'low-level' way, ie without any ORM stuff, and I found it to be a pretty good alternative to db-api. It's a bit complex, but powerful, and having the possibility to handle sql requests as Python objects (instead of raw strings) really helps. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
On Oct 6, 7:15 am, Jorge Godoy <[EMAIL PROTECTED]> wrote: > Tim Chase wrote: > > Any respectable comparison of Python web frameworks should > > include evaluation of at least Django and TG. Or at least give > > good reason why the comparison excludes them. Mine is not a respectable comparison of Web frameworks, it is NOT intended to be so. It is just a set of notes I kept for myself and that may be or may be not of interest to others. > When he said that he didn't want anything complex neither anything that used > a templating system, I thought this had already excluded a lot of > frameworks, including TG and Django. This is clearly not true, since I could use these frameworks without using their templates if I wanted. It would be very stupid to dismiss an entire framework only because I dislike its templates. > > Zope is also missing, but I'm not sure Zope qualifies so much as > > a framework, but as an answer to the question "If Emacs were a > > Python web environment, what would it look like?" > > He already had dislikings with Plone that weren't clear, maybe a lot of > those are Zope related... > > I agree, though, that more time could be spent explaining "why" things were > discarded / ignored. Look, there are already tons of pages on the net ranting against Zope, my complaints are quite common and I have no interest in repeating what has been already said. For instance, if you Google a bit you should find the rants of the Quixote people against Zope. I share their position. I did not talk about TG because I see it as being very close to Pylons and everybody is saying they will be unified in the near future, so it would be a waste of effort to discuss TG per se. Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Lawrence Oluyede wrote: > Thomas Wittek <[EMAIL PROTECTED]> wrote: >> At least, you missed Turbo Gears :) >> http://turbogears.org/ >> For me, it feels more integrated than Pylons. > > Yeah, so integrated that the next version will be based upon Pylons ;-) ? What is good, since a lot of good things from Pylons will work with TG and a lot of good TG things will remain (and possibly be compatible with Pylons). If you take a better look at "the next version", you'll also see that the major concern was with WSGI support and reinventing / "rewriting" the wheel (what TG developers don't want to do all the time). As an example of this fusion, take a look at ToscaWidgets. Works, *today*, with both frameworks. You don't have to wait for "the next version". -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Tim Chase wrote: > Any respectable comparison of Python web frameworks should > include evaluation of at least Django and TG. Or at least give > good reason why the comparison excludes them. When he said that he didn't want anything complex neither anything that used a templating system, I thought this had already excluded a lot of frameworks, including TG and Django. > Zope is also missing, but I'm not sure Zope qualifies so much as > a framework, but as an answer to the question "If Emacs were a > Python web environment, what would it look like?" He already had dislikings with Plone that weren't clear, maybe a lot of those are Zope related... I agree, though, that more time could be spent explaining "why" things were discarded / ignored. -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
>> At work we are shopping for a Web framework, so I have been >> looking at the available options on the current market. > > At least, you missed Turbo Gears :) > http://turbogears.org/ > For me, it feels more integrated than Pylons. Django [1] barely gets anything more than a mention as well. Any respectable comparison of Python web frameworks should include evaluation of at least Django and TG. Or at least give good reason why the comparison excludes them. Zope is also missing, but I'm not sure Zope qualifies so much as a framework, but as an answer to the question "If Emacs were a Python web environment, what would it look like?" I chose Django, but saw the power in TG as well...from my testing of them, Django has a nice unified OOB experience, while TG feels like it's trying to rein in very strong, but disparate parts. Django's built-in templating system is one of those things you either love or you hate. Fortunately, if you're a hater, you can mindlessly swap it out for your template system of choice with minimal fuss. -tim [1] http://www.djangoproject.com -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Thomas Wittek <[EMAIL PROTECTED]> wrote: > At least, you missed Turbo Gears :) > http://turbogears.org/ > For me, it feels more integrated than Pylons. Yeah, so integrated that the next version will be based upon Pylons ;-) ? -- Lawrence, oluyede.org - neropercaso.it "It is difficult to get a man to understand something when his salary depends on not understanding it" - Upton Sinclair -- http://mail.python.org/mailman/listinfo/python-list
Re: Yet another comparison of Python Web Frameworks
Michele Simionato: > At work we are shopping for a Web framework, so I have been looking at > the available options > on the current market. At least, you missed Turbo Gears :) http://turbogears.org/ For me, it feels more integrated than Pylons. -- Thomas Wittek Web: http://gedankenkonstrukt.de/ Jabber: [EMAIL PROTECTED] GPG: 0xF534E231 -- http://mail.python.org/mailman/listinfo/python-list
Yet another comparison of Python Web Frameworks
At work we are shopping for a Web framework, so I have been looking at the available options on the current market. In particular I have looked at Paste and Pylons and I have written my impressions here: http://www.phyast.pitt.edu/~micheles/python/yet-another-comparison-of-web-frameworks.html I do not speak too well of Pylons, so if you thing I am wrong feel free to correct me here ;) Michele Simionato -- http://mail.python.org/mailman/listinfo/python-list
