Pulling this conversation back to the Python 3 thread Thomas started, didn't mean to hijack my own patch thread with a Python 3 discussion.
On Thu, Aug 2, 2012 at 1:56 PM, Anand Chitipothu <[email protected]> wrote: > >> I posted some details of my initial thoughts on the 22nd, but two > immediate > >> action items were to update the wsgiserver code from CherryPy as that > is now > >> Python 2/3 compatible, and to identify how to best upgrade to Python 3's > >> unicode handling (moving encoding/decoding to a python 2 only module, > >> perhaps) since that was the biggest issue I ran into with my first > attempt. > > > > I think we should start depending on cherrypy-wsgiserver instead of > > shipping a copy with web.py. When we started using it, it was not > > available on pypi. > > > > cherrypy-wsgiserver is not available for Python3, at least on pypi. We > > should provide alternate implementation of dev server using wsgiref. > Personally, I disagree - I hate having to go out and grab (and build, install, etc.) additional projects when I want to try out some new tool, I loved that I was able to drop the web.py codebase onto my machine and get everything up and running in a matter of moments, without any hassle. Especially given that the cherrypy code isn't intended to be used in production, just for development and testing, it seems doubly unhelpful to pull it out into a dependency. The current wsgiserver code on CherryPy's source repository is Python 2/3 compatible, handled by a version check in the package's __init__.py: https://bitbucket.org/cherrypy/cherrypy/src/b0c48210b250/cherrypy/wsgiserver/__init__.py It would be a fairly safe and very simple change to upgrade web.py's wsgiserver directory with this code. Even if you'd prefer ultimately to move to a dependency model, that's a serious, and backwards-incompatible change, where upgrading is reasonably trivial. I'd suggest solving the 2/3 problem first, then outsourcing the CherryPy dependencies later, if that's really valuable for the project. > > One of the burdens web.py carries is python2.3 compatibility. When I > last heard, Python 2.3 was still supported on Redhat servers. It might > have changed now. Anybody knows what is the status now? > Thanks for the input Zhang. Personally, I have no objection to dropping 2.3 support (or for that matter, all of 2!), but I don't really think that's the proper thing to do. Like above, backwards-incompatible changes are a dangerous design decision, and if we can in any way implement Python 3 support without breaking existing support, that would be ideal. CherryPy still supports 2.3, according to the documentation in this file: https://bitbucket.org/cherrypy/cherrypy/src/b0c48210b250/cherrypy/_cpcompat.py which also details how they handled the string encoding issues I described earlier, so I think it should be possible. I hadn't actually spotted that file before googling to see if CherryPy supported 2.3, and coincidentally (or not) the page I found was their solution to the biggest sticking point I'd hit thus far. I'll try to play with applying this methodology to some of web.py when I have a chance. >From their source code: > Python 2 uses str and '' for byte strings, while Python 3 > uses str and '' for unicode strings. We will call each of these the 'native > string' type for each version. Because of this major difference, this > module > provides new 'bytestr', 'unicodestr', and 'nativestr' attributes, as well > as > two functions: 'ntob', which translates native strings (of type 'str') into > byte strings regardless of Python version, and 'ntou', which translates > native > strings to unicode strings. Michael -- You received this message because you are subscribed to the Google Groups "web.py" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/webpy?hl=en.
