Fail after install

[russel]

I pip installed pychapel into a newly created virtualenv, then rebuilt Chapel from Git master following the instructions fro readthedocs. Sadly then:

|> pych --check
Traceback (most recent call last):
File "/home/users/russel/PythonEnvironments/Fedora_Python3_PyChapel/bin/pych", line 9, in
from pych.version import APP_NAME, APP_VERSION
File "/home/users/russel/PythonEnvironments/Fedora_Python3_PyChapel/lib/python3.4/site-packages/pych/init.py", line 6, in
import pych.runtime
File "/home/users/russel/PythonEnvironments/Fedora_Python3_PyChapel/lib/python3.4/site-packages/pych/runtime.py", line 11, in
from pych.types import PychArray
File "/home/users/russel/PythonEnvironments/Fedora_Python3_PyChapel/lib/python3.4/site-packages/pych/types.py", line 35, in
long: ctypes.c_long,
NameError: name 'long' is not defined

[lydia-duncan]

Hi Russel: Thanks for your interest! I will start looking into this issue right away and let you know my progress

[lydia-duncan]

It turns out that Python 3 does not support long or unicode as types, and the string type has been renamed. I will now look into getting both Python 2 and Python 3 to work (Python 2 is fine)

[lydia-duncan]

This may take some time, so in the meanwhile, I would suggest using Python 2 (if that works for you)

[russel]

Python 3 has indeed removed the int/long distinction, there is only the int type and switching between hardware and software integers is left to the PVM. The Unicode literal type was re-added in Python 3.3 exactly to help the Python 2 → Python 3 conversion. Apart from PyPy3, I think everyone is on Python 3.3 or 3.4 if they are not stuck with 2.6 or 2.7. String type is still called str in Python 3 I believe.

If you want me to give a hand with this, I can grab the repository and take a look.

[lydia-duncan]

I was compiling with Python 3.4 and 'unicode' caused a name error, too, which was why I went looking for what happened to it - the stackoverflow question on the subject says that 'Python 3 renamed the unicode type to str, the old str type has been replaced by bytes' (http://stackoverflow.com/questions/19877306/nameerror-global-name-unicode-is-not-defined-in-python-3).

You are more than welcome to help (after signing a contributor's agreement for any code you send back, found at https://github.com/chapel-lang/chapel/tree/master/doc/developer/contributorAgreements), but I suspect the work will be fairly uninteresting. I'm not sure of the amount of code that will need to adjust. I did find a resource of idioms to look for/use (http://python-future.org/compatible_idioms.html) and I suspect there are more than it covers so if you know of additional ones, I'd definitely appreciate hearing about them!

[russel]

Ah, sorry: yes, strings are ASCII sequences in Python 2 and so indistinguishable from byte sequences, whereas in Python 3 strings are sequences of Unicode code points with an encoding (the sane encoding is UTF-8). The bytes type really comes into its own for IPC and networking!

The core question here is whether you want a single code base that works with Python 2 and Python 3 or whether having two code bases is acceptable. Of course it is possible to have lots of shared Python 2/Python 3 compliant code with bit of version specific code to avoid some hassles, using Git features.

I will clone the repository and assess the situation.

[lydia-duncan]

I think from a maintenance perspective we'd prefer to have a single code base - there's a lot of work that still needs to be done on pyChapel and it'd be really nice to only have to do it once instead of mirroring it across the two.

[russel]

What is the base version of Python 2 you will go with. Clearly I will suggest 2.7.10, but…

[lydia-duncan]

Yeah, we're using 2.6.9 over here, but we'd obviously like it to be able to work with 2.7 as well . . .

[russel]

Are you using Scientific Linux? Is there some reason you cannot update to Python 3? Or at least 2.7.10? Does this imply we have to use 2.6 as the base version for the Python code?

[lydia-duncan]

We're using SUSE. I'll investigate whether (and how quickly) we can update to Python 3, but for now we should assume 2.6 as the base version.

We want to be relevant to the Python community, so if it seems like Python 2 is gradually getting deprecated then we will need to update for sure - I know that's the intention overall but it seems like we've lived in a Python 2 and Python 3 world for a while now, so as someone without a finger to the pulse of the Python community we don't have a good notion of when that will change. The reason pyChapel was initially written in 2.7 was familiarity on the part of the implementer, and because our machines had 2.6 installed we needed to make sure that worked as well.

[russel]

Whilst I believe everyone should use 3.4 or later, there are some using 2.7, and indeed 2.6, who are unable to change quickly – though they only have until 2020 to actually change. So for wide usage it makes sense for PyChapel (just like SCons) to support 2.7 and 3.3+ with a single codebase for the short and medium term. SCons has chosen to not support 2.6 since supporting only 2.7 with 3.3+ is so, so much easier. There are various features techniques and tricks for doing this: use of future and six being the main ones. I can take a look at trying to make it all work with 2.7 and 3.4, but I am loathe to install 2.6 unless it is absolutely necessary.