Python 3 AMUSE: dependence on 2to3? about amuse HOT 16 CLOSED

I have little experience with using python 3; I think Arjen should be able to answer this

from amuse.

It's not only print statements but also other python 2 specific syntax that needs to be translated for python 3. So all python files are processed with 2to3

from amuse.

Wouldn't it be possible to translate the code to python3, and keep compatibility with python2 using

from __future__ import print_function, other_python3_things

?

from amuse.

possible yes;-) but there are other priorities...I think first we should have a AMUSE configure and build with python 3 and tests running reliably and covering the same things as for v2.7; unification of the install and (binary) build scripts for v3 and 2.7 and probably a couple of other issues...

from amuse.

from amuse.

good point;-) btw are you aware of the buildbot??

from amuse.

Which one are you using?

from amuse.

Would it be a good idea to gradually process all files with 2to3, and re-commit those rewritten files (probably after checking, and definitely after adding from __future__ import X)?
Or is there a reason not to do this?

from amuse.

its a bit messy, and can cause confusion if you are making edits/ debugging files that have seperate conventions, so I don't think its a good idea. It would also be pretty annoying to go through the edits if you have different branches e.g. when merging one way or the other). And it wouldn't solve the current issues with the python 3....

from amuse.

what are the other python3 problems?
I guess the confusion can be avoided by doing the conversion on an interface-by-interface basis.
As for conventions, AMUSE isn't exactly using a standard (e.g. PEP8) as is...

from amuse.

I think not all tests are passing (atm I cannot see p3 version is feature complete, but maybe I am mistaken)...I was not talking about the style conventions;-), more like practical things like debugging across files with different print etc..in any case these are my concerns...

from amuse.

ah, ok. Would be good to discuss this stuff at some point, may be useful to let the community help with the transition to py3 amuse. I currently don't know what needs doing, but would be very willing to help...

from amuse.

Would it be a good idea to gradually process all files with 2to3, and re-commit those rewritten files

This wouldn't be backwards compatible with Python 2, even with from __future__ statements, since various stdlib modules have also been renamed.

As an example, I have (manually(*)) consolidated the support/ and support3/ modules into a single Python-3-with-2-backwards-compatibility codebase. Hopefully, these changes are not too drastic, though some of the imports have to be paid attention to if people are other imports.

With that in mind, I wouldn't mind stepping through some of the code Python files, making just the necessary changes to have those files Python 2 & 3 compatible, since this could incredible help with #256 . (Note that suggestion above about first getting a single flow for Python 2 and 3 properly instead, may be harder without doing this 2-3-compatibility conversion first.)

(*) Futurize, Modernize or six can help here, though I generally find it clearer to do this manually: these packages add extras that aren't always that clear. It does make Py2/3 code more consistent, though.

from amuse.

If you do this, you get a not python 2 and also not python 3 codebase. Although we have a lot of tests and can probably make it work, it will have even more edge cases and subtle problems than using 2to3. This is OK for the support directory which is small and has a very specific usage pattern, it is not for the whole codebase.

So yes to fixing code where the 2to3 code has problems (this has turned out to be problematic/ambiguous to understand code) but no to a kind of frankenstein hybrid.

Also, please, no use of the futurize, modernize and six modules.

from amuse.

Let's make an inventory of all the things that 2to3 changes, and if we can solve these sufficiently to not require this step anymore.

from amuse.

This is better covered by individual issues - closed.

from amuse.