Re: PEAK-Rules for Python3
PJ Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> Fri, 3 Apr 2015 20:56:47 -0400
| Newsgroups | gmane.comp.python.peak |
|---|---|
| Message-ID | <CALeMXf6HYobNT-BfiQo6VBK235WDubKpANwk0rk7Mr-Z9rde3w@mail.gmail.com> |
On Fri, Apr 3, 2015 at 5:58 PM, PJ Eby <pje-Wh6+Hckhi6HFNGf7iClzIwC/[email protected]> wrote: > This is basically a monkeypatch to post-process class decorators on > Python 3, by detecting DecoratorTools' metaclass-decorator protocol > and only applying the decoration part, not the metaclass part. I > would be very interested in seeing what test failures are left after > you add this, and the code I just checked in to fix the > unittest-related failure. If this patch above works, then we should > also see a lot fewer failures for AddOns as well. Update: the SVN versions of DecoratorTools and AddOns now run with clean tests on Python 3.1 and 3.2; I haven't tried anything more recent yet. I'm playing around with BytecodeAssembler, and have gotten it down to only a couple hundred lines of error output on the tests; no crashes yet on 3.1 or 3.2. FYI, the way I changed the call signature for creating code objects was to add a zero as the *second* argument to code(); if you added the extra argument someplace else it might be what's causing your core dump. The remaining failures are either shallow (the representation of error type names in doctest) or expected (tuple-unpacking arguments not supported in Python 3, or the disappearance of the DUP_TOPX opcode). Anyway, I've also checked in the BytecodeAssembler work I've done so far -- it *should* work well enough for PEAK-Rules, but only testing will tell.