GeezerVisonThe World Wide Web, restored to 800 pixels of glory. | ||||
| Home|About|Gaming cabinet|Archives|How it works|Starter sites | ||||
GeezerVison is showing github.com — Fix problems with import and zipimport in particular by jeff5 · Pull Request #31 · jython/jython3 Conversation
|
|
Not sure the exact bit of code that you are talking about, but sounds like a job for *args ? |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
This cures the constructor-related exception on attempts at importing modules, but there are still problems with PyZipImporter. Also improved some comments.
|
@stuaxo When I write This stuff is an example of how Jython makes Python objects. It's clever, and not terribly well explained anywhere, but the best explanation I know is here: https://wiki.python.org/jython/PythonTypesInJava. The problem referred to is that However, this doesn't suddenly make Jython 3 work, so there's more to find. |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
We use java.nio.Path extensively to achieve platform independence and to support (and preserve) relative paths exactly as CPython does. Because Jython does not yet work well enough to run standard unit tests, we start a thorough Java-based test.
There was an error while loading. Please reload this page.
|
Getting quite nice conformance now with CPython as far as construction of a zipimporter goes: We copy CPython, which does not have absolute file paths in the _files cache. Use of relative paths has generally been problematic in Jython, although it's what CPython does extensively. We have our own idea of the current directory, and some complex path manipulation using it, because it seemed Java would not pay attention to the changed value of the current working directory in property |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
The test expresses the behaviour of get_data in CPython 3.5.2, and fails in every call at present (on Windows), so is disabled in the unit test.
Also re-named some local members. The objective is (only) to be clear about the specification of the methods, how it works internally. Un-expose some methods that do not have CPython counterparts. All preparatory to systematic tests.
Test against careful observation of equivalent behaviour in CPython, when a .py file name should be returned and when a .class.
|
There are many more things I'd like to change in |
Sorry, something went wrong.
There was an error while loading. Please reload this page.
There was an error while loading. Please reload this page.
Successfully merging this pull request may close these issues.
There was an error while loading. Please reload this page.