On 10. 09. 21 10:48, Antonio Cuni wrote:
On Fri, Sep 10, 2021 at 9:55 AM Petr Viktorin
mailto:encukou@gmail.com> wrote: Sadly, "top 4000 PyPI packages" is very biased towards widely-used projects and the public projects -- ones least likely to have issues, because the community (of widely-used projects) or the author of the CPython change (for public projects) can submit fixes early.
I agree it's biased, but it's the only reasonable heuristic that we can use.
It would be sad if CPython focused only on successful, public projects; but I fear that's where we'll end up if we use this heuristic when evaluating changes.
We can use an N higher than 4000 to account also for public-but-less-succesfull ones.
... And I forgot about public projects that aren't on PyPI. I'm biased towards Fedora, so I'll name GIMP plugins, Firefox build system, and (for C API specifically) Samba bindings, as examples.
For non public ones, honestly I am not even sure whether we should care: if they are private it's very likely that they are used in a business context, where they surely can spend the money to fix them.
I think I get where you're coming from, but I really don't think making Python more expensive to maintain is helpful. their path as a Python developer
- money/time can also be spent on rewriting things in another language, if that's more economic (and that works for a community of volunteers as well as for a company)
- eventually some human will still need to do the change, and question
- not all companies have money to spend. I don't know how you feel about cash-strapped startups or Python-friendly skunkworks teams in multinational companies. But anyway, if a company can "surely can spend the money", IMO it would be better if they spend it on improving the ecosystem in backwards-compatible ways.
I think that the ability of evolving CPython and generally improve the broader Python ecosystem is more important than allowing some companies to save some bucks, but that's just my own personal opinion, of course.
Sure, let's evolve and improve CPython. But can we make it in steps that are individually helpful?
(I work at Red Hat but the views in this mail are my own.)