Failed to import some python std libs(e.g. json) in python code and then called in go code

[corona10]

Issue from https://github.com/google/grumpy/issues/408

def feature1(inputJsonString):
    print inputJsonString
    import json
    import sys
    print json.dumps(1)
    return sys.version

feature1({'s': 3})

Expected:

{'s': 3}
1

Got:

{'s': 3}
Traceback (most recent call last):
  File "/Users/grumpy.git/__main__.py", line 8, in <module>
  File "/Users/grumpy.git/__main__.py", line 3, in feature1
  File "/Users/grumpy.git/grumpy-runtime-src/build/src/__python__/json/__init__.py", line 110, in <module>
  File "/Users/grumpy.git/grumpy-runtime-src/build/src/__python__/json/decoder.py", line 25, in <module>
  File "/Users/grumpy.git/grumpy-runtime-src/build/src/__python__/json/decoder.py", line 23, in _floatconstants
TypeError: bad operand type for unary -: 'tuple'
exit status 1

[alanjds]

I made a fix too, but forgot to push for review: https://github.com/alanjds/grumpy/tree/fix-jsondecode

The CPython blame says that it is better to get from float('-inf'), available since CPython 2.6 . But the json/decoder.py was updated only on 3.4 .

The real issue here, besides old CPython code, is about tuple unpacking on assignments.

[corona10]

@alanjds Yes, your solution also fixes this issue. Since CPython 2.7 still uses struct unpack we should maintain (https://github.com/python/cpython/blob/2bea7716093012319b5e6a4260fe802b15031f21/Lib/json/decoder.py#L18)

I think that we should use CPython 2.7 code. We can switch them when we support Python3.

WDYT?

[corona10]

If we are importing any Python standard library related code in the future, we should use the CPython 2.7 code. I think it guarantees compatibility with CPython 2.7.

[alanjds]

I am not that sure. Usually, 3.X code are supersets of 2.7 ones, including all previous functionality.

tempfile, for example, is the same plus TemporaryFile. glob.glob is the same, but supporting recursion to subdirectories.

Beside deprecations, I think it's better to use the newest code available, if compatible. Will inherit bugfixes, enhancements and got easier to bring support for Python 3.

Why not providing the new features, if compatible?

[alanjds]

Btw, I merged your PR #5

[alanjds]

For sure Python2 compatibility will come before Python3, but maybe one can be not "against" the other.

@corona10 WDYT about targeting both pythons?

[corona10]

@alanjds

Most of the compatible compiler use same code of origin stdlib. PyPy2, Jython2, IronPython, Pyston when they target Python2, they only use Python2 codes.

I don't think using a mixture code of Python2/3 is the proper way to develop a compatible compiler. (Only means when we use stdlib code)

[corona10]

We can use Python3 grammar when we meet an unavoidable situation, but it means that grumpy doesn't fully support the python2 feature.

[corona10]

We can support Python 3 when we target python3, but now it looks not easy since they are still growing.

One of the good points of grumpy is that we can promote this project who want to archive their Python2 code into Go code. (If they just maintain it and does not want to port into Python3)

So, I suggest that we should focus on fully supporting Python2 which is not also the easy job.

[alanjds]

Ok. You may be right.

I am clearly biased because people around me always (this week included) ask for Py3 support. And I am developing for Py3 only on my daily job already.

Just feel sad to build Py2 compat instead of Py2 and Py3 at same time when possible. Seems a waste of time.

But this can be an illusion of my biased sight anyway.