Ensure Travis runs intended Java versions 8 & 11 on macOS by solving
problems related to homebrew. Install java 11 for Windows. Builds on
work by cclauss in jythonGH-35.

Tweak build.xml to exclude more flakey tests. Update test_subprocess.py
at test_no_leaking so that we can see why it ought to be skipped in
Jython (saving us the longest test in the whole suite).

This change begins a shift to a "plain Java objects" approach to the
data model. We provide PyType and Operations classes, the marker
interfaces and a base Python object implementation. The elaborate Slots
enum describes a system of handles for special functions used by the
run-time. Other classes, although numerous, are present to support these
and errors they raise.

There is a unit test that exercises creation and lookup of each broad
sub-class of Operations object.

Move these Jython 2 source files unmodified to the Jython 3 source tree,
preparatory to conversion for Jython 3. (Accept the build fails.)

As a rule, each committed state should build without error. As an
exception, we commit pure file moves from 2 to 3 to provide an
unambiguous pedigree to git (and code archaeologists).

The changes to convert PyLong from 2 to 3 are large. Formatting code in
stringlib can be re-used with relatively minor changes. This change set
also brings in new classes for exceptions, and stubs for certain core
classes to satisfy dependencies.

We preserve legacy annotations in PyLong as comments so that the git
diff can align the old and new implementations of corresponding methods.

We will use Python to generate some of our code, and it has to be a 3.8.
We adjust the Travis CI build to support that, and insert a gratuitous
use of Python as a test.

bool provides a simple case of inheritance but it is rather a special
one since Java Boolean is its canonical implementation. We extend the
Operations formation test to bool and int.

Allow code to be wide, but keep comments at a readable width. This aids
comparison with the VSJ original, while we need it.

We provide an exposure mechanism sufficient to populate the dictionary
of the type object for any built-in, and from that the slots of
Operations objects. We apply this to int and bool.

We test that we can invoke a few unary special methods for int and bool.

The refactoring extracts common code between the unary and binary tests
(and later ones to be developed). The testing is at the level of
descriptors: we are not yet caching these as method handles in the
Operations object, although much of the code is present.

This change adds the code to Slot.java that causes the slots of
Operations objects to be filled with handles to implementation methods.
The unary and binary slot wrapper tests are extended to invoke these
slots and test the result against the same criteria as for the
corresponding descriptor.

This change imports Java code generation in Python and applies it to the
repetitive task of creating a version of each PyLong method specialised
for the class 'self'. Implementations inherited from Jython 2, still
present for now, are ignored where a class-specific duplicate exists.

These are evolved versions of the Jython 2 code, moved to PyLongMethods,
and called from generated wrappers. These operations are not simply
invocations of the Java counterparts but quite complex, so we add a
specific test.

Slots are added to Slot and OPerations based on CPython slots and how
Jython works. Many of these are unused, but where they match methods in
the ported PyLong, the signature will be validated. Since documentation
is a focus, this change also fixes the javadoc so it builds cleanly.

Many of the special methods were already in the generated PyLongMethods,
but now we remove them absolutely from PyLong. We add tests that call a
few of them, to prove this works.

We implement __(r)pow__ and the __*shift__ methods as hand-crafted
additions to PyLongMethods, rather than generating them, as they are
irregular.

We reproduce on the new code the style of copyright notice found
elsewhere in Jython, with the addition of "Licensed to PSF ...",
requested in the  contributor agreement we all signed.

The copyright label is probably not necessary, but we follow precedent.

This move, without fixing the inconsistencies, is our way of providing a
trace to the earlier work.

The text of PyFloat.java (moved in the last change) is corrected for the
new context and approach to exposing special methods (slots). We
introduce PyFloat.py to generate many of those operations, and enhance
the tests to demonstrate the mechanism for invoking them.

We introduce a rigorous unit test and careful implementations. Just
calling Java for these (with a trap for division by zero) doesn't reach
all these corners.

Note that the Python regression tests do not exercise cases involving
inf and nan seen here, so a simpler implementation may be conformant.

At this stage, running on one host type is enough of a check. It should run on pushes to main and PRs, wherever the workflow itself exists (only the Jython 3.8 development main branch). (PR jython#134)

We move Jython 2 PyTuple, PySequence and PySlice into the new project
core, unmodified to ensure the trace is clear in git to the previous
work.

Merging from main to fix Python version

Implements descriptors for attributes and members of built-in types, exposed by annotations and the type construction process.

PyJavaMethod represents bound and unbound *methods* (name
'builtin_function_or_method'). CPython calls the same idea PyCFunction.
PEP 573 introduces a PyCMethod (name 'builtin_method') for methods of
types in modules.

It's going to be confusing if we don't go with PyJavaFunction.

Port the basic apparatus of modules defined in Java from VSJ and a test.
Rationalise ArgParser to eliminate a legacy constructor.

As a result we find and fix a bug and some inefficiencies in
PyJavaFunction calls.

Separate extension module initialisation into create and exec phases,
roughly as PEP 489.

We implement a few built-in functions and object references, and a unit
test of the functions. The Interpreter now makes itself an instance of
the module so that it is available to the frame.

With a few adjustments to the interpreter frame and the function object,
we show that we can access the contents of the builtins module as we
interpret CPython byte code.

Disassembled byte code sits alongside the compiled code so we can see
what we're interpreting.

We add simple examples to exercise them. This discovers a bug in
list.__setitem__ (actually PyList.Delegate.setItem) which we fix. We add
a PyList constructor from stack slices. (Other PyList change is
trivial.)

We access existing comparison implementations from CPython byte code.
This allows us to provide examples of if-else and while loops. We fix a
minor bug this revealed in PyUnicode.

 Means to expose functions from modules.

Merge in changes associated with adding a builtins module. The
difference for the conditionals is in the tests, where we now create an
interpreter explicitly.

Flow control and conditional branching opcodes

We also compile the examples with Python 3.11. As the changes to the
interpreter so far are simply name changes we disable the CPython
interpreter tests.

We update framework and implementation classes that we need for
execution of 3.11 byte code. The main affected classes are PyCode,
PyFrame and PyFunction, and their implementations for CPython byte code.

PyFunction is added because in 3.11 all frames have a function object,
even a top level module. Other changes are just supporting methods and
tweaks.

Opcodes are not implemented yet, so we can't run code, but we can load
it.

We re-enable a batch of tests in CPython311CodeTest and implement the
opcodes they need in eval(). A number of object and utility classes have
to up their game in support.

Intended to support a proposed process for publishing documentation.