I think Massimo has already spoken to all these concerns / issues; Closing files explicitly is stylistic - saying what you mean (and not counting on side-effects of the system); it makes for more readable code in general (although some will complain about an extra line of typing, it is explicit to say "I'm done with this handle now!). Among other things, not depending on side effects of a particular system means your code is more portable to other systems/languages (you may want to move processing from javascript to a controller or vice-versa; you can think of other situations where language choice of a part is beyond your choice).
Massimo has chosen to do this already. As for rewrite for Python 3 at some point in the future (as Massimo alluded to being a possible fork from backward compatibility) that will be an opportunity to look at the application writer's idioms, and if something can be changed to more naturally express the work-flow of expressing business logic, this will be an opportunity to explore that. In the meantime, no worries - openness to feedback is a good thing. On Thu, Aug 6, 2009 at 12:06 PM, waTR <r...@devshell.org> wrote: > > Re-writing a framework after 2-3 years is suicide. First, and > foremost, we do not have enough developers to take-on such a huge > task. Even if we did, it is still too early because they are not > organized for such a task (look at Perl 6...and how long it is taking > them to release a new version). > > Backwards compatibility is EXTREMELY important for a framework to be > taken seriously. If you are looking at this issue from your bedroom > and thinking I want a really fun hot-rod framework to play with, thats > fine. However, for a business, you are looking for something that is: > 1. Going to still be around in 5 years > 2. Going to still be stable & Secure in 5 years > 3. Going to still be compatible in 5 years. > > Don't forget that some companies are still using code written back in > the 1970s (think COBOL). While I agree that it would be FUN to play > with the latest web-framework features, I am sure you are free to fork > this project and take it in an experimental direction. However, try > not to push such a promising potential "enterprise" framework in that > direction. > > As Massimo says, there are no bugs here, rather design decisions. If > you disagree with a design decision, fork and re-design. If you can > live with it, provide some work-around plug-ins to do it the way you > feel it should be done. > > Speaking of which... is there a plug-in function in web2py yet??? It > would be great for web2py to allow people to plug-in these crazy > features so people can choose to try every idea talked about by simply > downloading the plug-in. Then, if it is popular enough, it can be > added to the list of plug-ins that will be included in the main > release once the framework moves to Python 3. > > > > On Aug 6, 7:29 am, Timbo <tfarr...@swgen.com> wrote: > > It's been a while since I've been around but this seems to be an > > important discussion that I'd like to weigh in on. > > > > Massimo is right. Most of Armin's critiques are thought-out design > > decisions. The perceived problems from just looking at the code don't > > play out in reality due to being either a non-issue handled by some > > other mechanism. > > > > The issue of open file-handles is partly an issue and partly Armin > > showing his ignorance of WSGI. Any iterator passed back to a WSGI > > server will be "closed" if it has a close methods and will be > > appropriately deleted. For all the other instances, yes, we should > > close them. > > > > I'm not going to weigh in on the ORM since I currently do not use it > > (however, this might change with the new ORM coming out). > > > > Fact is, I've used web2py for production purposes for more than a year > > now and the only issues I've had with my setup were either my own code > > or issues with python's broken socket library (which the included > > wsgiserver uses). > > > > As for the future of Python...I see cPython becoming what the vanilla > > Linux kernel is today. That is to say, it's sort of the base-line, > > but no distribution uses just the vanilla kernel, but they all add > > their own patches and customizations. Pypy will likely bypass both > > cPython and Jython in performance and flexibility within the next 2 > > years and popularity in the following 5. Python developers will refer > > to cPython more than end-users will actually use it. Google will keep > > using it since they're investing in Unladen-Swallow, but independent > > projects will gear more towards Pypy compatibility due to it's > > platform flexibility, speed and scalability. > > > > That being said, Python 3.x will not be adopted as quickly as some > > would hope. Py3 support is barely on the radar for Pypy and Jython. > > Frankly, even at Python3.1 it's still horribly broken for web- > > development. The Cherrypy and Werkzeug devs are building their own > > versions of the cgi library. > > > > Eventually, web2py will need to have some implementation on Python3, > > but I don't see that as needed for at least 2 more years. Python2 is > > still going very strong. It will be more than 2 years before Google > > migrates. They will likely be the driving force behind moving beyond > > Py2. > > > > Just my 2c > > > > -tim > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web2py@googlegroups.com To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/web2py?hl=en -~----------~----~----~----~------~----~------~--~---
