[PEAK] PEAK-Rules for Python3

[PJ Eby]

A further update: all shallow and cascading failures in 3.x are fixed,
and the remaining broken feature has been fixed with another syntax
workaround.  At this point, PEAK-Rules should have clean test runs on
both Python 2.x and 3.x ,when it and its dependencies are the latest
from SVN.  (Note that I made some BytecodeAssembler changes today, and
you need those, too!)

Please let me know if you're seeing any test failures or experiencing
any breakage in 3.x code using PEAK-Rules.

If you want to move your code that uses PEAK-Rules to 3.x, and you are
using the syntax-matching rules feature or the let-binding arguments
feature, you'll need to tweak your code to use the new 2.x/3.x
cross-compatible syntax for these features.

Syntax rules with backquoted names (e.g. "type(`x`) is `y`") are now
replaced with double-tilded names ("type(~~x) is ~~y").   And methods
with binding-tuple arguments must be expanded from e.g.:

@when(something, "let(x=1, y=2) and somethingElse(foo)")
def aMethod((x,y), foo):
    ...

to:

@when(something, "let(x=1, y=2) and somethingElse(foo)")
def aMethod(__args__, foo):
    (x,y) = __args__
    ...

(This isn't a general repacement for named-tuple arguments, just for
ones used with PEAK-Rules' let-binding feature.  The special argument
*must* be named __args__ and it *must* be unpacked to the desired
named arguments as the first code inside the function body.
Otherwise, an exception will be raised.)

Both backquoted names and let-bindings are fairly obscure features of
PEAK-Rules, but now it's possible to port code using them to 3.x.  The
old ways of spelling these features remain so that old code doesn't
break, and the new ways work under both 2.x and  3.x so you can begin
switching your 2.x code even if you're not porting to 3.x yet.


On Thu, Apr 9, 2015 at 1:55 PM, PJ Eby <pje at telecommunity.com> wrote:
> Update: I've reviewed all remaining PEAK-Rules failures on 3.1, 3.2
> and 3.4, and what's left at this point is just a missing feature:
> method argument binding is broken, due to dependence on named tuple
> args.  Everything else is shallow or cascading errors, now that I've
> updated BytecodeAssembler to emulate the SLICE_X opcodes from Python
> 2.x.  (Note that 3.3+ changes dictionary and function reprs and
> certain dissasembly bits, which adds a couple hundred lines more
> failure output compared to 3.1/3.2, but AFAICT these are all shallow.)
>
> Also, I've changed syntax binding variables to the form ~~x instead of
> `x` -- the latter syntax still works on 2.x, but of course is not
> available on 3.x.
>
> If you find anything in PEAK-Rules that's not working on 3.x that
> *doesn't* depend on tuple argument syntax, let me know.
>
> On Thu, Apr 9, 2015 at 12:15 PM, PJ Eby <pje at telecommunity.com> wrote:
>> Yes.  Slicing is broken, as is syntax pattern matching.  I'm not
>> seeing any breakage on peak.rules.debug's import, though.  As of this
>> morning, Python 3.1 has 735 lines of failure output from `setup.py
>> test`, in about 30-something individual doctest failures, almost half
>> of which are pure repr issues, where the values shown as not matching
>> are actually equal.  Most of the remaining ones are either
>> SyntaxErrors caused by unsupported-on-3.x syntax, slicing problems, or
>> cascading errors from the two preceding things.  I only see two errors
>> that look like they need further investigation: the MRO problem in
>> README.txt, and the 'NoneType is not callable' in Predicates.txt.
>>
>> I'm thinking that I need to change the pattern-matching syntax to
>> something like `[[var]]` instead of backquotes, though for backwards
>> compatibility I'll still support backquotes.  But then the tests and
>> things can use [[]] syntax to work across 2.x and 3.x.
>>
>> (Btw, I just checked in some more test cleanup stuff, to clear away
>> several more false positive test failures on 3.x)
>>
>>
>> On Thu, Apr 9, 2015 at 9:50 AM, Cara <ceridwen.mailing.lists at gmail.com> wrote:
>>> I haven't had much chance to look at this this week, but I checked out
>>> and installed the current versions in SVN.  Except for the same
>>> segfaults in BytecodeAssembler's tests, most of the major bugs I saw are
>>> gone.  There are some real bugs still in PEAK-Rules, some of which are
>>> shallow but may be concealing more serious bugs (the peak.rules.debug
>>> import in test_rules.py is broken), some of which are shallow and easily
>>> fixable (__repr__ differences), and some of which look like real bugs.
>>> I could post the log if it would be helpful, but I assume you're seeing
>>> the same thing.
>>>
>>> Cara
>>>
>>>