[Python-ideas] from __past__ import division, str, etc

[Nick Coghlan]

On 9 Jan 2014 09:49, "Amber Yust" <amber.yust at gmail.com> wrote:
>
> 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).

It also mistakenly assumes our goal is to get existing *applications* to
migrate. It really isn't - we're obviously delighted if app developers
choose to switch (as it indicates we have created a compelling platform),
but we *needed* key library and framework developers to add Python 3
support in order to bootstrap the Python 3 development ecosystem.

Cheers,
Nick.

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