Convert Python 2 to 3 using Futurize Conservatively #5
Conversation
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
Signed-off-by: Dan Yeaw <dan@yeaw.me>
| @@ -20,12 +20,13 @@ | |||
|
|
|||
|
|
|||
| from __future__ import absolute_import | |||
| from builtins import object | |||
There was a problem hiding this comment.
Why are you explicitly importing from the builtins module?
There was a problem hiding this comment.
Futurize backported 18 builtins from Python 3 to Python 2. If someone is running with Py3, it has no effect, but with Py2 it pulls in the Py3 backported versions. This is actually one of the strengths of this approach that it provides this extra "future" module with these builtins.
The other main option is called python-modernize which converts Py2 code into a common subset of Python 2 and 3, with six as a run-time dependency, futurize converts Py2 code into (almost) standard Py3 code, with future as a run-time dependency.
Because future provides more backported Py3 behaviours, the code resulting from futurize is more likely to work identically on both Py3 and Py2 with less additional manual porting effort. The disadvantages is that well I guess we pollute the namespace slightly, and that future only support Python 2.6, 2.7, and 3.3+. Six supports more backwards compatibility, but 2.6 is already end of life, and 2.7 will be soon.
I tried python-modernize first, and I think python-future is really a nice way to go.
For more information, here is the python-future explanation.
|
@amolenaar and @dieterv, any thoughts? Are you still interested in maintaining etk.docking? Are there concerns with my PR? |
|
Apart from my question it looks good. |
|
@amolenaar Excellent, did you see my response? |
|
@dieterv, @danyeaw It may be an idea to move this code inside the Gaphor repo, or at least move it to the Gaphor organization. @danyeaw This lib relies heavily on the X-Window DND functionality, via the GDK library. With hindsight this was not the best option. If it is possible to implement a custom (in-app) protocol, that would be way better for portability and usability. |
| @@ -0,0 +1,9 @@ | |||
| # Install | |||
| simplegeneric | |||
There was a problem hiding this comment.
I think future should be added as a dependency as well.
There was a problem hiding this comment.
I hadd to tweak the examples in docs/examples a little, due to the new naming of the toplevel package (etkdocking), but it works just fine.
|
@amolenaar @dieterv I agree that transferring it to the Gaphor organization would help maintain the project and better streamline the updates we need. @amolenaar Agreed that this isn't ideal. Do you think it would be better to remove dependence on these lower level APIs prior to trying to upgrade Gaphor to PyGObject? |
|
@danyeaw In a previous attempt to port gaphor to gtk3 I ran into trouble with DnD. I was missing some apis. It may be better to create some shortcuts in order to get stuff workibg faster. |
|
@amolenaar Do you have any guidance on an approach? Should I try to rip out all of etkdocking prior to updating Gaphor to use PyGObject? Should I just try to just replace the DND functionality? |
This PR takes a conservative approach and only adds Python 3 compatibility using the futurize library. I was also not able to get etk.docking to work with Python 2.7 based on namespace collision caused by the period in the name, so I refactored the project in to a more standard (for today) project structure.