Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix non-byteplay code in commit 8833ef... to support both Python 2 and Python 3 #5

Open
peterazmanov opened this issue Nov 17, 2015 · 5 comments
Labels

Comments

@peterazmanov
Copy link
Owner

8833ef2

@peterazmanov peterazmanov added this to the Python 3 support milestone Nov 17, 2015
@peterazmanov peterazmanov changed the title Fix non-byteplay code in commit 8833ef24346b49a65a20ba5a5d652ea9512c63de to support both Python 2 and Python 3 Fix non-byteplay code in commit 8833ef... to support both Python 2 and Python 3 Nov 17, 2015
@MatthieuDartiailh
Copy link

Do you have any ideas on how to do that ?

@peterazmanov
Copy link
Owner Author

If I remember correctly this part of changes is related to WIP-changes in parser.

I think the easiest way to go is to support enaml-syntax version the same as that of the package. I believe the amount of enaml code out there isn't that big, so if one wants to move to Python 3 it won't be a problem to convert enaml code too.

As of the way to achieve this. parser.py defines the syntax, so we can't implement support of both Python versions in one file. So basically one should take old version and name it for example _parser2.py, name new version _parser3.py and choose which module to import in parser.py based on Python version. Maybe there is more elegant way...

@MatthieuDartiailh
Copy link

I will have to look at both versions but one way to make things easier to maintain may be to write the parser as a class (possible in pyparsing). This way we can have a base class handling common patterns and add more cases in a Python2 and Python3 subclasses. I will look into both and see what amount of code is duplicated to see whether or not this is pertinent.

@peterazmanov
Copy link
Owner Author

Currently there is quite a large amount of common code, but it won't be the case when full Python 3 grammar would be supported. In source of Python there is explicit grammar of the language, and I suspect it was the source for original version of parser.py. You can compare grammars of different Python versions to estimate the amount of common grammar rules, which as I understand you consider putting in base class.

@MatthieuDartiailh
Copy link

Thanks for the pointer. I will give it a look.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants