Live data from Hacker News

Pylava: A fork of the Pylama code audit tool for Python 3.7

github.com

21–30 of 30 posts

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#21
post #9

Earlier quoted context omitted.

Arch Linux has been shipping Py3 as the default python for a long time…

I am aware of that. So has been many other distributions like Debian, Ubuntu, etc. My point was: Which command do you normally use to install packages in Python 3? pip3 or pip? I thought it was pip3 but the article seems to imply that using the pip command to install packages in Python 3 is common too. If this is true, which distribution ships Python 3 with pip instead of pip3 for installing packages in Python 3? Doe…

Not the parent but on Ubuntu I use:

$ python -m pip ... # Use Python 2

$ python2 -m pip ... # If you want to be sure is using Python 2

$ python3 -m pip ... # Use Python 3

$ python3 -m venv ... # Create a virtualenv with Python 3 as documented on https://docs.python.org/3/library/venv.html to "prevent any potential confusion as to which Python interpreter a virtual environment will be based on"

I know it's verbose and long to type but looks explicit to me and saved me to use the wrong version of Python several times.

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#22
post #20
post #16

I've had this experience with a bunch of popular Django-related projects recently, where they stop receiving regular PR review and releases. Keeping up with Django's release cycle then requires digging into the bug trackers and forks for common dependencies. It's totally understandable for that to happen, when even popular projects rely on the volunteer effort of one or two people. One model I'm curious about is http…

One thing which would help would be corporate support. The Django project itself gets some support, probably not enough, but many people forget how much of the value from Django comes from the apps rather than the core framework.

Jazzband is interesting from that angle as well -- maybe encourage employees to spend some 20% time as Jazzband maintainers?

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#23
post #5

> On some Python 3 distributions, you may need to replace pip with pip3 in the command above. Are there any distributions where the command pip just works with Python 3? In every Python 3 installation I have used, I had to invoke it as pip3. So it seems to me that pip3 is the commonly used command and one may need to replace pip3 with pip only on some distributions.

Try `PYTHON -m MODULE` as in `python3 -m pip` if you want to make sure to use python3's pip, `python2 -m pip` for python2, `~/bin/python -m pip` for a personal python install, etc.

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#24
post #14

This is an interesting story. Python breaks perfectly reasonable code which is surprisingly nothing new for Python. A tool stops working. Users want fix. Author of the tool is unavailable. The tool needs to be forked. A new name needs to be chosen. A new distribution point needs to be established. All because Python chooses to break existing code. Can't the software designers of this century choose to provide feature…

I guess you’re mostly complaining about Python 2->3? That was a long time ago, and Python is hardly the only language to introduce a new, breaking major version.

This is a code analysis tool, quite different from your average library. It broke because Python introduce new reserved keywords (async/await). This is a non-breaking change for almost all libraries/software (and if it IS breaking for you, you probably just have to change variable names or something similar), but code analysis tools are different, they have to be totally up to date with new language features. Lots of languages introduce new reserved keywords decently often (in fact, lots have explicitly added async and await somewhat recently), it tends to break very little, except code analysis tools.

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#25
post #14

This is an interesting story. Python breaks perfectly reasonable code which is surprisingly nothing new for Python. A tool stops working. Users want fix. Author of the tool is unavailable. The tool needs to be forked. A new name needs to be chosen. A new distribution point needs to be established. All because Python chooses to break existing code. Can't the software designers of this century choose to provide feature…

Not that I disagree, but "async" is such a generic and widespread term that I can easily understand why they wouldn't want to choose something else. Have you read the kerfuffle about https://github.com/staltz/prevent-smoosh et al?

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#26
post #2

> With the release of Python 3.6, it became clear that Pylama was in need of maintenance updates. Python 3.6 warned that async was about to become a reserved keyword in Python 3.7. I can imagine there must be lot of code bases with async as variable name. For example: async = True This is an error in Python 3.7. >>> async = 1 File " ", line 1 async = 1 ^ SyntaxError: invalid syntax But this used to run just fine with…

My biggest hangup for my project is Celery... not compatible with 3.7 due to the use of the reserved keyboard `async` :(

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#27
post #22
post #20

Earlier quoted context omitted.

One thing which would help would be corporate support. The Django project itself gets some support, probably not enough, but many people forget how much of the value from Django comes from the apps rather than the core framework.

Jazzband is interesting from that angle as well -- maybe encourage employees to spend some 20% time as Jazzband maintainers?

Agreed — it'd be huge if companies donated even modest amounts to ongoing work on the open-source products which power their business.

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#28
post #5

> On some Python 3 distributions, you may need to replace pip with pip3 in the command above. Are there any distributions where the command pip just works with Python 3? In every Python 3 installation I have used, I had to invoke it as pip3. So it seems to me that pip3 is the commonly used command and one may need to replace pip3 with pip only on some distributions.

I generally use pyenv and/or a virtualenv, where the python and pip aliases point to the currently active version, which is almost always 3.

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#29
post #14

This is an interesting story. Python breaks perfectly reasonable code which is surprisingly nothing new for Python. A tool stops working. Users want fix. Author of the tool is unavailable. The tool needs to be forked. A new name needs to be chosen. A new distribution point needs to be established. All because Python chooses to break existing code. Can't the software designers of this century choose to provide feature…

I think you are referring to https://www.joelonsoftware.com/2004/06/13/how-microsoft-lost...

Re: Pylava: A fork of the Pylama code audit tool for Python 3.7

#30
post #26
post #2

> With the release of Python 3.6, it became clear that Pylama was in need of maintenance updates. Python 3.6 warned that async was about to become a reserved keyword in Python 3.7. I can imagine there must be lot of code bases with async as variable name. For example: async = True This is an error in Python 3.7. >>> async = 1 File " ", line 1 async = 1 ^ SyntaxError: invalid syntax But this used to run just fine with…

My biggest hangup for my project is Celery... not compatible with 3.7 due to the use of the reserved keyboard `async` :(

I just can't stand Celery as a project. It takes ages to stay up to date and I have had a few issues with it which just should not happen for such a large project
Post reply on HN