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

--remove-literal-statements doesn't work #24

Closed
phorward opened this issue Feb 22, 2021 · 3 comments
Closed

--remove-literal-statements doesn't work #24

phorward opened this issue Feb 22, 2021 · 3 comments

Comments

@phorward
Copy link

phorward commented Feb 22, 2021

Hi!

First of all, thank you very much for writing this software. It is very useful to decrease the size of Python's standard library when exposing it for web-apps running with Pyodide, a full CPython 3.8 compiled to web-assembly and running in the browser.

Anyway, it seems I found a bug, because the --remove-literal-statements does not seem to have any effect on the provided sources. These two calls return exactly the same result. Docstrings are everywhere.

$ pyminify  0.py >a.txt 
$ pyminify --remove-literal-statements 0.py  >b.txt 

Attached are the results I got. I'm on pyminify 2.4.1 as installed from PyPI, the used Python version for execution is 3.9.1, but I also tested it with 3.8.2 with the same result.

0.py => this is the __init.py__ of Python 3.8.2's collections standard library package
a.txt
b.txt

@phorward
Copy link
Author

Supplement: After a few further tests, I found out that the docstring from other modules seems to be removed properly - except in the case with the 0.txt above. (__init__.py from cpython/Lib/collections)

@dflook
Copy link
Owner

dflook commented Feb 22, 2021

Hi @phorward, thanks for creating an issue.

It looks like this is because the problem modules use the global __doc__ name or .__doc__ attributes, which currently disable all literal removal. This doesn't always work correctly, but cautiously leaves docstrings in if unsure.

I do plan to make this more flexible, see #11.

@phorward
Copy link
Author

@dflook Thanks for the quick answer! Yes, it seems that this module uses __doc__, but with a different context, so it shouldn't break. But it's OK for me, and I'm looking forward so that #11 is getting fixed.

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

No branches or pull requests

2 participants