René Dudfield schrieb: > On Sat, Sep 19, 2009 at 2:26 PM, Georg Brandl > <g.brandl-hi6y0cq0...@public.gmane.org> wrote: >> René Dudfield schrieb: >> >>>>> Here is a snippet from the compat.py we used to port pygame to support >>>>> python2.3 through 3.1 >>>> How is that related? >>>> >>> >>> Rather than using a 2to3 tool - which then makes you have two versions >>> of your code, making the code work in python 2.x and 3.x. 2to3 >>> outputs python2.x incompatible code - when it doesn't have to. >> >> Sorry, but I think you do not express the intent of 2to3 correctly here. >> It is not meant to provide a one-time conversion, so that you then >> have to maintain two codebases, it is meant to be run over your 2.x code >> every time you want to distribute a version for Python 3, or even >> transparently in the distutils build process. This of course means that >> the 2.x code needs to be written with 3.x and the conversion in mind. >> > > My point is: using b'' stops those that choose to have one code base. > Not everyone can use 2to3, but for those that can: great! > > There is no 2to3 for extension modules.
Of course not, since it is for Python code. How you handle your C modules (whose API has not changed very dramatically) is not relevant to how you handle your Python modules. > There is no 2to3 distutils mod to run 2to3 automatically at this time > (correct me if I'm wrong). Yes, there is. It's what e.g. docutils and pygments are using. > People are creating separate branches for py3k... and those projects > that do that seem to let the py3k version rot. That's because they don't get enough advice about porting, despite there being a mailing list, or frown upon using 2to3 for whatever reasons. > You still need to debug, and support multiple versions of code... > since 2to3 generates multiple versions. This is what a test suite is made for. > If someone sends you a patch for the 3.0 version > you need to either reverse it yourself or find someone to do it for > you... same thing with bug reports and tracebacks. Yes, but the version that 2to3 generates is usually not far from the original, so you should have no problem adapting the patch. When someone sends you a patch for a single-source project, he will very probably not know that it is a single-source project, and use either 2.x or 3.x specific things in it, and you have to adapt it as well. Certainly, maintaining a project for 2.x and 3.x compatibility *is* going to be more work, no matter how you choose to do it. But saying that 2to3 is bad because you then have to source trees to maintain is plain wrong. >> Writing code that runs unchanged on 2.x (where x < 6) and 3.x may seem >> nice, but forces you to do unnecessary workarounds, e.g. in exception >> handlers. > > Well, I'm sure there are cases where it would cause unnecessary > workarounds... however with the right compat.py and compat.h setup it > hasn't been too hard in my experience in porting this way. > > There is an easy workaround for the exceptions changes... > # define geterror in your compatibility module. > def geterror (): > return sys.exc_info()[1] > > Now you can write: > except ImportError: > e = geterror() This is exactly what I mean by unnecessary workarounds. Anyway, this thread is not supposed to be about 2to3 or syntax differences between 2.x and 3.x, so I'll stop here; more about this should go to python-porting. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. _______________________________________________ Web-SIG mailing list Web-SIG@python.org Web SIG: http://www.python.org/sigs/web-sig Unsubscribe: http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
