<p dir="ltr">Also note that even if publicly visible projects are outnumbered by private projects, the public projects tend to have a much larger impact on the overall ecosystem, because they're used by many entities (whereas private projects are typically only used by a single entity given their nature).</p>

<div class="gmail_quote">On Jan 8, 2014 5:13 PM, "Alejandro López Correa" <<a href="mailto:alc@spika.net">alc@spika.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
2014/1/9 Chris Angelico <<a href="mailto:rosuav@gmail.com">rosuav@gmail.com</a>>:<br>
> On Thu, Jan 9, 2014 at 10:34 AM, Alejandro López Correa <<a href="mailto:alc@spika.net">alc@spika.net</a>> wrote:<br>
>> 2014/1/8 Steven D'Aprano <<a href="mailto:steve@pearwood.info">steve@pearwood.info</a>>:<br>
><br>
> But what IS a good metric? How are you going to measure any of that?<br>
> It's better to at least use PyPI stats than to pull numbers out of a<br>
> hat.<br>
><br>
<br>
The problem I see is that metric might be equal or worse than just<br>
guessing because it is clearly biased: it focuses on open source<br>
projects hosted on PyPI. It is easy to measure it, but maybe it is not<br>
good to do so if that measure is used to make important decisions. In<br>
my [very limited] experience, the number of open source projects pales<br>
in comparison to that of projects kept "in the shadows".<br>
<br>
> Maybe. But how much temptation would it need to be to induce a<br>
> complete rewrite? (Mind you, it's not always a *complete* rewrite.<br>
> I've been "porting" code from Win32 C++ to GTK Pike, and in the<br>
> process usually shortened it by 50% or better, but mostly what I'm<br>
> doing is reading the old code, taking maybe a few bits of it that are<br>
> so simple they'd be the same in nearly any language, and<br>
> reimplementing the original logic.) The expanded gap between Python<br>
> 2.7 and Python 3.7 is mainly going to be features of 3.7 that you<br>
> could choose to use now that you've ported, rather than mandatory<br>
> changes. Python doesn't arbitrarily drop features or break stuff in<br>
> minor releases. That means the gap between 2.7 and 3.7 will still be<br>
> far FAR narrower than the gap between Python and Ruby - so,<br>
> correspondingly, the temptation to switch to Ruby would have to be<br>
> really strong. In the porting case I mentioned a moment ago, there<br>
> really was a very strong temptation (using Win32 APIs meant I was<br>
> bound to Windows (though Wine is a wonderful thing), and the C++ code<br>
> was going through stupid levels of overhead to manage memory and<br>
> such), so it was worth switching. I was NOT able to convince my boss<br>
> to switch our web site from PHP into Python, because he just couldn't<br>
> see enough benefit from changing language - but moving to a new PHP<br>
> was a much lower hump to get over. (Only a few things needed<br>
> changing.)<br>
<br>
Fair enough. I think it is a good argument.<br>
<br>
Alejandro<br>
_______________________________________________<br>
Python-ideas mailing list<br>
<a href="mailto:Python-ideas@python.org">Python-ideas@python.org</a><br>
<a href="https://mail.python.org/mailman/listinfo/python-ideas" target="_blank">https://mail.python.org/mailman/listinfo/python-ideas</a><br>
Code of Conduct: <a href="http://python.org/psf/codeofconduct/" target="_blank">http://python.org/psf/codeofconduct/</a></blockquote></div>