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

Incorrect parameter type hint or method realization of write_aas_xml_file() #42

Closed
zrgt opened this issue Nov 30, 2022 · 3 comments · Fixed by #251
Closed

Incorrect parameter type hint or method realization of write_aas_xml_file() #42

zrgt opened this issue Nov 30, 2022 · 3 comments · Fixed by #251

Comments

@zrgt
Copy link
Contributor

zrgt commented Nov 30, 2022

The problem occures by using adapter/xml_serialization.py/write_aas_xml_file(). The method has file as parameter, which should be of type IO, but I get Exception, that the expected type of parameter file is str

Traceback (most recent call last):
.........\basyx\aas\adapter\xml\xml_serialization.py", line 897, in write_aas_xml_file
tree.write(file, encoding="UTF-8", xml_declaration=True, method="xml", **kwargs)
File "src\lxml\etree.pyx", line 2057, in lxml.etree._ElementTree.write
File "src\lxml\serializer.pxi", line 758, in lxml.etree._tofilelike
File "src\lxml\etree.pyx", line 318, in lxml.etree._ExceptionContext._raise_if_stored
File "src\lxml\serializer.pxi", line 682, in lxml.etree._FilelikeWriter.write
TypeError: write() argument must be str, not bytes

@jkhsjdhjs
Copy link
Contributor

Yep. We should fix this together with the points discussed here https://git.rwth-aachen.de/acplt/pyi40aas/-/issues/109

@s-heppner
Copy link
Contributor

@jkhsjdhjs What's the status of this?

@jkhsjdhjs
Copy link
Contributor

@s-heppner The issue isn't resolved yet. We should fix this eventually, but it's not a priority right now.

jkhsjdhjs referenced this issue in rwth-iat/basyx-python-sdk Mar 13, 2024
lxml supports paths already, no modification is necessary there.
However, the `lxml.etree.ElementTree.write()` function requires
`BinaryIO`, i.e. files opened with the 'b' mode. While it would be
possible to access the underlying binary buffer of files opened in text
mode via `open()`, this isn't possible for `io.StringIO()`, as it
doesn't have the `buffer` property. Thus, even if we could support files
opened via `open()` in text mode, we couldn't annotate the XML
serialization functions with `TextIO`, as `io.StringIO()` remains
unsupported. Because of that, I decided to not support `TextIO` for the
XML serialization.

The builtin JSON module only supports file handles, with the
`json.dump()` method only supporting `TextIO` and `json.load()`
supporting `TextIO` and `BinaryIO`. Thus, the JSON adapter is modified
to `open()` given paths, while the JSON serialization is additionally
modified to wrap `BinaryIO` with `io.TextIOWrapper`.

Fix #42
jkhsjdhjs referenced this issue in rwth-iat/basyx-python-sdk Mar 13, 2024
lxml supports paths already, no modification is necessary there.
However, the `lxml.etree.ElementTree.write()` function requires
`BinaryIO`, i.e. files opened with the 'b' mode. While it would be
possible to access the underlying binary buffer of files opened in text
mode via `open()`, this isn't possible for `io.StringIO()`, as it
doesn't have the `buffer` property. Thus, even if we could support files
opened via `open()` in text mode, we couldn't annotate the XML
serialization functions with `TextIO`, as `io.StringIO()` remains
unsupported. Because of that, I decided to not support `TextIO` for the
XML serialization.

The builtin JSON module only supports file handles, with the
`json.dump()` method only supporting `TextIO` and `json.load()`
supporting `TextIO` and `BinaryIO`. Thus, the JSON adapter is modified
to `open()` given paths, while the JSON serialization is additionally
modified to wrap `BinaryIO` with `io.TextIOWrapper`.

Fix #42
s-heppner pushed a commit that referenced this issue Mar 14, 2024
lxml supports paths already, no modification is necessary there.
However, the `lxml.etree.ElementTree.write()` function requires
`BinaryIO`, i.e. files opened with the 'b' mode. While it would be
possible to access the underlying binary buffer of files opened in text
mode via `open()`, this isn't possible for `io.StringIO()`, as it
doesn't have the `buffer` property. Thus, even if we could support files
opened via `open()` in text mode, we couldn't annotate the XML
serialization functions with `TextIO`, as `io.StringIO()` remains
unsupported. Because of that, I decided to not support `TextIO` for the
XML serialization.

The builtin JSON module only supports file handles, with the
`json.dump()` method only supporting `TextIO` and `json.load()`
supporting `TextIO` and `BinaryIO`. Thus, the JSON adapter is modified
to `open()` given paths, while the JSON serialization is additionally
modified to wrap `BinaryIO` with `io.TextIOWrapper`.

Fix #42
s-heppner pushed a commit that referenced this issue Aug 16, 2024
adapter.http: allow changing the API base path
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants