still doesn't build on pypy3 7.0

[glyph]

following up from #97:

Collecting git+https://github.com/python/typed_ast
  Cloning https://github.com/python/typed_ast to /private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-req-build-39y_vwx6
Building wheels for collected packages: typed-ast
  Running setup.py bdist_wheel for typed-ast ... error
  Complete output from command /Users/glyph/.virtualenvs/tmp-57d83c9d1ed6ccb/bin/pypy3 -u -c "import setuptools, tokenize;__file__='/private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-req-build-39y_vwx6/setup.py';f=getattr(tokenize, 'open', open)(__file__);code=f.read().replace('\r\n', '\n');f.close();exec(compile(code, __file__, 'exec'))" bdist_wheel -d /private/var/folders/5z/sbg483yj7031bkxcptzpyh5w0000gn/T/pip-wheel-sxm1s6jn --python-tag pp370:
  running bdist_wheel
  running build
  running build_py
  creating build
  creating build/lib.macosx-10.14-x86_64-3.6
  creating build/lib.macosx-10.14-x86_64-3.6/typed_ast
  copying typed_ast/conversions.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
  copying typed_ast/__init__.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
  copying typed_ast/ast3.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
  copying typed_ast/ast27.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast
  package init file 'ast3/tests/__init__.py' not found (or not a regular file)
  creating build/lib.macosx-10.14-x86_64-3.6/typed_ast/tests
  copying ast3/tests/test_basics.py -> build/lib.macosx-10.14-x86_64-3.6/typed_ast/tests
  running build_ext
  building '_ast27' extension
  creating build/temp.macosx-10.14-x86_64-3.6
  creating build/temp.macosx-10.14-x86_64-3.6/ast27
  creating build/temp.macosx-10.14-x86_64-3.6/ast27/Parser
  creating build/temp.macosx-10.14-x86_64-3.6/ast27/Python
  creating build/temp.macosx-10.14-x86_64-3.6/ast27/Custom
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/acceler.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/acceler.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/bitset.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/bitset.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/grammar.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/grammar.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/grammar1.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/grammar1.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/node.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/node.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/parser.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/parser.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/parsetok.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/parsetok.o
  gcc -pthread -arch x86_64 -DNDEBUG -O2 -fPIC -Iast27/Include -I/usr/local/Cellar/pypy3/7.0.0/libexec/include -c ast27/Parser/tokenizer.c -o build/temp.macosx-10.14-x86_64-3.6/ast27/Parser/tokenizer.o
  ast27/Parser/tokenizer.c:17:10: fatal error: 'codecs.h' file not found
  #include "codecs.h"
           ^~~~~~~~~~
  1 error generated.
  error: command 'gcc' failed with exit status 1

It looks like the inclusion of codecs.h was intended to be removed based on discussion on the previous issue?

[glyph]

(Same error with pypy3 7.1.1)

[ethanhs]

@glyph if you read my comment there are a lot of changes that would need to be made for typed_ast to work on PyPy (the changes in the comment are just the beginning). Deleting the codecs.h include is not really going to get you far. I gave up around the time I made that comment because I didn't feel life vendoring half of the CPython APIs we use. However, perhaps perhaps PyPy can have an internal parser flag that gets enabled from a typed_ast module, since it will be a while before they reach 3.8?

[glyph]

@ethanhs ah, I see. If it’s not worthwhile to have a tracking issue open for pypy compatibility, please feel free to close this; I was just trying to catalogue the failures I encountered trying to get pypy to work for a production codebase.

[gvanrossum]

Thanks, let’s close this then.

[h-vetinari]

Update for those subscribed here, re:

@ethanhs: However, perhaps perhaps PyPy can have an internal parser flag that gets enabled from a typed_ast module, since it will be a while before they reach 3.8?

typed_ast support in PyPy was implemented by @isidentical, see comment here:

PyPy 3.8 will have typed_ast support natively (just like CPython 3.8), !791 (merged).

PyPy 3.8 is on the horizon, but still likely several months (or more) away.

[ethanhs]

It seems that while type comment parsing is implemented, language feature versioning perhaps is not?

[isidentical]

feature_version is on the list of todos, and will probably get implemented before the release.

…

On Fri, Jul 2, 2021, 3:31 AM Ethan Smith ***@***.***> wrote: It seems that while type comment parsing is implemented, language feature versioning perhaps is not? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#111 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ALJKHQJNULWO7N234YBYNB3TVUCHXANCNFSM4HNQ5SQQ> .