Re: [python-committers] Pace of change for Python 3.x

[Nick Coghlan]

On 26 January 2017 at 17:34, A.M. Kuchling  wrote:
> I mean, if funding software maintenance is illegal for a 501c3, then
> the FSF, Software Conservancy, Software in the Public Interest, Django
> Foundation, NumFOCUS, etc. are probably all illegal.

Note that I said the PSF needs to be careful in how it approaches the
question, not that it can't do it at all.

Problematic: "Commercial and other institutional end users are worried
about a lack of developer time being invested in maintaining long term
support branches, so the PSF should commit to funding that directly"
(this is the motivation where I believe the answer should be "Pay a
vendor for commercial support and tell them to work more actively on
the sustainability problem")

Entirely fine: "The core development community have submitted a grant
request to fund a dedicated part-time contract role for X months to
facilitate issue triage, patch reviews, and mentoring of potential new
core developers"

The latter motivation is about supporting the community and
facilitating its growth, which is entirely in line with the
Foundation's public interest mission.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Nick Coghlan]

On 25 January 2017 at 19:28, Neil Schemenauer  wrote:
> On 2017-01-25, A.M. Kuchling wrote:
>> I think this is the next frontier for Python maintenance; we need
>> full-time core maintainers, no third parties are funding any such
>> developers, and the PSF doesn't seem interested in pursuing that.
>
> IMHO, the PSF should be doing it.  I don't know exactly how the
> Linux Foundation works but my superficial understanding is that the
> LF gets funding mostly from big companies and then directly pays
> some Linux developers.  Most notable, Linus is paid by the LF.

Right now, the PSF's more concerned by the state of PyPI and the
packaging ecosystem than they are CPython - keep in mind that one of
the main concerns being raised about CPython development is that the
pace of change is already *too high* for the rest of the ecosystem to
keep up with (just based on those of us that have obtained individual
agreements with our employers to spend part of our time on upstream
contributions), whereas improvements in the packaging tools space
(which provide a more immediate benefit to many more community
members) are severely constrained by volunteer availability.

On that front, a funding proposal is being submitted to the Mozilla
Grants program to finalize the sunsetting of the legacy web service at
pypi.python.org, and migrating all operations over to pypi.org (those
are currently running as parallel front ends to the same backing data
store, but the new one is missing maintainer facing features that mean
it isn't yet possible to shut down the old one).

Eric also correctly channeled me in that I think the right way for
people to advocate for LTS CPython releases is:

1. Pick a commercial Python redistributor
2. Start paying them for support
3. Advocate for *them* (through whatever channels they provide) to
pursue a fully funded recurring LTS model in CPython upstream

That entirely avoids the "Is this an appropriate activity for a public
interest charity to be funding?" question, and also gives commercial
redistributors a clear practical benefit that they can pitch to their
subscribers (i.e. getting fixes backported from the main line of
development to LTS versions).

Cheers,
Nick.

P.S. Since it's relevant to the conversation at hand, and we all
collectively benefit from the upstream community maintaining strong
ties with our commercial redistributors, I'll also point out that
ActiveState, one of CPython's longest term commercial redistributors
and one of the founding sponsors of the PSF, is currently hiring for a
couple of key roles in their open source languages support and
development team: http://www.activestate.com/company#careers

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Nick Coghlan]

On 25 January 2017 at 15:29, M.-A. Lemburg  wrote:
> I also believe that the PSF should start stepping up and
> invest some money into helping with Python support. A lot
> of money is being spent on community work, but hardly any
> on development work at the moment.

Software maintenance is a commercial support activity that is normally
done for profit, so the PSF needs to be careful in how it approaches
it to avoid getting in trouble with the IRS (public interest charities
like the PSF operate under different taxation rules from trade
associations like the Linux and OpenStack Foundations, and hence have
a different set of constraints on their activities).

> By doing so, the PSF could also attract more sponsors, since
> sponsoring would then have a real tangible benefit to the
> sponsors.

This is the aspect the PSF needs to be careful about, as it's treading
very close to the line of activities that are better suited to a trade
association or for-profit corporation.

Something along the lines of the Twisted or Django fellowship would
likely be feasible - that would involve a grant request from the core
development community to fund someone to focus full-time on issue
triage and patch review for a designated period of time.

We'd need volunteers to help out with the review and selection process
for applicants for the role, as well as a volunteer to actually write
a grant proposal (including coming up with measurable objectives to
help the PSF judge whether or not the grant was a success).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Brett Cannon]

On Wed, 25 Jan 2017 at 06:29 M.-A. Lemburg  wrote:

> On 25.01.2017 13:30, Antoine Pitrou wrote:
> >
> > Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
> >> All that said, I believe a having a Python 2.7 style long
> >> support version for Python 3 would be nice and have a stabilizing
> >> effect which our user base would appreciate.
> >
> > Trying to enforce such a level of commitment (if we're talking 5+ years
> > of bugfix maintenance on an increasingly divergent codebase) in the
> > already controversial PEP 407 is probably not a good idea.  A separate
> > PEP is in order.
>
> This is not about enforcing commitment, it's about opening
> up our release process to be able to apply fixes on such an
> LTS beyond what we'd normally do.
>
> I'm pretty sure we can find core developers or attract new ones
> who'd be happy to be able to help fix issues in Python releases
> they use in their day job rather than work on releases which
> they won't be able to use in their day for at least another
> few years due to company policies.
>

I don't think that's necessarily true. I'm sure core developers fix bugs in
Python 2.7 if they run into them and it affects their work, but beyond that
I don't know how many of us are actually helping to maintain Python 2.7
beyond that (I for one immediately ignore all issues relating to 2.7 only
at this point). And attracting people to help is typically not an issue,
it's getting enough core developers to do code reviews to keep up with the
workload.

-Brett


>
> I also believe that the PSF should start stepping up and
> invest some money into helping with Python support. A lot
> of money is being spent on community work, but hardly any
> on development work at the moment.
>
> By doing so, the PSF could also attract more sponsors, since
> sponsoring would then have a real tangible benefit to the
> sponsors.
>
> >> We'd just say:
> >> this is our new LTS release (e.g. Python 3.7) and then move on
> >> until we're confident again that the feature set has stabilized
> >> enough to create a new LTS release.
> >
> > In practice you wouldn't just "move on" but have to maintain that LTS
> > release (which is the whole point).  If we're talking something past the
> > 2 years timerange, you can't just impose that on all core developers, so
> > you need a subgroup of maintainers dedicated to that LTS release.
>
> See above; this is about opening doors and lifting restrictions.
>
> --
> Marc-Andre Lemburg
> eGenix.com
>
> Professional Python Services directly from the Experts (#1, Jan 25 2017)
> >>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
> >>> Python Database Interfaces ...   http://products.egenix.com/
> >>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/
> 
>
> ::: We implement business ideas - efficiently in both time and costs :::
>
>eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
> D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
>Registered at Amtsgericht Duesseldorf: HRB 46611
>http://www.egenix.com/company/contact/
>   http://www.malemburg.com/
>
> ___
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers
> Code of Conduct: https://www.python.org/psf/codeofconduct/
>
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Neil Schemenauer]

On 2017-01-25, A.M. Kuchling wrote:
> I think this is the next frontier for Python maintenance; we need
> full-time core maintainers, no third parties are funding any such
> developers, and the PSF doesn't seem interested in pursuing that.

IMHO, the PSF should be doing it.  I don't know exactly how the
Linux Foundation works but my superficial understanding is that the
LF gets funding mostly from big companies and then directly pays
some Linux developers.  Most notable, Linus is paid by the LF.

Probably it is hard to attract and retrain top talent with a
Patreon-like donation system.  Software hackers are an eclectic
group so some of them would prefer that system.  However, I would
guess the majority would prefer more stable employment. 

Regarding PEP 407, I agree the LTS periods need to be longer.
Certainly we can't force core developers into doing maintenance.
However, there should be a process for an officially blessed LTS
release.  As a project, we should decide that it is worthwhile and
figure out how to help make it happen.

I guess we could decide that we don't want to do LTS releases.  I
would accept that.  Personally I think it would be a huge mistake,
especially at this point.  Python 2.7 is poised to become the
ultimate LTS release of Python.  I fear if we can't get more people
to upgrade in the next few years, Python will be forever fractured
into two communities.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Brett Cannon]

On Wed, 25 Jan 2017 at 06:11 A.M. Kuchling  wrote:

> On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote:
> > Channeling Nick, I'd say that LTS support should come from commercial
> third
> > parties, such as OS vendors. I agree with Antoine: it's not something we
> > want to impose on the core devs. How much fun is 2.7 maintenance?
>
> Are there any core developers who have Patreon accounts for monthly
> donations?  Examples from more Linux-y projects:
>
>
> https://www.reddit.com/r/linux/duplicates/5omtvg/patreons_to_support_open_source_projects_please/


I have yet to see anyone reach a level high enough to support themselves.
The people that I have seen use these approaches and make a living are
bloggers that also sell advertising and merchandise.


>
>
> I think this is the next frontier for Python maintenance; we need
> full-time core maintainers, no third parties are funding any such
> developers, and the PSF doesn't seem interested in pursuing that.
>

I've talked to the PSF about this and it isn't a lack of desire, it's a
lack of funds. The PSF wants to have at least a couple of years worth of
salary in the bank before taking on any employee and I suspect the salary
that would be required isn't a small sum.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Barry Warsaw]

On Jan 25, 2017, at 07:45 AM, Eric V. Smith wrote:

>Channeling Nick, I'd say that LTS support should come from commercial third
>parties, such as OS vendors. I agree with Antoine: it's not something we want
>to impose on the core devs. How much fun is 2.7 maintenance?

Which effectively happens anyway, although to varying degrees of activity.  If
an OS vendor releases a version of Python in their LTS, that's also a
commitment to support that for the length of LTS (Python usually being within
in the sphere of LTS supported packages, e.g. not everything in Ubuntu is
guaranteed support for 5 years of an LTS, just 'main' packages).

Cheers,
-Barry
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[M.-A. Lemburg]

On 25.01.2017 13:30, Antoine Pitrou wrote:
> 
> Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
>> All that said, I believe a having a Python 2.7 style long
>> support version for Python 3 would be nice and have a stabilizing
>> effect which our user base would appreciate.
> 
> Trying to enforce such a level of commitment (if we're talking 5+ years
> of bugfix maintenance on an increasingly divergent codebase) in the
> already controversial PEP 407 is probably not a good idea.  A separate
> PEP is in order.

This is not about enforcing commitment, it's about opening
up our release process to be able to apply fixes on such an
LTS beyond what we'd normally do.

I'm pretty sure we can find core developers or attract new ones
who'd be happy to be able to help fix issues in Python releases
they use in their day job rather than work on releases which
they won't be able to use in their day for at least another
few years due to company policies.

I also believe that the PSF should start stepping up and
invest some money into helping with Python support. A lot
of money is being spent on community work, but hardly any
on development work at the moment.

By doing so, the PSF could also attract more sponsors, since
sponsoring would then have a real tangible benefit to the
sponsors.

>> We'd just say:
>> this is our new LTS release (e.g. Python 3.7) and then move on
>> until we're confident again that the feature set has stabilized
>> enough to create a new LTS release.
> 
> In practice you wouldn't just "move on" but have to maintain that LTS
> release (which is the whole point).  If we're talking something past the
> 2 years timerange, you can't just impose that on all core developers, so
> you need a subgroup of maintainers dedicated to that LTS release.

See above; this is about opening doors and lifting restrictions.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 25 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[A.M. Kuchling]

On Wed, Jan 25, 2017 at 07:45:05AM -0500, Eric V. Smith wrote:
> Channeling Nick, I'd say that LTS support should come from commercial third
> parties, such as OS vendors. I agree with Antoine: it's not something we
> want to impose on the core devs. How much fun is 2.7 maintenance?

Are there any core developers who have Patreon accounts for monthly
donations?  Examples from more Linux-y projects:

https://www.reddit.com/r/linux/duplicates/5omtvg/patreons_to_support_open_source_projects_please/

I think this is the next frontier for Python maintenance; we need
full-time core maintainers, no third parties are funding any such
developers, and the PSF doesn't seem interested in pursuing that.

--amk
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Paul Moore]

On 25 January 2017 at 12:45, Eric V. Smith  wrote:
> Channeling Nick, I'd say that LTS support should come from commercial third
> parties, such as OS vendors. I agree with Antoine: it's not something we
> want to impose on the core devs. How much fun is 2.7 maintenance?

Agreed. When lack of reviews is an issue, imposing additional "not
fun" work on core devs isn't sustainable. As someone who does
(non-Python) software support for my day job, dealing with legacy
issues in Python doesn't feel like a hobby, it feels like work (and
unlike the rest of my day, I'm not getting paid for it).

Paul
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Eric V. Smith]

On 1/25/2017 7:30 AM, Antoine Pitrou wrote:

We'd just say:
this is our new LTS release (e.g. Python 3.7) and then move on
until we're confident again that the feature set has stabilized
enough to create a new LTS release.


In practice you wouldn't just "move on" but have to maintain that LTS
release (which is the whole point).  If we're talking something past the
2 years timerange, you can't just impose that on all core developers, so
you need a subgroup of maintainers dedicated to that LTS release.


Channeling Nick, I'd say that LTS support should come from commercial 
third parties, such as OS vendors. I agree with Antoine: it's not 
something we want to impose on the core devs. How much fun is 2.7 
maintenance?


Eric.


___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x

[Antoine Pitrou]

Le 25/01/2017 à 10:19, M.-A. Lemburg a écrit :
>>
>> You should take a look at this old deferred PEP:
>> https://www.python.org/dev/peps/pep-0407/
> 
> I don't understand the reasoning behind that PEP. With the proposed
> timing, those "LTS" releases would be no different than what we have
> today.
> 
> The only effect of the PEP would be to do releases more often,

That's indeed the main motivation: allow shipping changes faster to the
subset of users who are ok with a shorter support cycle (which has the
side-effect of making those changes tested in the wild earlier).

> which then results in using up minor release version numbers much
> too fast to give the impression of a stable programming system.

People with such psychological bias can simply use said "LTS" releases,
which would provide the same level of stability as today's feature releases.

> FWIW: I don't consider a release which is supported for just two years
> a long term support release.

The vocabulary can be changed if that's a concern :-)

> All that said, I believe a having a Python 2.7 style long
> support version for Python 3 would be nice and have a stabilizing
> effect which our user base would appreciate.

Trying to enforce such a level of commitment (if we're talking 5+ years
of bugfix maintenance on an increasingly divergent codebase) in the
already controversial PEP 407 is probably not a good idea.  A separate
PEP is in order.

> We'd just say:
> this is our new LTS release (e.g. Python 3.7) and then move on
> until we're confident again that the feature set has stabilized
> enough to create a new LTS release.

In practice you wouldn't just "move on" but have to maintain that LTS
release (which is the whole point).  If we're talking something past the
2 years timerange, you can't just impose that on all core developers, so
you need a subgroup of maintainers dedicated to that LTS release.

Regards

Antoine.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

[M.-A. Lemburg]

On 24.01.2017 22:08, Victor Stinner wrote:
> 2017-01-24 21:46 GMT+01:00 Neil Schemenauer :
>> Maybe we could emulate the Linux kernel releases.  I.e. have
>> relatively fast moving development but also choose releases to give
>> long maintenance cycles.  Ideally the long term releases would be
>> synchronized with OS distribitions (e.g. Red Hat, Debian, Ubuntu).
> 
> You should take a look at this old deferred PEP:
> https://www.python.org/dev/peps/pep-0407/

I don't understand the reasoning behind that PEP. With the proposed
timing, those "LTS" releases would be no different than what we have
today.

The only effect of the PEP would be to do releases more often,
which then results in using up minor release version numbers much
too fast to give the impression of a stable programming system.

FWIW: I don't consider a release which is supported for just two years
a long term support release. If we start using such a term it should
match people's expectation following Ubunutu's LTS cycles, i.e.
you get (at least) 5 years support for the release.

All that said, I believe a having a Python 2.7 style long
support version for Python 3 would be nice and have a stabilizing
effect which our user base would appreciate.

I'd not make this based on any timing, though. We'd just say:
this is our new LTS release (e.g. Python 3.7) and then move on
until we're confident again that the feature set has stabilized
enough to create a new LTS release.

Perhaps making the last minor version to a major release version
as we did with 2.7 is a good approach, i.e. we'd switch the
major number when cutting an LTS release and follow similar
guidelines as we have for 2.7 for this 3.x LTS release.

-- 
Marc-Andre Lemburg
eGenix.com

Professional Python Services directly from the Experts (#1, Jan 25 2017)
>>> Python Projects, Coaching and Consulting ...  http://www.egenix.com/
>>> Python Database Interfaces ...   http://products.egenix.com/
>>> Plone/Zope Database Interfaces ...   http://zope.egenix.com/


::: We implement business ideas - efficiently in both time and costs :::

   eGenix.com Software, Skills and Services GmbH  Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
   Registered at Amtsgericht Duesseldorf: HRB 46611
   http://www.egenix.com/company/contact/
  http://www.malemburg.com/

___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

[Brett Cannon]

On Tue, 24 Jan 2017 at 13:26 Neil Schemenauer 
wrote:

> On 2017-01-24, Victor Stinner wrote:
> > You should take a look at this old deferred PEP:
> > https://www.python.org/dev/peps/pep-0407/
>
> Thanks, that's very close to what I was thinking.  I would still add
> that we should be extra careful about incompatible language features
> until 2.7.x usage has mostly died off.  That isn't logically part of
> the PEP but a general development philosophy I think we should
> adopt.
>

In terms of the stdlib we have already committed to not remove any code
until after 2.7 hits EOL :
https://www.python.org/dev/peps/pep-0004/#for-modules-existing-in-both-python-2-7-and-python-3-5
(but I suspect will be stretched until we decide to release Py4k).

We also have had a language change moratorium for Python 3.2:
https://www.python.org/dev/peps/pep-3003/ . That was done in hopes of PyPy
and other interpreters would use the time to catch up, but that never
materialized.

But as Alex pointed out, part of the problem is people don't want to switch
unless they have a compelling reason to that they can materially point to.
For instance I have heard plenty of people say that async/await and
f-strings are reasons enough for them to switch, not the fact that Python 3
has a more consistent design while now matching Python 2.7's overall
performance.

I should also say that I think Python 3.6 is a rare release. With async
opening up so many doors for consistency in the language it led to a lot of
changes there. But then again Python 3.6 also had a whole PEP dedicated to
adding a 'fold' argument to datetime. And in Victor's case a lot of stuff
was performance stuff that's under the covers and not really exposed
directly to the user anyway so no language moratorium would have changed
things.

While I like the idea of PEP 407 if we stop doing bugfix releases for
non-LTS releases and everything is considered provisional until it lands in
an LTS release, I think we will have to see if GitHub helps or hurts our
release process. If it makes it easier to cut releases then maybe it will
be okay (that's something current and former RMs and their cohorts should
be the ones to answer). But I'm also happy with waiting until 2020 to think
about this -- which is 2 feature releases away -- or to make PEP 407 a Py4k
thing.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

[Alex Martelli via python-committers]

On Tue, Jan 24, 2017 at 1:26 PM, Neil Schemenauer 
wrote:

> On 2017-01-24, Victor Stinner wrote:
> > You should take a look at this old deferred PEP:
> > https://www.python.org/dev/peps/pep-0407/
>
> Thanks, that's very close to what I was thinking.  I would still add
> that we should be extra careful about incompatible language features
> until 2.7.x usage has mostly died off.  That isn't logically part of
> the PEP but a general development philosophy I think we should
> adopt.
>

I love that PEP. However, I don't think the best way to attract large
masses of people away from 2.7 and onto 3.* is to avoid adding features to
3.* releases: such an approach would not offer compelling reasons to
migrate, as needed to overcome natural inertia.

Rather, thinking of what arguments I could bring to add further support to
a case for migration (wearing the "consultant's hat" which I haven't donned
in 12 years, so, I'm a bit rusty:-) I think: performance/scalability;
stability; cool new features; whatever extra gizmos may help existing 2.7
code run fine under new shiny 3.whatever with only automated code
transformation steps in the way (reverse migration, i.e 3.foobar -> 2.7,
nowhere near as important). A lot of this describes stuff that HAS been
happening -- the "stability" point would be particularly well addressed by
PEP 407 or some variant thereof...


Alex
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

[Neil Schemenauer]

On 2017-01-24, Victor Stinner wrote:
> You should take a look at this old deferred PEP:
> https://www.python.org/dev/peps/pep-0407/

Thanks, that's very close to what I was thinking.  I would still add
that we should be extra careful about incompatible language features
until 2.7.x usage has mostly died off.  That isn't logically part of
the PEP but a general development philosophy I think we should
adopt.
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/

Re: [python-committers] Pace of change for Python 3.x [was: My cavalier and aggressive manner, API] change and bugs introduced for basically zero benefit

[Victor Stinner]

2017-01-24 21:46 GMT+01:00 Neil Schemenauer :
> Maybe we could emulate the Linux kernel releases.  I.e. have
> relatively fast moving development but also choose releases to give
> long maintenance cycles.  Ideally the long term releases would be
> synchronized with OS distribitions (e.g. Red Hat, Debian, Ubuntu).

You should take a look at this old deferred PEP:
https://www.python.org/dev/peps/pep-0407/

Victor
___
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/