On Apr 24, 9:21 am, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote: > > Again, to me, this is a non-issue because I've been able to create a > > cross-version compatible single codebase for pyparsing. But it was a > > bit dicey there for a while, and I think other module developers/ > > maintainers may not be so lucky. > > I'm more optimistic. I tried it for Django, and while the port is not > complete, it goes really well and supports "basic" operations (i.e. > the Django tutorial). > > Based on your experience, and other reports, I think there is a fair > chance that you can support a wide range of versions (2.x and 3.x) > from a single code base for most projects. > > > - create (if possible) single cross-version compatible code > > - forego support of 3.0 users > > - discontinue pre-2.6 support for future versions of their module > > - maintain dual codebase > > One needs to consider the drawbacks in each case; for the single > codebase approach, the drawback probably is that readability > suffers, and the need for testing increases (but it does always > if you support multiple targets). It also requires expertise to > create such cross-version code in the first place, but that's > "just" a learning issue (i.e. you have to keep the rules in mind > that you want to follow). > > Regards, > Martin
Martin -- Well, my concerns about 3.0 continue to be founded. Up until now I have been just reading "What's New" docs, and relying on input from others as to what changes I will have to make. Yesterday I downloaded and installed 3.0a5, and it is clear that there is *no* way to have a single code base for any but the most trivial module. The biggest sticking point is the incompatibility of "except" syntax. Apparently the promise of syntax compatibility in the 3.0a4 docs was an overstatement. Syntax can't be conditionalized out with "if version >= 3:" type code, so I must have separate Python 2.x and Python 3.x codebases, as will anyone whose modules include exception handlers. I also tripped over the conversion from "<iterator>.next()" to "next(<iterator>)". Fortunately, this only occurs in my test cases, so my runtime module will not be affected by extra conditional testing, just to pick the right code form for the particular Python version that is running. Conversion of print from statement to function is definitely more painful than I thought it would be. Again, I am fortunate that this largely affects only my test code, with only minimal impact on my runtime module. I continue to struggle with some of the refactoring done in references to func.func_code, im_self, etc. changing to __code__, __self__, and so on. There is a bit of code in Pyparsing that normalizes user callbacks to a standard call using 3 arguments, and I have to compensate for functions that have self args, or are callables. I see that there is some movement to "get rid of bound methods," but I don't fully understand how this will be done, nor how I will adjust my code to compensate. In fact, I will probably set this effort aside for now, so as to avoid converting/conditionalizing code to alpha versions of Python, and having to change them again for later alphas or the final release. By the way Martin, your work on 2to3 was especially helpful in this effort - thank you! In summary, I am adjusting my plans for future support of Python versions in pyparsing. As of a pyparsing release some time after August, I will only support Python 3.0 versions with any new features or bugfixes, and the pyparsing version that is compatible with Python 2.x will be frozen. -- Paul -- http://mail.python.org/mailman/listinfo/python-list
