You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm convinced we benefit by re-using the CPython guide, but the idea was to track change by pulling in CPython changes as we go along. In practice, this doesn't happen, and when a backlog has built up, the merge looks scary.
Chapters are files. There are three cases to consider:
A file is the same in Jython as in CPython (yay!).
A file has a small number of differences in Jython's copy from CPython's. One might be able to have a file of the same name and merge the changes.
A file differs a lot. Jython needs its own version entirely. (Include here chapters we drop and chapters we add.)
In practice, 2. is where the problem lies, as it's always more important to make a specific change than keep up.
The text was updated successfully, but these errors were encountered:
A problem observed with category 3. is as follows. Where there is a "completely different" version of an existing CPython chapter (e.g. runtests_jy.rst replaces runtests.rst) there remains a lot of cross-referencing under the old name (or labels defined in the original). This leads readers into trouble.
It is better not to have both versions around, and to re-use labels (where they mean the same), or invalidate them (which alerts us to dangling references through an error). Corresponding chapters then have the same file name.
I'm convinced we benefit by re-using the CPython guide, but the idea was to track change by pulling in CPython changes as we go along. In practice, this doesn't happen, and when a backlog has built up, the merge looks scary.
Chapters are files. There are three cases to consider:
In practice, 2. is where the problem lies, as it's always more important to make a specific change than keep up.
The text was updated successfully, but these errors were encountered: