[PEAK] trying to run peak-rules on python3

PJ Eby pje at telecommunity.com
Tue Mar 19 13:25:24 EDT 2013

On Tue, Mar 19, 2013 at 11:04 AM, Hervé Coatanhay
<herve.coatanhay at gmail.com> wrote:
> I did changes in README.txt to pass test. Mostly obvious ones, like print
> and types changes. But i had to replace DUP_TOPX with DUP_TOP_TWO (I'm not
> entirely sure if that's OK).

Me either.  I haven't messed with py3 bytecode at all yet.  But if I
understand correctly, DUP_TOPX(1) would map to DUP_TOP and DUP_TOPX(2)
would map to DUP_TOP_TWO, but any larger number and it's more
complicated than that.

> There are still some failing tests. One seems like some discrepancy between
> python2 and python3:
> In python2:
>>>> exec(compile('42', '', 'eval'))
>>>> eval(compile('42', '', 'eval'))
> 42
> In python3:
>>>> exec(compile('42', '', 'eval'))
> 42
>>>> eval(compile('42', '', 'eval'))
> 42

That one probably won't affect anything in PEAK-Rules.

> Other failing tests a related to the use of from_function classmethod. I'm
> suspecting some issue with DecoratorTools because Decoratools tests are not
> passing. I'll try to make them pass.
> Finally, there are 2 tests failing that i don't know where to start with:
>     >>> from peak.util.assembler import TryExcept
>     >>> c = Code()
>     >>> c.return_(
>     ...     TryExcept(
>     ...         Return(1),                                      # body
>     ...         [(Const(KeyError),2), (Const(TypeError),3)],    # handlers
>     ...         Return(4)                                       # else
> clause
>     ...     )
>     ... )

Not sure what's up with this one: the log you sent shows this actually
having the same code (or at least as far as I can see).  It shouldn't
be a whitespace difference, as I think the flags are set to ignore

>     >>> c = Code()
>     >>> c(1, True, 1.0, 1)     # equal, but different types
>     >>> dis(c.code())

This is a 2to3 artifact: the original test had the fourth value as
"1L", which resulted in a fourth constant.  Python 3 doesn't have a
distinct type for longs, so there's no way to create that value.  So
this failure is of no consequence.

Anyway, what about PEAK-Rules' own tests?  It's got quite a lot of
them, including for the criteria and predicate and indexing systems.

More information about the PEAK mailing list