10000 Jython 3 MVP and Roadmap by jeff5 · Pull Request #21 · jython/jython.github.io · GitHub
[go: up one dir, main page]
Skip to content

Jython 3 MVP and Roadmap #21

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Oct 24, 2020
Merged

Jython 3 MVP and Roadmap #21

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
5 commits
Select commit Hold shift + click to select a range
e04bd52
Jython 3 MVP and approach (new page)
jeff5 Aug 29, 2020
11fd705
Fix typos and clarify certain proposals.
jeff5 Aug 29, 2020
7afd793
Split material into Features and Roadmap,
jeff5 Sep 5, 2020
f774354
Minor typos and clarity (roadmap).
jeff5 Sep 5, 2020
40778fb
Bug fixes and addition from review
jeff5 Sep 6, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
Next Next commit
Split material into Features and Roadmap, 
Make a serious attempt at a roadmap.
  • Loading branch information
@jeff5
jeff5 committed Sep 5, 2020
commit 7afd793934e1c0068ff6cfb629a312a677d65112
4 changes: 4 additions & 0 deletions .gitignore
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,3 +27,7 @@ gh-pages/
pkg/
test/dest
tmp/*
scraps/

# IDE droppings
.idea/
8 changes: 6 additions & 2 deletions _data/navbar.yml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -33,8 +33,12 @@ navbar:
url: https://sourceforge.net/p/jython/mailman/
- title: Developer Guide
url: https://jython-devguide.readthedocs.io/en/latest/
- title: Jython 3 MVP
url: jython-3-mvp
- title: Jython 3
subItems:
- title Features (MVP)
url: jython-3-mvp
- title Roadmap
url: jython-3-roadmap
- title: Website source
url: https://github.com/jython/jython.github.io/
- title: Links
Expand Down
99 changes: 17 additions & 82 deletions jython-3-mvp.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,7 +1,7 @@
---
title: Jython 3 MVP
title: Jython 3 Features and MVP
---
# Minimum Viable Jython 3
# Jython 3 Features and a Viable Minimum

This is a discussion document that attempts to describe,
and to some extent prioritise,
Expand Down Expand Up @@ -186,6 +186,10 @@ Have we enough understanding to avoid unintentionally making it difficult?
* There will be blood.
* Risk: much existing guidance invalidated (Jython Book).

* Clear semantics for `import` from Java
* Semantics in Jython 2 have repeatedly changed.
* `import` as written tries the same thing repeatedly


## Implementation and API Features

Expand Down Expand Up @@ -214,88 +218,19 @@ became public API, just to cross our own package boundaries.)
* MVP: Clear relationships amongst interpreter, system state and
thread state. (At least the interpreter and its semantics are API.)

* Adopt or write a higher proportion of modules in Python vs Java,
than is the case in Jython 2.
(Decent but not high performance interpreter is a pre-requisite.)
* Only performance-critical modules are hand-crafted in Java.
* Modules that take advantage of Java libraries call them from Python.
* Enthusiasm for writing in Java should be directed to re-implementing
popular libraries that broaden Jython use (`numpy`, etc.).

* Use fewer external JARs than in Jython 2.
* Purpose of each JAR should be documented in the build.
* Avoid libraries that circumvent the JVM:
* Incompatibility in dealing strings and i/o has been expensive.
* Many bugs related to `jnr.posix`. (Replace with `java.nio.file`?)
* Carefully consider what `os.*` methods we offer and their semantics.
* Reconsider `jnr.jffi`. (Remove related `ctypes` support.)

* Use the dynamic language features (at last) starting with `MethodHandle`.
* A core implementation closer to modern CPython.
* MVP: `MethodHandle` used to fill type slots (concept proven).
* When compiling to JVM byte code, create call sites using the same
or a related `MethodHandle`.

* Use a PEG parser following GvR's lead.
* Gives us a lot for free (but not a whole compiler).
* MVP: Still need a Lexer. (ANTLR?)
* MVP: Generate the AST classes from ASDL. (Python or ANTLR?)
* MVP: Compiler from AST to Python byte code. (Available in Python?)
* Compiler from AST to Java byte code. (Ours to write/update.)

* Use the six module during development with a view to ensuring our
users can migrate using it. (Suggestion needs exploration.)


## Build environment
## Jython 2 Features not to Reproduce

All this feels like MVP in order to maintain acceptable quality.

* The project is homed at GitHub, where 3.8 is a branch.

* We follow CPython processes
* Jython Devguide should reflect these processes
* Accepting integrations like as miss-islington may not be available.

* Build with Gradle
* multi-project, e.g.: `core`, `compiler`, `lib`, `apps` sub-projects.
* composite project, with (say) `tools` for our build-time use only.

* Test at multiple layers routinely
* JUnit tests for core elements in isolation (per build/commit).
* `regrtest` test of integrated interpreter (before commit).
* Test parsing at the REPL simulated somehow (before merge).
* This is a shared need with CPython.
* Test what the user actually installs: JAR and application (before merge).
* Test typical user integrations (before merge).
* **Not:** Java `List` and `Map` implicitly Python `list` and `map`.
* This is a tempting feature and it almost works,
but involves complex guesswork.
* Propose a brief way to be explicit instead.

* **Not:** Java package cache.
* The location of this is problematic for users.
* It has been the subject of a CVE and follow-up bug.
* If there is evidence it significantly improves performance,
without being a security issue,
a reworked version could be added to 3.

## Some roads proposed not to taken

* **Not:** Java `List` and `Map` implicitly Python `list` and `map`.
This is a tempting feature and it almost works,
but involves complex guesswork.
We need a brief way to be explicit instead.

* **Not:** Build to the above specification directly on the `jython/jython3`
repo.
* It reproduced the Jython 2 object model. We'd like to move on.
* It has never pulled any bug-fixes from the trunk,
and we judge the merge to be too difficult.
* It is desirable to acknowledge the work somehow, and to pull in some
content, perhaps converted modules, if this is efficient.
* We should make clear on `jython/Jython3` that it is not Jython 3.
* Reports of project death continually appear there.
* They are of course greatly exaggerated.

* **Not:** Bend the use of Gradle to a file structure conceived for Ant.
* The existing Gradle build works this way and it was *hard work*.
* Git is capable of tracing the ancestry of files that have moved.

* **Not:** Start from scratch.
* The Jython 2 code base contains a huge amount:
* solutions to problems we haven't even recognised in Jython 3.
* design choices (although mostly free of rationale).
* We'd like to trace our history back to early contributors.
* Downside: for an appreciable time, we shall have legacy code
in `/src` that is waiting to be incorporated.
Loading
0