Re: [Webware-devel] Future Webware versions
On 3/18/07, Christoph Zwerschke [EMAIL PROTECTED] wrote: On webware-discuss I already announced that I want to release the next Webware version 0.9.3 very soon. If anybody has suggestions or patches or bug reports that I should take into account, please let me know. I had a problem on Mac using Webware out of the repository where the AutoReload feature would not work. I believe it threw an exception related to importing modules, but it's been awhile. I'll try to test it out this week and see if I can reproduce and fix it. What about the idea of releasing a 1.0 version without much change if the 0.9.3 turns out to be stable? Sounds good to me. I had thought about suggesting the same thing. One big change I wanted to make is to require Python 2.3 or 2.4. This would allow us to remove a lot of old garbage and code many things simpler. It would be an opportunity to really clear out the code base. The question is should we do this before or after 1.0 because these refactoring will certainly bring some instability again. (Unfortunately, Webware's few tests do not cover very much.) I really think we should up the requirement *after* 1.0 since we're so close to 1.0 right now. The next big change could be the transition to more contemporary coding style and tools, naming conventions, using setuptools and getting rid of Webware's peculiar plug-in architecture. This would break backward compatibility more or less so it should be done in a new major version as well. I'm also not sure whether I or anybody else will have enough time and energy to ever tackle this. For new projects, it seems to make more sense to use one of the nice contemporary web frameworks. So it may be better to release the 1.0 now than never. I guess the question is whether or not anyone will put in the time to do these things. My particular wish is for more properties and less methods. For example, self.request.urlPath. But I was hoping a nicer syntax for properties would have been added to Python by now! Note that backward compatibility can still be maintained by having WebKit.Object __call__() return self. I also have a setUp() and tearDown() for servlets that don't require a parameter or calling super (unlike awake/sleep). I've been using them locally, but they're not checked in. I also have a bunch of reusable code which I felt I didn't have time to document and support properly... I'm still using Webware, but I'm also pretty busy and Webware does what I need it to do. That makes it hard for me to find time for enhancing it. And btw we all appreciate your efforts, Christoph! You've been great for the project. -Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Future Webware versions
On Mar 19, 2007, at 8:53 AM, Chuck Esterbrook wrote: And btw we all appreciate your efforts, Christoph! You've been great for the project. Allow me to ditto that remark. Your work, Christoph, is a tremendous benefit to the Webware project. Many thanks, Mark Phillips - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
Re: [Webware-devel] Future Webware versions
On 3/19/07, Christoph Zwerschke [EMAIL PROTECTED] wrote: Chuck Esterbrook wrote: I had a problem on Mac using Webware out of the repository where the AutoReload feature would not work. I believe it threw an exception related to importing modules, but it's been awhile. I'll try to test it out this week and see if I can reproduce and fix it. Unfortunately I have no Mac experience and equipment, so it will be good if you check this. The only thing I did last time was running the tests on a Mac in the SourceForge compile farm, but that probably didn't cover the AutoReload feature. I really think we should up the requirement *after* 1.0 since we're so close to 1.0 right now. Ok. I'll postpone major changes until then. We can then maintain the stable branch as 1.0.x and continue with 1.1 or 2.0 depending on how radically we're going to change and break things, or maybe we make two steps. I like your idea of properties with the __call__ hack for backward compatibility. Another question is whether we should support WSGI and develop Webware in a similar direction as Ian's Wareweb, maybe reusing some of his idea and code. Btw, how do you think about the transition from tabs to spaces? Before 1.0, after 1.0, or never? ;-) 4 spaces are standard per PEP 008, and it seems they will even become standard for C sources of Python 3K. What about [EMAIL PROTECTED]'s suggestion: What if you stayed with tabs and then added a converter, so that you can quickly convert the tabs to the number of spaces that you want? In fact, this might be a good idea for a lot of free source Python projects distributed on the web -- though I would suspect it would be better to use tabs as the default and offer the ability to convert to space because sometimes it's possible it might not look quite right converting a project coded for spaces to tabs. It allows everyone to use their favorite approach. You mentioned something about patches being a mess, but I don't see why. People could send in patches as all spaces or all tabs or am I not thinking of something? I suppose there would then be a burden on people who use spaces to invoke a script prior to checkin, but could that also be done via a script? Something like: # ci tabify -r . svn ci $* spacify -r . The -r . could actually be the default behavior of tabify and spacify. The ci script could be put in your path. Would this make life better? -Chuck - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
[Webware-devel] Future Webware versions
On webware-discuss I already announced that I want to release the next Webware version 0.9.3 very soon. If anybody has suggestions or patches or bug reports that I should take into account, please let me know. What about the idea of releasing a 1.0 version without much change if the 0.9.3 turns out to be stable? One big change I wanted to make is to require Python 2.3 or 2.4. This would allow us to remove a lot of old garbage and code many things simpler. It would be an opportunity to really clear out the code base. The question is should we do this before or after 1.0 because these refactoring will certainly bring some instability again. (Unfortunately, Webware's few tests do not cover very much.) The next big change could be the transition to more contemporary coding style and tools, naming conventions, using setuptools and getting rid of Webware's peculiar plug-in architecture. This would break backward compatibility more or less so it should be done in a new major version as well. I'm also not sure whether I or anybody else will have enough time and energy to ever tackle this. For new projects, it seems to make more sense to use one of the nice contemporary web frameworks. So it may be better to release the 1.0 now than never. Thoughts and suggestions concerning future versions, anyone? -- Christoph - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
