[PEAK] PEAK-Rules for Python3

[PJ Eby]

On Wed, Apr 1, 2015 at 1:15 AM, Cara <ceridwen.mailing.lists at gmail.com> wrote:
>
> Before I touched the code base at all, I ran all the doctests in Python
> 2.7 to get an idea what was failing.  The results are here:

Those results are incorrect; in fact there are only 3 shallow failures
for Python 2.7 across all the projects you listed.  The correct way to
run the full tests is with "setup.py test".  That will run both the
doctests and the unittests for each project, and with the correct
options for each file/project.

The only projects with failures on 2.7 are PEAK-Rules and
DecoratorTools, and in each case it's due to subtle repr differences
or internal refactorings in 2.7.  Essentially, they work just fine on
2.7

> (The only functionality I could find
> that was broken is that the class decorators don't seem to be working.)

Yes, and that's due to a fundamental limitation in Python 3, which
doesn't have any way to select a metaclass while within a class
definition suite, except by an even nastier global monkeypatching than
the way decoratortools works in general.  This limitation is one of
the many reasons I probably won't be trying to port my projects to
Python 3.  I previously raised the issue on Python-dev (see e.g.
https://mail.python.org/pipermail/python-dev/2012-April/118952.html ),
and there is a PEP (#422) that would address the issue, complete with
a patch ( http://bugs.python.org/issue17044 ), but which has been
languishing for a couple of years.  A couple months ago, there was a
new proposal ( http://code.activestate.com/lists/python-ideas/32123/
), which could probably also be made to work for most uses, but of
course is also not implemented in any version of Python 3.


> 1) Breaking backwards compatibility: Python has had, for instance,
> class decorators since 2.6, which isn't even supported any more.  I
> don't have any interest in rewriting the frame-hacking for
> DecoratorTools.decorator_class() to make it work on Python 3, so I'd
> just refactor all the relevant code to use the built-in class
> decorators.

This isn't actually possible, anyway: you would not be able to define
generic function methods in a class body unless you added an explicit
metaclass or class decorator to the class, and rewrote the API or
dropped the feature.  (I guess I should say, it isn't possible while
retaining the features of class-level AddOns or of defining gf methods
in class bodies.)

> 2) Implicit relative imports: most of the packages are filled with lines
> like,
> from peak.utils.decorators import ...

Huh? that's an explicit absolute import, not an implicit relative one.
Maybe you mean the "from core import *" stuff.

> In Python 3, these don't work and the automatic conversion tools don't
> work on them.  They're responsible for most of the failures I'm seeing
> in the doctests.  I could probably get everything running using
> virtualenv and setuptools, but at that point I'm refactoring the entire
> package structure.  Breaking backwards compatibility by eliminating
> dependencies would help but not solve the problem entirely.

This actually mostly sounds like a problem with the way you're running
the doctests.


> At this point I'm stopping for now, primarily because I've changed the
> objective of the project I was planning on using PEAK-Rules for so it's
> no longer useful.  I didn't tackle any of the hard problems like
> rewriting ByteCodeAssembler.  My attempt is up at
> https://github.com/ceridwen/PEAK-Rules  If anyone
> needs a Python 3-compatible version of Extremes or SymbolType, or a
> mostly-compatible version of DecoratorTools, there they are.

If I were to drop compatibility with Python <2.6, BytecodeAssembler
and the most of the other ast stuff could be mostly replaced with the
Python 2.6+ "ast" module and the compile() builtin.  Such a thing
would be vastly easier to make work with 3.x, I imagine.  In practice,
I don't have time or interest at the moment sufficient to do it
myself.  Such a thing might be better off as a fork, anyway.