Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

github.com

Post reply on HN
Print view View original

11–20 of 30 posts

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

#11

Post by [deleted] »

xyrouter wrote: post #9
floatboth wrote: post #7

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…

[deleted]

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

#12

Post by floatboth »

xyrouter wrote: post #9
floatboth wrote: post #7

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…

If 'python' is 3, I'd expect 'pip' to be for 3, and 'pip2' for 2.

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

#14

Post by modsec »

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 flags (use strict, use VERSION, etc.) to enable new features that break existing code?

There was a nice and popular article/blog post from someone famous about never ever breaking existing code or functionality because users depend on it but I cannot remember the title of that post to search it.

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

#15

Post by xyrouter »

floatboth wrote: post #12
xyrouter wrote: post #9

Earlier quoted context omitted.

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…

If 'python' is 3, I'd expect 'pip' to be for 3, and 'pip2' for 2.

Ah! That makes a lot of sense. If Python 3 is the default, it does make sense 'pip' to be the Python 3 pip. That way 'pip' always refers to the default version.

Unfortunately in the Ubuntu and Mac world 'python' is still Python 2.7 and 'pip' refers to the Python 2 pip. Python 3 is available as 'python3' along with 'pip3'.

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

#16

Post by JackC »

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 https://jazzband.co/, "a collaborative community to share the responsibility of maintaining Python-based projects." Not sure how well that works in practice, but it would be great for something like that to crack the maintainer-burnout problem.

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

#17

Post by closed »

xyrouter wrote: 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.

AFAIK you usually have pip (system default python), pip2 (corresponds to python2), and pip3 (corresponds to python3). Like others have mentioned, a few distributions have python 3 as the default python.

In later versions you can invoke pip using python -m pip install ..., which makes it more clear which python is being used.

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

#18

Post by foo101 »

JackC wrote: 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…

I believe something like the model followed by Apache Software Foundation works well in favor of continuity of a project. They have an overseeing committee that one can request to add new committers or even transfer ownership of project if the existing committers are no longer maintaining the project.

But ASF does come with a lot of bureaucracy for creating a new project. GitHub makes creating new projects very simple but it also makes disapperance of ownership very likely. If there was a way to request GitHub to transfer ownership of a popular but unmaintained project to someone else, a lot of time and effort spent in creating new forks and new project resources could be avoided.

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

#19

Post by pas »

foo101 wrote: post #6
mcintyre1994 wrote: post #3

Earlier quoted context omitted.

Yep, Python doesn't use semver and after 2-3 I doubt they're keen on major version changes any more. From the 3.7 release notes ( https://docs.python.org/3/whatsnew/3.7.html ): Backwards incompatible syntax changes: async and await are now reserved keywords.

Has any other mainstream programming language like C or Java introduced such reserved keywords in a new release? I guess if C or Java were to do something like this it would cause a lot of hue and cry. I remember when C++ had to introduce a keyword for automatic type inference they reused the 'auto' keyword instead of introducing a new keyword at the risk of breaking a lot of existing code. How do other mainstream la…

enum, assert was added to Java, but nothing major since then. (var is an invalid class name starting in Java 10, and underscore is a keyword since Java 9)

https://en.wikipedia.org/wiki/List_of_Java_keywords

For C++ ( New keywords: alignas, alignof, char16_t, char32_t, constexpr, decltype, noexcept, nullptr, static_assert, and thread_local ) : https://stackoverflow.com/questions/6399615/what-breaking-ch...

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

#20

Post by acdha »

JackC wrote: 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.
Post reply on HN