|
Size: 948
Comment:
|
Size: 2242
Comment: curses works now on py3
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| #pragma section-numbers 2 |
|
| Line 3: | Line 5: |
| This is a status page for keeping track of what needs to be done to make progress on Mercurial on Python 3. Nobody is actively working on this - AugieFackler works on it sporadically, and would be happy to see patches on this topic flagged with Py3 on the mailing list. | = Python 3 = This is a status page for keeping track of what needs to be done to make progress on Mercurial on Python 3. Our current aim is to support Python 3.5+. <<TableOfContents>> == Status == We have been testing by installing default mercurial on our system using Python 3. Most of the things work correctly. Things which don't work can be found at BetaBugs section below. We are planning to mark hg 5.0 which is scheduled for May 1 as Python 3 beta release. If you are an extension author and want to port the extension, [[https://www.mercurial-scm.org/repo/hg-committed/file/tip/mercurial/pycompat.py||pycompat.py]] contains most of our compatibility hacks. If you need help or guidance, you can message on IRC or devel mailing list. We will be happy to help you. |
| Line 6: | Line 20: |
| The most significant problem at the moment is some lingering cyclic imports in the codebase: | == Things need to be investigated == |
| Line 8: | Line 22: |
| ==== cmdutil -> subrepo -> cmdutil ==== The easiest fix for this would be to move hgsubrepo to a new file, and then fix the registration mechanism to be dependency injected somehow. ==== mercurial.repoview -> mercurial.revset -> mercurial.repoview ==== |
* Windows encoding changes https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8 * Lazy importer performance overhead. Our custom importer on Python 2 always returns a stub module during ``import``. Python 3's does I/O to verify the module exists then returns a lazy module that is loaded when first accessed. In addition to behavior differences, the I/O may contribute sufficient performance overhead to constitute a problem. * A mechanism for extensions to advertise that they are Python 3 compatible. Nearly every extension will break in Python 3. We may want a mechanism that requires extensions to self-declare that they are Python 3 compatible - possibly via special syntax in their source code or the presence of a well-named variable. It might have to be at the source level because Python 3 would need to evaluate code in order to obtain the value of a module-level variable. |
| Line 15: | Line 28: |
| ==== mercurial.fileset -> mercurial.merge -> mercurial.subrepo -> mercurial.match -> mercurial.fileset ==== If hgsubrepo moved out of subrepo, this would also be resolve.d |
== Beta bugs == |
| Line 18: | Line 30: |
| Following are things which don't work right now: | |
| Line 19: | Line 32: |
| ==== mercurial.filemerge -> mercurial.match -> mercurial.fileset -> mercurial.merge -> mercurial.filemerge ==== | * ~1% of tests fail * phabricator extension * out of core extensions * [[https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8|Windows filesystem encoding]] If you find anything apart from this not working, definitely go ahead and edit this page and we will fix it. ---- CategoryAudit |
Note:
This page is primarily intended for developers of Mercurial.
Python 3
This is a status page for keeping track of what needs to be done to make progress on Mercurial on Python 3. Our current aim is to support Python 3.5+.
1. Status
We have been testing by installing default mercurial on our system using Python 3. Most of the things work correctly. Things which don't work can be found at BetaBugs section below.
We are planning to mark hg 5.0 which is scheduled for May 1 as Python 3 beta release.
If you are an extension author and want to port the extension, https://www.mercurial-scm.org/repo/hg-committed/file/tip/mercurial/pycompat.py contains most of our compatibility hacks. If you need help or guidance, you can message on IRC or devel mailing list. We will be happy to help you.
2. Things need to be investigated
- Windows encoding changes
https://docs.python.org/3/whatsnew/3.6.html#pep-529-change-windows-filesystem-encoding-to-utf-8
Lazy importer performance overhead. Our custom importer on Python 2 always returns a stub module during import. Python 3's does I/O to verify the module exists then returns a lazy module that is loaded when first accessed. In addition to behavior differences, the I/O may contribute sufficient performance overhead to constitute a problem.
- A mechanism for extensions to advertise that they are Python 3 compatible. Nearly every extension will break in Python 3. We may want a mechanism that requires extensions to self-declare that they are Python 3 compatible - possibly via special syntax in their source code or the presence of a well-named variable. It might have to be at the source level because Python 3 would need to evaluate code in order to obtain the value of a module-level variable.
3. Beta bugs
Following are things which don't work right now:
- ~1% of tests fail
- phabricator extension
- out of core extensions
If you find anything apart from this not working, definitely go ahead and edit this page and we will fix it.