Reduce type hinting in Python

[elisbyberi]

I believe that we should reduce type hinting usage in order to be able to maintain Python and Codon simultaneously, using a single code base. From Codon docs: "Codon emulates Python's lax runtime type checking using a technique known as monomorphization [without compromising execution speed]."

This library is nearly compatible with Codon.

Example In Python, we can emit the Type[Element] type hint, and in Codon we can emit type statement (since Codon classes are types). We can replace line below with element_factory = Element,: https://github.com/imgurbot12/codon-xml/blob/4ae976bb4a7f997e7eb9a45c4903da4b674b52f2/xml/builder.py#L18

[imgurbot12]

Fair enough. Are there any typehints I should avoid aside from the Type[] annotation? I can remove them for the next commit.

[elisbyberi]

There are other type hints that are incompatible between Python and Codon, and I will be listing them in the Readme.md to ensure that any changes to Codon typing are tracked.

As the library continues to develop, I will be making minor changes to the type hinting in a way that does not break existing code.

I suggest keeping this issue open to track the process of reducing type hinting.

[imgurbot12]

Sure. Sounds good. Thanks.

[elisbyberi]

I noticed that you are using Python typing extensively, but it might be easier if you complete the Python version without any type hinting first. Currently, it seems to be causing circular importing issues: #4. My suggestion would be to remove type hinting altogether initially and then we can make the library compatible with Codon by adding type hinting only where necessary.

If you plan on removing type hinting, you may want to reject or delete #3.

[imgurbot12]

Worth considering. I'd be willing to try that in another branch at least and see if it makes things easier.

[imgurbot12]

@elisbyberi I had another error come up I'm not sure how to resolve. I'm working on a version without as many type hints but I'm getting an import error from within the xpath sublibrary:

lexer.codon:6:8-17: error: no module named '.._tokenize'

is there no way to import using dots like in standard python?

[elisbyberi]

@imgurbot12 The setup provided in codon_xml.zip works in Codon but not in Python. It is important to note that the lexer needs to be imported in xpath for it to work properly.

The _tokenize module is utilized exclusively by xpath.lexer when type hinting is not used. It is possible that the module is located in the wrong directory.

[imgurbot12]

Hmm, It's still not working for me but I'm also not using the most recent version of Codon. I was seemingly having issues even running the latest version. Is there any intention of fixing these parity issues between Codon and Python at a later date?

The appeal of Codon, in my mind, would be that it enables developers to make major optimizations by making use of the already builtin python typehints available aside from being able to compile it which is also a huge bonus. The amount of changes needed to enable the plain python to run is a bit disheartening.

[elisbyberi]

In the upcoming pull request (for the latest working version of pyxml), I intend to remove all type hints for Python by commenting them out and add static typing for Codon where it is needed. After this step is complete, further development can proceed.

The amount of changes needed to enable the plain python to run is a bit disheartening.

The program should be able to run in plain Python, and type hints are only used to provide a way of indicating types to help static type checkers and linters accurately predict errors. Stated differently, type hinting must not interfere with the algorithm's functionality.

[imgurbot12]

Right I understand that, but for Codon to require it's own type hinting system that conflicts with Python's native type hints it makes it more difficult to integrate and turns Codon more into it's own language rather than something that compile and optimize Python.

The other small things like the way the import system works differently and the top-down parsing meaning you can't reference objects before they are defined all make it more annoying and less than trivial to port code from one to the other.

In my opinion, the ease of translation and portability between the two are the major factor that draws me to Codon in the first place. At the moment, with how prevalent type hinting is in all of my projects, it would be a major effort to compile any of my code with Codon. Is there a roadmap to fix these pain points or is the intent to have Codon exist as it's own language that almost works with python?

[elisbyberi]

@imgurbot12 Even though I'm quite busy, I'll try to work on the compatibility problems. Types bytes and bytearray were recently added to the "_compat" module.

[imgurbot12]

Closing due to inactivity. Feel free to reopen if you have any questions or issues!