[Python-Dev] The end of 2.7

[Benjamin Peterson]

Per my last message, 2.7.4 has at long last been released. I apologize
for the long interval between 2.7.3 and 2.7.4. To create more
determinism in the future, I will be soon updating PEP 373 with
approximate dates of future 2.7 bugfix releases. I will be aiming for
6 month intervals.

This means we need to talk about how many more 2.7 releases there are
going to be. At the release of 2.7.0, I thought we promised 5 years of
bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
was released in July 2010, which currently puts us within a few months
of 3 years of maintenance. Over the past year, I've been happy to see
a lot of movement towards 3 including the porting of important
codebases like Twisted and Django. However, there's also no doubt that
2.x is still widely used. Obviously, there will be people who would be
happy if we kept maintaining 2.7 until 2025, but I think at this
juncture 5 total years of maintenance is reasonable. This means there
will be approximately 4 more 2.7 releases.

Thoughts?

Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[Georg Brandl]

Am 06.04.2013 23:02, schrieb Benjamin Peterson:
> Per my last message, 2.7.4 has at long last been released. I apologize
> for the long interval between 2.7.3 and 2.7.4. To create more
> determinism in the future, I will be soon updating PEP 373 with
> approximate dates of future 2.7 bugfix releases. I will be aiming for
> 6 month intervals.
>
> This means we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
> was released in July 2010, which currently puts us within a few months
> of 3 years of maintenance. Over the past year, I've been happy to see
> a lot of movement towards 3 including the porting of important
> codebases like Twisted and Django. However, there's also no doubt that
> 2.x is still widely used. Obviously, there will be people who would be
> happy if we kept maintaining 2.7 until 2025, but I think at this
> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.
>
> Thoughts?

I agree that keeping to 5 years of official maintenance releases is
reasonable at present.

However, in 2015 I can well imagine offers from group(s) in the community
to maintain the 2.7 branch with fixes ported from 3.x. At that point,
we will have to decide how to treat releases from this "backports" branch.

Georg

[Antoine Pitrou]

On Sat, 6 Apr 2013 17:02:17 -0400
Benjamin Peterson <benj...@python.org> wrote:
> Obviously, there will be people who would be
> happy if we kept maintaining 2.7 until 2025, but I think at this
> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.
>
> Thoughts?

That's quite fine with me.

Regards

Antoine.

[Christian Heimes]

Am 06.04.2013 23:11, schrieb Georg Brandl:
> Am 06.04.2013 23:02, schrieb Benjamin Peterson:
>> Per my last message, 2.7.4 has at long last been released. I apologize
>> for the long interval between 2.7.3 and 2.7.4. To create more
>> determinism in the future, I will be soon updating PEP 373 with
>> approximate dates of future 2.7 bugfix releases. I will be aiming for
>> 6 month intervals.
>>
>> This means we need to talk about how many more 2.7 releases there are
>> going to be. At the release of 2.7.0, I thought we promised 5 years of
>> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
>> was released in July 2010, which currently puts us within a few months
>> of 3 years of maintenance. Over the past year, I've been happy to see
>> a lot of movement towards 3 including the porting of important
>> codebases like Twisted and Django. However, there's also no doubt that
>> 2.x is still widely used. Obviously, there will be people who would be
>> happy if we kept maintaining 2.7 until 2025, but I think at this
>> juncture 5 total years of maintenance is reasonable. This means there
>> will be approximately 4 more 2.7 releases.
>>
>> Thoughts?
>
> I agree that keeping to 5 years of official maintenance releases is
> reasonable at present.
>
> However, in 2015 I can well imagine offers from group(s) in the community
> to maintain the 2.7 branch with fixes ported from 3.x. At that point,
> we will have to decide how to treat releases from this "backports" branch.

Five years official releases sounds fine to me, too.

Martin, how long are you going to build official Windows binaries for
Python 2.7?

Christian

[Gregory P. Smith]

I agree with Benjamin though is it really necessary to do two 2.7 releases a year for the last two years?  that's rather rapid (but as the release manager its your call).

A few of us (sorry I forgot who all was there though I think Martin was?) had a discussion at PyCon a few weeks ago and seemed to think that a state of affairs where a 2.7.5 release one year-ish from now would be fine as the last _binary_ release but that continuing to make a 2.7.6 and beyond as source only releases was reasonable.

Regardless, the 5 years of 2.7 supported releases plan still makes sense regardless of release binaries being available for windows and mac or not.

-gps

Unsubscribe: http://mail.python.org/mailman/options/python-dev/greg%40krypto.org

[Benjamin Peterson]

2013/4/6 Gregory P. Smith <gr...@krypto.org>:

> I agree with Benjamin though is it really necessary to do two 2.7 releases a
> year for the last two years? that's rather rapid (but as the release
> manager its your call).

What I like about 6 months is that its short enough, so we don't have
feel bad about not taking a certain change; it can just be pushed to
the next no-too-far-away release. A year is quite a while to wait for
a fix to be released. It's also a nice timeframe for some
distributions (looking at you, Ubuntu).


--
Regards,
Benjamin

_______________________________________________
Python-Dev mailing list
Pytho...@python.org
http://mail.python.org/mailman/listinfo/python-dev

Unsubscribe: http://mail.python.org/mailman/options/python-dev/dev-python%2Bgarchive-30976%40googlegroups.com

[Ned Deily]

In article
<CAPZV6o-r_Z1MR+Kjn8jB5ZVX...@mail.gmail.com>,

Benjamin Peterson <benj...@python.org> wrote:
> 2013/4/6 Gregory P. Smith <gr...@krypto.org>:

> What I like about 6 months is that its short enough, so we don't have
> feel bad about not taking a certain change; it can just be pushed to
> the next no-too-far-away release. A year is quite a while to wait for
> a fix to be released. It's also a nice timeframe for some
> distributions (looking at you, Ubuntu).

+1 to both a 6-month release interval and to soon announcing a date for
the last maintenance release that is no later than 2015. As Georg
points out, though, there undoubtedly will be pushback on that so we
should make sure we have a good story for what happens after that date
and we start communicating it in plenty of time. An important of that
is emphasizing what will be available on Python 3.x by then and figuring
out what to do about any important missing pieces, e.g. key third-party
components not yet ported.

--
Ned Deily,
n...@acm.org

[Raymond Hettinger]

On Apr 6, 2013, at 2:02 PM, Benjamin Peterson <benj...@python.org> wrote:

we need to talk about how many more 2.7 releases there are
going to be. At the release of 2.7.0, I thought we promised 5 years of
bugfix maintenance, but my memory may be fuddled. 

I don't we need to make any "promises" beyond 5 years,

but I also think it is likely the 2.7 will end-up being a 

long-term maintenance version of Python.

At this year's Pycon keynote, I surveyed the crowd (approx 2500 people)

and all almost everyone indicated that they had tried out Python 3.x

and almost no one was using it in production or writing code for it.

That indicates that Python 2.7 will continue to be important for a good

while.  

In addition,  the other implementations of Python (Jython, PyPy, GAE, 

and IronPython) are all at or nearly at Python 2.7.   So, continued

support will be needed for their users as well.

After 2.7.4, I expect that the pace of real bug fixes will slow down,

but that we'll continue to improve docs, add docstrings, update IDLE, etc.

IMO, it is premature to utter the phrase "the end of 2.7".

Better to say, "2.7 is stable and is expected to only have minor updates".

Future point releases probably ought to occur "on their own schedule"

whenever there are a sufficient number of changes to warrant a release,

or an important security fix, or whenever the release managers have time.

Raymond

------

PYTHON 2.7      I'm not dead!

CART DRIVER     'Ere.  He says he's not dead.

LARGE MAN       Yes he is.

PYTHON 2.7      I'm not!

CART DRIVER     He isn't.

LARGE MAN       He will be soon. He's very ill.

PYTHON 2.7      I'm getting better!

LARGE MAN       You're not.   You'll be stone

                dead in a few minutes.

[Terry Jan Reedy]

On 4/6/2013 5:11 PM, Georg Brandl wrote:
> Am 06.04.2013 23:02, schrieb Benjamin Peterson:
>> Per my last message, 2.7.4 has at long last been released. I apologize
>> for the long interval between 2.7.3 and 2.7.4. To create more
>> determinism in the future, I will be soon updating PEP 373 with
>> approximate dates of future 2.7 bugfix releases. I will be aiming for
>> 6 month intervals.

In 6 months, there will be a bunch more IDLE fixes (there are already
some that were too late for today's releases), so that will be good from
that standpoint. Some people will continue teaching with 2.7 for who
knows how long. I expect Idle to be considerably polished within 2 years.

>> This means we need to talk about how many more 2.7 releases there are
>> going to be. At the release of 2.7.0, I thought we promised 5 years of
>> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
>> was released in July 2010, which currently puts us within a few months
>> of 3 years of maintenance. Over the past year, I've been happy to see
>> a lot of movement towards 3 including the porting of important
>> codebases like Twisted and Django. However, there's also no doubt that
>> 2.x is still widely used. Obviously, there will be people who would be
>> happy if we kept maintaining 2.7 until 2025, but I think at this
>> juncture 5 total years of maintenance is reasonable. This means there
>> will be approximately 4 more 2.7 releases.
>>
>> Thoughts?

> I agree that keeping to 5 years of official maintenance releases is
> reasonable at present.

I do not remember if there was any promise of security fixes after 5 years.

> However, in 2015 I can well imagine offers from group(s) in the community
> to maintain the 2.7 branch with fixes ported from 3.x.

I can imagine that. And I can imagine no volunteers ;-). I think that
volunteering after the mid-2015 5-year release is too late in a sense.
Anybody who thinks they will want to prolong maintenance should start
working *now* to test bugfix patches on 2.7 and re-write as necessary
and earn core-developer status. I think this should be
suggested/publicized now.

Unless Benjamin volunteers to continue doing releases, at least one new
volunteer needs to learn how to do them, perhaps by working with him on
some the the remaining releases he does do.

> At that point, we will have to decide how to treat releases from this "backports" branch.

If there are at least a couple of people with 2.7 branch push
privileges, who understand and agree to follow 'bugfixes only', with due
consideration of back-compatibility, then I see no reason for such
releases not to be official PSF releases. If some people take up 2.7
after the final 2.7 release and work independently us, then it is out of
our hands. (And they will have to call their releases something other
than 'Python 2.7.z')

--
Terry Jan Reedy

[Senthil Kumaran]

On Sat, Apr 6, 2013 at 2:02 PM, Benjamin Peterson <benj...@python.org> wrote:

> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.

That's good. From the subject of the email, I though you were
announcing "This is the end of 2.7.x releases".
2 more year with 6 month cycle seem to be a good one.

Thank you!
Senthil

[Nick Coghlan]

On Sun, Apr 7, 2013 at 7:02 AM, Benjamin Peterson <benj...@python.org> wrote:
> Per my last message, 2.7.4 has at long last been released. I apologize
> for the long interval between 2.7.3 and 2.7.4. To create more
> determinism in the future, I will be soon updating PEP 373 with
> approximate dates of future 2.7 bugfix releases. I will be aiming for
> 6 month intervals.
>
> This means we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
> was released in July 2010, which currently puts us within a few months
> of 3 years of maintenance. Over the past year, I've been happy to see
> a lot of movement towards 3 including the porting of important
> codebases like Twisted and Django. However, there's also no doubt that
> 2.x is still widely used. Obviously, there will be people who would be
> happy if we kept maintaining 2.7 until 2025, but I think at this
> juncture 5 total years of maintenance is reasonable. This means there
> will be approximately 4 more 2.7 releases.
>
> Thoughts?

This aligns well with what I've been telling people for the past
couple of years, so +1 from me.

Commercial Linux distros will also offer 2.7 support out beyond 2015,
and it seems to me that the intersection between "needs Python 2.7
support beyond 2015" and "is willing to pay for that support" is
likely to be pretty high. If the demand is there on the Windows side,
then I expect companies like ActiveState and Enthought will also be
happy to oblige.

Cheers,
Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[mar...@v.loewis.de]

Quoting Benjamin Peterson <benj...@python.org>:

> This means we need to talk about how many more 2.7 releases there are
> going to be. At the release of 2.7.0, I thought we promised 5 years of
> bugfix maintenance, but my memory may be fuddled.

I'd like to promote the idea to abandon 2.7 bug fix releases earlier
than that, e.g. along with the release of 3.4. My recollection is
that "we" didn't actually promise any specific time frame; I recall
that Guido said that Python 2.7 would be supported "indefinitely",
which is not "infinitely" [1]. The Whats New says [2]

"""It’s very likely the 2.7 release will have a longer period of
maintenance compared to earlier 2.x versions."""

which explicitly refuses to set a date. Of course, individual committers
may have promised a more specific policy publicly in the past.

Since Christian asked: I'll likely continue to make binary releases
for Windows as along as Benjamin declares releases to be bug fix
releases. However, it will become increasingly difficult for users
to actually use these releases to build extension modules since
Microsoft decided to take VS 2008 Express offline (VS 2008 remains
available to MSDN subscribers; getting it from a store might
also be difficult in 2014).

I wonder whether the burden of maintaining three branches for bug
fixes (2.7, 3.3, default) and three more for security fixes
(2.6, 3.1, 3.2) is really sustainable for committers. I wouldn't
want to back off wrt. security fixes, and 2.6 will soon fall out
of the promised 5 years (after the initial release). However,
stopping to accept bug fixes for 2.7 would IMO significantly reduce
the load for committers - it would certainly continue to get
security fixes, and (for the time being) "indefinitely" so.

Wrt. to the 3.x migration rate: I think this is a self-fulfilling
prophecy. Migration rate will certainly increase once we announce
an end of 2.7, and then again when the end is actually reached.

I'm doubtful with respect to a community-managed ongoing 2.7 bug
fix release (i.e. I doubt that it will happen); the same was
discussed for a next 2.x feature release, and it hasn't happened.
OTOH, it is very likely that people will publish their own patches
to 2.7 throughout the net, just as the Linux distributions already
do. It may even happen that some volunteer offers to publish a
combined repository for such patches, with various members of the
community having write access to such a repository (but no formal
releases coming out of that).

Regards,
Martin

[1] http://mail.python.org/pipermail/python-dev/2009-November/093651.html
[2] http://docs.python.org/dev/whatsnew/2.7.html#the-future-for-python-2-x

[Maciej Fijalkowski]

Martin, you guys are shooting yourself in a foot. Almost noone uses
python 3 in production, even at pycon, which is the more progressive
crowd. There is a giant group of people using python that are not as
vocal. While I bet some are using Python 3, Python 2 is incredibly
popular for the "long tail" of libraries and applications. How much is
2.7 a burden? There are no major changes and it's pretty cool to
consider it "done".

For what is worth, we'll maintain the stdlib part of 2.7 past 2 years.
It would be cool if python-dev participated in that.

Cheers,
fijal

[Lennart Regebro]

On Sun, Apr 7, 2013 at 7:11 AM, <mar...@v.loewis.de> wrote:

> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
> prophecy. Migration rate will certainly increase once we announce
> an end of 2.7, and then again when the end is actually reached.

Well... People are in general *stuck* on Python 2. They are not
staying because they want to. So I'm not so sure migration rate will
increase because an end is announced or reached.

//Lennart

[mar...@v.loewis.de]

> Martin, you guys are shooting yourself in a foot. Almost noone uses
> python 3 in production, even at pycon, which is the more progressive
> crowd. There is a giant group of people using python that are not as
> vocal. While I bet some are using Python 3, Python 2 is incredibly
> popular for the "long tail" of libraries and applications. How much is
> 2.7 a burden? There are no major changes and it's pretty cool to
> consider it "done".

Indeed - hence I think it is just fine to stop applying bug fixes to it,
as well. People for whom it works fine today apparently don't run into any
significant bugs. They can happily continue to use it as-is for ten or more
years. It will not go away just when we reduce changes to security fixes.
It will remain available for download, the documentation will keep being
online, people can continue to ask questions about it on python-list, and
continue to get answers.

Stopping to apply bug fixes does not really *end* Python 2.7.

It's only that people who *do* run into bugs don't have the option anymore
that we will eventually publish a fixed release. Their options reduce to
- port to 3.x (particularly interesting if Python 3.x *already* fixed it)
- find a work-around
- maintain a bug fix locally
- do something else entirely (like abandoning Python)

People deserve to know our plans, so we really need to agree on them and
then announce them (see PEP 404). However, people (IMO) have no right to
expect us to maintain Python 2.7 until they migrate to 3.x. If we would do
that, they will never migrate.

Regards,
Martin

[Maciej Fijalkowski]

On Sun, Apr 7, 2013 at 9:44 AM, <mar...@v.loewis.de> wrote:
>> Martin, you guys are shooting yourself in a foot. Almost noone uses
>> python 3 in production, even at pycon, which is the more progressive
>> crowd. There is a giant group of people using python that are not as
>> vocal. While I bet some are using Python 3, Python 2 is incredibly
>> popular for the "long tail" of libraries and applications. How much is
>> 2.7 a burden? There are no major changes and it's pretty cool to
>> consider it "done".
>
>
> Indeed - hence I think it is just fine to stop applying bug fixes to it,
> as well. People for whom it works fine today apparently don't run into any
> significant bugs. They can happily continue to use it as-is for ten or more
> years. It will not go away just when we reduce changes to security fixes.
> It will remain available for download, the documentation will keep being
> online, people can continue to ask questions about it on python-list, and
> continue to get answers.

No, they manage to work around issues. It doesn't mean there are no
bugs or bugfixes won't help. But I'm not going to argue with you, I
don't think you can be convinced about anything here.

>
> Stopping to apply bug fixes does not really *end* Python 2.7.
>
> It's only that people who *do* run into bugs don't have the option anymore
> that we will eventually publish a fixed release. Their options reduce to
> - port to 3.x (particularly interesting if Python 3.x *already* fixed it)
> - find a work-around
> - maintain a bug fix locally
> - do something else entirely (like abandoning Python)
>
> People deserve to know our plans, so we really need to agree on them and
> then announce them (see PEP 404). However, people (IMO) have no right to
> expect us to maintain Python 2.7 until they migrate to 3.x. If we would do
> that, they will never migrate.
>
> Regards,
> Martin

As far as I remember python 3 was supposed to be a better language,
not just "the maintained version". It's such a bad idea to force
people to go through porting because 2.x is not maintained any more.
If they never migrate on the premises of python 3 being a better
language what does it say about python 3?

I cannot of course tell you what you should do in your free time
though, if you don't feel like doing anything in that area, fine.
We'll maintain the stdlib of Python 2.7 past the 2 year mark though.

Cheers,
fijal

[mar...@v.loewis.de]

Quoting Lennart Regebro <reg...@gmail.com>:

> On Sun, Apr 7, 2013 at 7:11 AM, <mar...@v.loewis.de> wrote:
>> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
>> prophecy. Migration rate will certainly increase once we announce
>> an end of 2.7, and then again when the end is actually reached.
>
> Well... People are in general *stuck* on Python 2. They are not
> staying because they want to. So I'm not so sure migration rate will
> increase because an end is announced or reached.

I assume you say that because people rely on libraries that haven't
been ported (correct me if there are other reasons to be stuck).

With an announced end-of-life, I'm certain that migration rate will
increase, because people will now urge their suppliers, pointing
to the announcement. With Benjamin's proposed schedule, they would
still have two years for their suppliers to act. Even under my proposed
schedule, there would be plenty of time.

Also, this is all free software (at least most of it).
Nobody can *really* be stuck on a not-ported dependency, as they
could always port it themselves, and even fork if the developer
refuses to integrate the port (and you know that this actually
happens).

Regards,
Martin

[Stefan Behnel]

Maciej Fijalkowski, 07.04.2013 09:52:

> As far as I remember python 3 was supposed to be a better language,
> not just "the maintained version". It's such a bad idea to force
> people to go through porting because 2.x is not maintained any more.
> If they never migrate on the premises of python 3 being a better
> language what does it say about python 3?

Nothing. Most people simply don't do the switch all by themselves before
you can convince that that what they have in their hands is actually a dead
parrot.

Stefan

[Steven D'Aprano]

On 07/04/13 17:44, mar...@v.loewis.de wrote:
>> Martin, you guys are shooting yourself in a foot. Almost noone uses
>> python 3 in production, even at pycon, which is the more progressive
>> crowd. There is a giant group of people using python that are not as
>> vocal. While I bet some are using Python 3, Python 2 is incredibly
>> popular for the "long tail" of libraries and applications. How much is
>> 2.7 a burden? There are no major changes and it's pretty cool to
>> consider it "done".
>
> Indeed - hence I think it is just fine to stop applying bug fixes to it,
> as well. People for whom it works fine today apparently don't run into any
> significant bugs. They can happily continue to use it as-is for ten or more
> years. It will not go away just when we reduce changes to security fixes.
> It will remain available for download, the documentation will keep being
> online, people can continue to ask questions about it on python-list, and
> continue to get answers.

+1

On the python-list@ mailing list, we occasionally get posts from people
still using Python 2.3, and regularly from people on 2.5.

> Stopping to apply bug fixes does not really *end* Python 2.7.
>
> It's only that people who *do* run into bugs don't have the option anymore
> that we will eventually publish a fixed release. Their options reduce to
> - port to 3.x (particularly interesting if Python 3.x *already* fixed it)
> - find a work-around
> - maintain a bug fix locally
> - do something else entirely (like abandoning Python)

Or, if they have paid support from a vendor like Red Hat, hassle the vendor
for a fix. Speaking of 2.3, as I understand it Red Hat still offer paid
support for 2.3, which won't expire for a few more years, and security fixes
only for some years beyond that.

[By memory, which may not be entirely accurate.]



--
Steven

[Lennart Regebro]

On Sun, Apr 7, 2013 at 9:51 AM, <mar...@v.loewis.de> wrote:
> Quoting Lennart Regebro <reg...@gmail.com>:
>> Well... People are in general *stuck* on Python 2. They are not
>> staying because they want to. So I'm not so sure migration rate will
>> increase because an end is announced or reached.
>
> I assume you say that because people rely on libraries that haven't
> been ported (correct me if there are other reasons to be stuck).

Company policies that mean you are using old distros with no support
for Python 3 and not being allowed to install it from source is also a
reason, but yes, the main one being libraries/frameworks, yes.

> With an announced end-of-life, I'm certain that migration rate will
> increase, because people will now urge their suppliers, pointing
> to the announcement.

The suppliers are often people who are maintaining an open source
library of some sort. When I see questions on stackoverflow about
support for X on Python 3 I sometimes take a quick look of the state
of libraries, check out their mailing list etc. It's *always* a
problem of that the maintainers themselves are stuck on Python 2.7 or
earlier together with porting being problematic. I think Python 3.3
with the u'' literal is much more important for increased adoption
there than the end of life of 2.7 as it often makes porting much
easier. But even so sometimes API's needs to be changed, etc, so it
takes a big concerted effort of both the maintainers, and the few
people that are interested in porting it to Python 3. And when you get
one new person asking for Python 3 support every 6 months, that's just
not enough people.

That's the hangup IMO. Ending Python 2.7 will make no difference there
either good or bad, I think. We need to find other ways of improving
adoption.

As for the company policies, in theory it sounds like a good argument
that ending Python 2.7 would be incentive for these to change. But
these are often slow moving companies that are happy using outdated
software, and are clearly using it already, or they would be on
distros that *did* support Python 3 already. :-)

> Nobody can *really* be stuck on a not-ported dependency, as they
> could always port it themselves, and even fork if the developer
> refuses to integrate the port (and you know that this actually
> happens).

Yes, but time/money/knowledge is at a premium. Also self-confidence. A
lot of people probably think porting is much harder than it is. :-)

//Lennart

[Steven D'Aprano]

On 07/04/13 17:52, Maciej Fijalkowski wrote:
> If they never migrate on the premises of python 3 being a better
> language what does it say about python 3?

Very little. People stick with languages for all sorts of reasons,
including:

- It's what I know
- I don't like change
- That's what the client insists on
- That's what my boss insists on
- That's what the vendor provides
- That's what my web host provides
- I really love language X, but I need this *one* library that's only
available on language Y, so I'm stuck


I stuck with Python 1.5 for seven or eight years, and didn't migrate to
Python 2 until 2.3. Why? Because that's what came standard on my Linux
distro of choice.



--
Steven

[Maciej Fijalkowski]

On Sun, Apr 7, 2013 at 9:51 AM, <mar...@v.loewis.de> wrote:
>

> Quoting Lennart Regebro <reg...@gmail.com>:
>
>> On Sun, Apr 7, 2013 at 7:11 AM, <mar...@v.loewis.de> wrote:
>>>
>>> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
>>> prophecy. Migration rate will certainly increase once we announce
>>> an end of 2.7, and then again when the end is actually reached.
>>
>>
>> Well... People are in general *stuck* on Python 2. They are not
>> staying because they want to. So I'm not so sure migration rate will
>> increase because an end is announced or reached.
>
>
> I assume you say that because people rely on libraries that haven't
> been ported (correct me if there are other reasons to be stuck).
>

I'm stuck because I can't tell my users "oh, we didn't improve pypy
for the last year/6 months/3 months, because we were busy upgrading
sources you'll never see to python 3"

Cheers,
fijal

[Lennart Regebro]

On Sun, Apr 7, 2013 at 10:10 AM, Lennart Regebro <reg...@gmail.com> wrote:
> That's the hangup IMO. Ending Python 2.7 will make no difference there
> either good or bad, I think. We need to find other ways of improving
> adoption.

And to be clear: I am therefore not arguing *not* to end it. I just
don't think that doing so will increase Python 3 adoption. I think
that's a red herring.

I have little opinion on whether to announce an official end or not,
nor when. I think the burden of maintaining many branches is a much
better argument, and that it therefore probably should be decided by
the maintainers.

[Stefan Behnel]

Maciej Fijalkowski, 07.04.2013 10:12:
> On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:
>> Quoting Lennart Regebro:

>>> On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote:
>>>> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
>>>> prophecy. Migration rate will certainly increase once we announce
>>>> an end of 2.7, and then again when the end is actually reached.
>>>
>>> Well... People are in general *stuck* on Python 2. They are not
>>> staying because they want to. So I'm not so sure migration rate will
>>> increase because an end is announced or reached.
>>
>> I assume you say that because people rely on libraries that haven't
>> been ported (correct me if there are other reasons to be stuck).
>
> I'm stuck because I can't tell my users "oh, we didn't improve pypy
> for the last year/6 months/3 months, because we were busy upgrading
> sources you'll never see to python 3"

Why not? It's not like many people *see* PyPy's sources ever in their life,
but my guess is that most of your users will eventually end up *using*
those upgraded sources anyway. So those upgrades will also be an
improvement for most of them.

Stefan

[Maciej Fijalkowski]

On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel <stef...@behnel.de> wrote:
> Maciej Fijalkowski, 07.04.2013 10:12:
>> On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:
>>> Quoting Lennart Regebro:
>>>> On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote:
>>>>> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
>>>>> prophecy. Migration rate will certainly increase once we announce
>>>>> an end of 2.7, and then again when the end is actually reached.
>>>>
>>>> Well... People are in general *stuck* on Python 2. They are not
>>>> staying because they want to. So I'm not so sure migration rate will
>>>> increase because an end is announced or reached.
>>>
>>> I assume you say that because people rely on libraries that haven't
>>> been ported (correct me if there are other reasons to be stuck).
>>
>> I'm stuck because I can't tell my users "oh, we didn't improve pypy
>> for the last year/6 months/3 months, because we were busy upgrading
>> sources you'll never see to python 3"
>
> Why not? It's not like many people *see* PyPy's sources ever in their life,
> but my guess is that most of your users will eventually end up *using*
> those upgraded sources anyway. So those upgrades will also be an
> improvement for most of them.
>
> Stefan

Some of them, maybe.

Most people absolutely don't care. Most of my users are people who
want this 10% speed improvement rather than sources upgraded to a
different, supposedly better, language.

Cheers,
fijal

[Stefan Behnel]

Maciej Fijalkowski, 07.04.2013 10:37:

> On Sun, Apr 7, 2013 at 10:32 AM, Stefan Behnel wrote:
>> Maciej Fijalkowski, 07.04.2013 10:12:
>>> On Sun, Apr 7, 2013 at 9:51 AM, <martin...@v.loewis.de> wrote:
>>>> Quoting Lennart Regebro:
>>>>> On Sun, Apr 7, 2013 at 7:11 AM, <martin...@v.loewis.de> wrote:
>>>>>> Wrt. to the 3.x migration rate: I think this is a self-fulfilling
>>>>>> prophecy. Migration rate will certainly increase once we announce
>>>>>> an end of 2.7, and then again when the end is actually reached.
>>>>>
>>>>> Well... People are in general *stuck* on Python 2. They are not
>>>>> staying because they want to. So I'm not so sure migration rate will
>>>>> increase because an end is announced or reached.
>>>>
>>>> I assume you say that because people rely on libraries that haven't
>>>> been ported (correct me if there are other reasons to be stuck).
>>>
>>> I'm stuck because I can't tell my users "oh, we didn't improve pypy
>>> for the last year/6 months/3 months, because we were busy upgrading
>>> sources you'll never see to python 3"
>>
>> Why not? It's not like many people *see* PyPy's sources ever in their life,
>> but my guess is that most of your users will eventually end up *using*
>> those upgraded sources anyway. So those upgrades will also be an
>> improvement for most of them.
>

> Some of them, maybe.
>
> Most people absolutely don't care. Most of my users are people who
> want this 10% speed improvement rather than sources upgraded to a
> different, supposedly better, language.

My guess is that they don't care because they don't have a choice anyway.
If they want to use PyPy (because they care about this 10% speedup), then
they have to stick to Python 2 as of now. Extrapolating from that that they
wouldn't prefer writing Python 3 code if they could is a fallacy.

Stefan

[Maciej Fijalkowski]

You're completely missing what I said. I'm not arguing against
providing pypy3k and we're working on it. Then users can choose. I'm
arguing against me porting PyPy *source* to python3, which does not
affect the language they users are using. Those are two drastically
different scenarios. One is visible to users (and our plan is to
support both pypy and pypy3k for the forseeable future) and the other
is what developers see with really 0 visibility to the user.

Cheers,
fijal

[Stefan Behnel]

Maciej Fijalkowski, 07.04.2013 10:45:

> You're completely missing what I said. I'm not arguing against
> providing pypy3k and we're working on it. Then users can choose. I'm
> arguing against me porting PyPy *source* to python3, which does not
> affect the language they users are using. Those are two drastically
> different scenarios. One is visible to users (and our plan is to
> support both pypy and pypy3k for the forseeable future) and the other
> is what developers see with really 0 visibility to the user.

Then I don't see why that code would have to be changed at all. AFAIK, most
of PyPy isn't even written in (real) Python but in RPython, which is
essentially "the subset of Python 2.x that PyPy can translate statically".
Unless you deliberately and arbitrarily want to change RPython to be "the
subset of Python 3.x that PyPy can translate statically", the eventual
death of Python 2 shouldn't affect that code.

Stefan

[Nick Coghlan]

On Sun, Apr 7, 2013 at 6:01 PM, Steven D'Aprano <st...@pearwood.info> wrote:
> Or, if they have paid support from a vendor like Red Hat, hassle the vendor
> for a fix. Speaking of 2.3, as I understand it Red Hat still offer paid
> support for 2.3, which won't expire for a few more years, and security fixes
> only for some years beyond that.
>
> [By memory, which may not be entirely accurate.]

Correct, the system Python in RHEL 4 is 2.3 and that is still a
supported platform if you pay for the Extended Lifecycle Support
(until early next year you can still get extended support for RHEL
*3*, and I believe the system Python in that is 2.2). RHEL 5 ships
with 2.4 and RHEL 6 with 2.6 and those are both still in their regular
support period. The system Python version in the upcoming RHEL 7
release hasn't been formally announced yet, but it doesn't take a
genius to figure out what it is going to be when the system Python in
Fedora is currently still Python 2.7. I'll also note that regular
support for RHEL 6 doesn't end until 2020, and extended support in
2023, so even Python *2.6* should have commercial support available
for another decade, let alone 2.7.

These supported versions are also (or will also be) available for free
through CentOS, ScientificLinux and other Red Hat derivatives.

It actually isn't the bug fixes which I consider particularly
important in 2.7 - it's the build fixes (including the
cross-compilation support). As the IDLE team ramp up their efforts,
there may also be benefit in getting updated versions of IDLE into the
hands of beginners (remember, a huge amount of training is enterprise
focused, which isn't likely to switch to 3.x until after Red Hat does,
and that migration has barely started on the Fedora side - having the
installer and package management system written in Python means that
migration is likely to open up some fairly major cans of worms).

Python 2.7 is a mature, stable platform for software development.
Python 3.3 is *better* in most respects, but if you've already worked
around (or aren't affected by) the text model issues in 2.x, then most
of the cool features in 3.x are available as backported modules on
PyPI.

With the lifting of the language moratorium. 3.3 has taken us further
down the "carrot" path for migration (adding the more efficient
Unicode representation, the "yield from" notation, more memory
efficient objects, import system enhancements and the improved
exception hierarchy to the pre-existing carrot that is chained
exceptions).

3.4 will likely add even more carrots, as we take further advantage of
the cleaner code base that was gained in the 3.x migration.

I think it's quite reasonable for individual committers to decide how
much we want to worry about Python 2.7. I know I've fixed some bugs in
3.x and then left the issue open as still applicable to 2.7 (usually
because the bug affected some part of the code that changed in the
transition, so the backport isn't straightforward). I consider that a
reasonable thing for me, or any other committer, to do: leave issues
open as applicable to 2.7 rather than doing the backport immediately.
If someone else cares enough to backport it, great, otherwise the
issue is still there to indicate that the problem still exists in 2.7.

Regards,

Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Alfredo Solano Martínez]

I think the question average python users have is "What's in it for me?".
While the guts have undergone lots of changes, from the outside it is mostly
perceived as the unicode-by-default and the print function. As per Bret's talk
at pycon [1], speed is roughly the same, which is great, considering all the
new stuff, but not a compelling reason to change for Joe Programmer. Joe will
probably consider PyPy because "moar speez" is an easy sell, though.

In a way, python3 is victim of the success of python2. Inertia is a powerful
force, and honestly, most of the time python2 just works (easy to write, easy
to modify, fast enough). Maybe it's just a marketing problem, and more
examples of "things you can only do with python3" are needed. Or maybe for all
the good changes already there, it still needs a killer feature, i.e. the
proverbial elevator pitch, that sets it apart from its older brother.

Alfredo

[1] http://pyvideo.org/video/1730/python-33-trust-me-its-better-than-27

[Tshepang Lekhonkhobe]

On Sun, Apr 7, 2013 at 9:13 AM, Maciej Fijalkowski <fij...@gmail.com> wrote:
> For what is worth, we'll maintain the stdlib part of 2.7 past 2 years.

You mean 2 years beyond 2015 (assuming that will be end-of-bugfix date)?

PS: I only noticed you were talking about PyPy because I recognized
your name; others won't.

[Antoine Pitrou]

On Sun, 07 Apr 2013 18:11:03 +1000

Steven D'Aprano <st...@pearwood.info> wrote:

> On 07/04/13 17:52, Maciej Fijalkowski wrote:
> > If they never migrate on the premises of python 3 being a better
> > language what does it say about python 3?
>
> Very little. People stick with languages for all sorts of reasons,
> including:
>
> - It's what I know
> - I don't like change
> - That's what the client insists on
> - That's what my boss insists on
> - That's what the vendor provides
> - That's what my web host provides
> - I really love language X, but I need this *one* library that's only
> available on language Y, so I'm stuck

- It takes time to migrate a codebase.

Regards

Antoine.

["Martin v. Löwis"]

Am 07.04.13 00:37, schrieb Benjamin Peterson:
> What I like about 6 months is that its short enough, so we don't have
> feel bad about not taking a certain change; it can just be pushed to
> the next no-too-far-away release. A year is quite a while to wait for
> a fix to be released. It's also a nice timeframe for some
> distributions (looking at you, Ubuntu).

This means that we will see two-digit micro-releases, right (assuming
that there will be a few security releases)?

Regards,
Martin

["Martin v. Löwis"]

Am 07.04.13 11:46, schrieb Tshepang Lekhonkhobe:

> On Sun, Apr 7, 2013 at 9:13 AM, Maciej Fijalkowski <fij...@gmail.com> wrote:
>> For what is worth, we'll maintain the stdlib part of 2.7 past 2 years.
>
> You mean 2 years beyond 2015 (assuming that will be end-of-bugfix date)?

No, I think he means "beyond 2 years from now", i.e. "beyond 2015", i.e.
"after python-dev stops maintaining it", without any specific end
of that support.

Regards,
Martin

[Skip Montanaro]

I started writing this last night before the flurry of messages which
arrived overnight. I thought originally, "Oh, Skip, you're being too
harsh." But now I'm not so sure. I think you are approaching the
issue of 2.7's EOL incorrectly. Of those discussing the end of Python
2.7, how many of you still use it in your day-to-day work? Have any of
you yet to move to Python 3? It sounds like many people at PyCon are
still 2.x users.

Where I work (a trading firm that uses Python as just one of many
different pieces of technology, not a company where Python is the core
technology upon which the firm is based) we are only just now
migrating from 2.4 to 2.7. I can't imagine we'll have migrated to
Python 3 in two years. It's not like we haven't seen this coming, but
you can only justify moving so fast with technology that already
works, especially if, like Python, you use it with lots of other
packages (most/all of which themselves have to be ported to Python 3)
and in-house software.

I think the discussion should focus on who's left on 2.x and why, not,
"yeah, releases every six months for the next couple years ought to do
it."

Just my 2¢.

Skip

[Benjamin Peterson]

2013/4/7 "Martin v. Löwis" <mar...@v.loewis.de>:

> Am 07.04.13 00:37, schrieb Benjamin Peterson:
>> What I like about 6 months is that its short enough, so we don't have
>> feel bad about not taking a certain change; it can just be pushed to
>> the next no-too-far-away release. A year is quite a while to wait for
>> a fix to be released. It's also a nice timeframe for some
>> distributions (looking at you, Ubuntu).
>
> This means that we will see two-digit micro-releases, right (assuming
> that there will be a few security releases)?

With the current proposal, 2.7.8 in 2015 would be the last non-security release.

--
Regards,
Benjamin

[Benjamin Peterson]

2013/4/7 Skip Montanaro <sk...@pobox.com>:

> I started writing this last night before the flurry of messages which
> arrived overnight. I thought originally, "Oh, Skip, you're being too
> harsh." But now I'm not so sure. I think you are approaching the
> issue of 2.7's EOL incorrectly. Of those discussing the end of Python
> 2.7, how many of you still use it in your day-to-day work? Have any of
> you yet to move to Python 3? It sounds like many people at PyCon are
> still 2.x users.
>
> Where I work (a trading firm that uses Python as just one of many
> different pieces of technology, not a company where Python is the core
> technology upon which the firm is based) we are only just now
> migrating from 2.4 to 2.7. I can't imagine we'll have migrated to
> Python 3 in two years. It's not like we haven't seen this coming, but
> you can only justify moving so fast with technology that already
> works, especially if, like Python, you use it with lots of other
> packages (most/all of which themselves have to be ported to Python 3)
> and in-house software.
>
> I think the discussion should focus on who's left on 2.x and why, not,
> "yeah, releases every six months for the next couple years ought to do
> it."

This thread is about setting CPython release schedules, so that the
discussion focuses on that is unavoidable. :)

I don't think the bug fix releases of CPython are critically important
to the life of a Python version. Every 2.x version has survived much
longer than Python-dev has done bugfixes on it. As has been noted on
this thread, there will be commercial and apparently PyPy support for
2.7 long after cpython stops bug fixing it.


--
Regards,
Benjamin

[Christian Tismer]

On 07.04.13 03:54, Raymond Hettinger wrote:

On Apr 6, 2013, at 2:02 PM, Benjamin Peterson <benj...@python.org> wrote:

we need to talk about how many more 2.7 releases there are
going to be. At the release of 2.7.0, I thought we promised 5 years of
bugfix maintenance, but my memory may be fuddled. 

I don't we need to make any "promises" beyond 5 years,

but I also think it is likely the 2.7 will end-up being a 

long-term maintenance version of Python.

At this year's Pycon keynote, I surveyed the crowd (approx 2500 people)

and all almost everyone indicated that they had tried out Python 3.x

and almost no one was using it in production or writing code for it.

That indicates that Python 2.7 will continue to be important for a good

while.  

In addition,  the other implementations of Python (Jython, PyPy, GAE, 

and IronPython) are all at or nearly at Python 2.7.   So, continued

support will be needed for their users as well.

After 2.7.4, I expect that the pace of real bug fixes will slow down,

but that we'll continue to improve docs, add docstrings, update IDLE, etc.

IMO, it is premature to utter the phrase "the end of 2.7".

Better to say, "2.7 is stable and is expected to only have minor updates".

Future point releases probably ought to occur "on their own schedule"

whenever there are a sufficient number of changes to warrant a release,

or an important security fix, or whenever the release managers have time.

Raimond, although I think you are right, I don't think this statement helps
Python to move forward. Your vision is realistic, nevertheless I
think it is important to tell everybody that 2013 is the year to move
to Python 3.

If enough people like you, Alex, Dabeaz, etc are claiming that loudly enough, it will
eventually happen!

cheers - chris

-- 
Christian Tismer             :^)   <mailto:tis...@stackless.com>
Software Consulting          :     Have a break! Take a ride on Python's
Karl-Liebknecht-Str. 121     :    *Starship* http://starship.python.net/
14482 Potsdam                :     PGP key -> http://pgp.uni-mainz.de
phone +49 173 24 18 776  fax +49 (30) 700143-0023
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/

[Christian Tismer]

Hi Skip,

On 07.04.13 14:10, Skip Montanaro wrote:

I started writing this last night before the flurry of messages which
arrived overnight.  I thought originally, "Oh, Skip, you're being too
harsh."  But now I'm not so sure.  I think you are approaching the
issue of 2.7's EOL incorrectly. Of those discussing the end of Python
2.7, how many of you still use it in your day-to-day work? Have any of
you yet to move to Python 3?  It sounds like many people at PyCon are
still 2.x users.

Where I work (a trading firm that uses Python as just one of many
different pieces of technology, not a company where Python is the core
technology upon which the firm is based) we are only just now
migrating from 2.4 to 2.7. I can't imagine we'll have migrated to
Python 3 in two years.  It's not like we haven't seen this coming, but
you can only justify moving so fast with technology that already
works, especially if, like Python, you use it with lots of other
packages (most/all of which themselves have to be ported to Python 3)
and in-house software.

I think the discussion should focus on who's left on 2.x and why, not,
"yeah, releases every six months for the next couple years ought to do
it."

when I read this, I was slightly shocked. You know what?
"""
We are pleased to announce the release of Python 2.4, final on November 30, 2004.
"""

I know that companies try to save (time? money?) something by not upgrading
software, and this is extremely annoying.

In my own project, which is for a customer, I just managed to do the complete transition
from Python 2.7 to 3.3.
Well, this was relatively simple because there is just my boss to be convinced,
and myself, because honestly the 3.3 support is still not as good as needed.
But I think every employee (including you) can quite easily put some pressure
on his company by claiming that Python 2.x is a dead end, and everybody is
about to move on to 3.x.
This does not have to be true, I just recognize that by claiming it and doing it
with your projects, the movement becomes a reality. Just say that we all need to
move on and cannot care about companies that ignore this necessity.

I agree it is hard to push things forward, when certain tools are just supporting
2.x. My way to get over this is ranting, and porting some things, and claiming
it was a cake walk. A lie, but it helped.

my 2.01 cent -- chris

[Gregory P. Smith]

You're not looking at it from the users perspective.  They see:

"we are pleased to announce that RHEL 4 will be supported until the year 3325"

and continue to use everything that it ships with and only that.  its their own loss for not investing in maintaining infrastructure of their own rather than investing in a support contract from their vendor but it is a valid choice none the less.  it has nothing to do with what python-dev chooses to do release wise.

I think this thread has already settled the question that Benjamin set out to ask: it doesn't matter when we stop issuing bug fix releases of 2.7, users will exist long enough for even today's deniers to hate them for using an old version.

If Benjamin wants to see bug fix releases made for two years, great!  If not, no big deal either. We as python-dev are a bunch of volunteers and it is up to each one of us if we'll bother to continue back porting fixes or investigating bugs on 2.7 or not. I strongly suspect that many of us will only continue to do so as long as 2.7 is relevant to our day jobs.

We don't need to close the 2.7 branch to commits and bug fixes.  Ever.  But most of us will stop caring about making changes to it at some point.  For me that point is after 3.4.

my 3 cents,

-gps

[Georg Brandl]

Am 07.04.2013 14:10, schrieb Skip Montanaro:
> I started writing this last night before the flurry of messages which
> arrived overnight. I thought originally, "Oh, Skip, you're being too
> harsh." But now I'm not so sure. I think you are approaching the
> issue of 2.7's EOL incorrectly. Of those discussing the end of Python
> 2.7, how many of you still use it in your day-to-day work? Have any of
> you yet to move to Python 3? It sounds like many people at PyCon are
> still 2.x users.
>
> Where I work (a trading firm that uses Python as just one of many
> different pieces of technology, not a company where Python is the core
> technology upon which the firm is based) we are only just now
> migrating from 2.4 to 2.7. I can't imagine we'll have migrated to
> Python 3 in two years.

You won't have to. You've been using 2.4 for 4.5 years after its last
maintenance release (which was in December 2008), so by analogy you'll
have until 2019 to migrate away from Python 2.7.

<0.5wink>
Georg

[Stephen J. Turnbull]

Skip Montanaro writes:

> It sounds like many people at PyCon are still 2.x users.

I suspect we're all still 2.x users at some level.

But the question is not "where are the users?" It's "where do the
development resources come from?" Pretty clearly, the python-dev
crowd has voted with their keyboards. You don't see a lot of
complaints from committers about this policy. I gather the general
feeling is that at this point supporting Python 2.x is just work that
somebody else benefits from.

2.x's EOL was discussed in the past (the thread about "why no 2.8?"),
and what we observe is nobody coming forward to maintain Python 2 for
the fun of it. People not only work on Python 3 for the fun of it,
but they even port packages to Python 3 for the fun of it![1]

> Where I work [...] it's not like we haven't seen this coming, but

> you can only justify moving so fast with technology that already
> works,

But by the same token, you should be able to see quite a ways in
advance when it's going to stop working, and then you can decide how
you want to pay for what you'd been getting for free.

As far as I can see, this is a win-win situation for Python 2 users.
Stick with Python 2, which you get for free and has evolved into a
robust powerful language embedded in a very rich ecosystem of add-on
packages. It's open source, so you can maintain it yourself if
necessary -- but it mostly *won't* be necessary. Or migrate to Python
3, which you get for free, is a better language, and whose ecosystem
is advancing at a good clip. And it is much more fun to work with in
many ways.


Sorry-no-free-ponies-here-ly y'rs,


Footnotes:
[1] FVO "fun" including "people who have done me a good turn will be
happy to see this done".

[R. David Murray]

On Mon, 08 Apr 2013 00:25:12 +0900, "Stephen J. Turnbull" <ste...@xemacs.org> wrote:
> 2.x's EOL was discussed in the past (the thread about "why no 2.8?"),
> and what we observe is nobody coming forward to maintain Python 2 for
> the fun of it. People not only work on Python 3 for the fun of it,
> but they even port packages to Python 3 for the fun of it![1]

Indeed. As one of the people who regularly makes commits to Python,
I can say that not applying bug fixes to 2.7 will be a big relief.
Having to patch 2.7 roughly doubles the time it takes to commit a fix
(much more if the fix doesn't apply cleanly), and I find myself more and
more likely to say "well, it's been that way in Python2 for a long while,
fixing it there is more likely to break things than it is to improve
things, so let's not backport". Or, as gps said, just leaving the issue
open to see if anyone else is willing to put in the effort to backport it.

I am likely to continue to consider backporting fixes (I mostly do stdlib
stuff) until Benjamin stops issuing bugfix releases, but the bar for a
fix getting backported will continue to rise, and by the time of 3.4 my
behavior may well be almost indistinguishable from those who are deciding
to stop backporting fixes at the 3.4 boundary :)

As others have pointed out, we are not talking about the end of 2.7,
just of the end of python-dev doing 2.7 bugfix releases. 2.7 will live
on longer than even 2.3/2.4 did, I expect, and I personally have no
problem with that.

My primary customers *are* using Python3, by the way. But I and they
still use Python2 for lots of things, and will probably do so for a while
yet. So I can also speak from a customer/consultant perspective and say
that I have no problem with the impending end of 2.7 bugfix releases.
In fact (except for IDLE, which I don't use myself but I really want to
see improved), I would be fine if this *had* been the last 2.7 bugfix
release :)

--David

["Martin v. Löwis"]

Am 07.04.13 16:58, schrieb Gregory P. Smith:

> We don't need to close the 2.7 branch to commits and bug fixes. Ever.

I wouldn't want this to happen, actually. People making changes to the
2.7 branch will want to see them released some day. The expectation is
on the release people to actually make the releases. I personally want
to see a fixed date when I can stop making Windows releases of 2.7, and
uninstall Visual Studio 2008.

So when we (Benjamin specifically) announce an end to bug fixing 2.7,
I'd really like to see the branch closed for bug fixing. It may well
be that another clone of cpython is established that gets bugs fixed
(and perhaps even new features), but I would rather that branch not
be hg.python.org/cpython.

Regards,
Martin

[Stefan Behnel]

Christian Tismer, 07.04.2013 15:53:

> But I think every employee (including you) can quite easily put some pressure
> on his company by claiming that Python 2.x is a dead end, and everybody is
> about to move on to 3.x.
> This does not have to be true, I just recognize that by claiming it and
> doing it with your projects, the movement becomes a reality. Just say
> that we all need to move on and cannot care about companies that ignore
> this necessity.
>
> I agree it is hard to push things forward, when certain tools are just
> supporting 2.x. My way to get over this is ranting, and porting some
> things, and claiming it was a cake walk. A lie, but it helped.

+1, although I'd rather call it a self-fulfilling prophecy than a lie.

Stefan

[Guido van Rossum]

I have spent many years in industry working for large companies that
have big, successful internal Python code bases, with dependencies on
large numbers of external packages. From talking about colleagues
about migrating to new language versions, several issues come forward.
They all conspire to make it hard to move forward, but not impossible.

- A single external package that doesn't yet support the new version
can block migration until it has been ported or been replaced by
something else.

- Many third party packages change their API as they move forward
(sometimes they are forced by changes in the language). This means
trouble in the backwards compatibility department.

- A migration takes a lot of effort. You have to put several engineers
on it full-time who could otherwise be developing new features; and it
disturbs the development activities of many other engineers, who will
be asked to fix tests, decide whether something is still used, and so
on.

- There are probably parts of the codebase that depend extensively on
some feature that doesn't work in the new version, e.g. str/unicode
equivalency. Yes, that code is probably buggy, but it is heavily used,
and rewriting it means changing interfaces between different
components, which in turn requires more rewrites.

- There are probably different departments within the company that
move at different speeds. It is extremely difficult to get everyone to
switch at the same time. So you have to come up with some kind of
gradual transition plan, which will probably make the effort even more
work, by requiring backwards compatibility for some internal
interfaces.

- Even if everything goes extremely smoothly, you can still count on
some interruption of production -- outages, performance degradations,
all the things that end users notice and gripe about. The prospect of
this makes managers *very* uncomfortable.

But, despite all this, migrations happen all the time, and I am sure
that Python 3 will prevail as time progresses. For many *users*,
Python 3 may be a distraction. But for most *developers*, maintaining
2.7 is a distraction. By and large, users of 2.7 don't need new
features, they just need it to keep working. And it does, of course.
(At the risk of a flawed analogy: Windows XP is still the best version
of Windows for hardware built when XP was current.)

But perhaps we could change the focus for 2.7 development a bit:
instead of fixing bugs (or bickering about whether something is a bug
fix or a new feature) we could limit changes to ensuring that it works
on newer platforms. Martin mentioned that building 2.7 for Windows
with the same toolchain that was used for the 2.7.0 release is getting
more and more problematic. I'm not sure, but I could imagine similar
problems for future versions of OS X and even Linux (though the Linux
distributions typically take care of issues themselves).

There's not much of a point in fixing bugs that always existed in 2.7,
since must 2.7 users are by now used to working around these. However,
I do see a point in supporting builds targeting newer OS versions.
This won't be much of a relief for Martin, but it might be one of the
best ways to interpret "support" of Python 2.7 for the next several
years. I would also support having a 3rd party doing this and sell the
binaries for a small fee (ActiveState started out this way) -- but it
would still behoove us to have the necessary build files in the core
repo.

Some final words: if any of the alternate Python implementations
(IronPython, Jython, PyPy, even Cython) are feeling down on Python 3
because they do not have enough volunteers to help with the port (even
though at least for IronPython and Jython, the new str/bytes model is
much more suitable than the old), they should apply to the PSF for
funding. I believe PyPy is already in the process of doing so.

--
--Guido van Rossum (python.org/~guido)

[R. David Murray]

On Sun, 07 Apr 2013 11:48:28 -0400, "R. David Murray" <rdmu...@bitdance.com> wrote:
> (much more if the fix doesn't apply cleanly), and I find myself more and
> more likely to say "well, it's been that way in Python2 for a long while,
> fixing it there is more likely to break things than it is to improve
> things, so let's not backport". Or, as gps said, just leaving the issue

Having sent this, I noticed that it is actually a significant point that
no one else has raised out, and is worth emphasising.

When we fix bugs, there is always a backward compatibility estimation
that goes into the fix, and whether to even make the fix in the bug fix
release: what are the chances that fixing this bug will break currently
working code, versus the chances that currently broken code will start
working correctly? If the chance of breakage outweighs the good done,
we don't apply the fix to the maintenance release.

The longer that a maintenance release is in the field, the higher
the probability that fixing a bug will break existing working code.
So even *without* a set maintenance end date, the number of bug fixes
*should* decline over time.

Five years is a long time. By that point, even regardless of any
maintenance commitment concerns, it is probably best to stop fixing
anything except security bugs *anyway*, as a service to the user
community :)

["Martin v. Löwis"]

> But perhaps we could change the focus for 2.7 development a bit:
> instead of fixing bugs (or bickering about whether something is a bug
> fix or a new feature) we could limit changes to ensuring that it works
> on newer platforms. Martin mentioned that building 2.7 for Windows
> with the same toolchain that was used for the 2.7.0 release is getting
> more and more problematic.

For Windows, I don't see a way to achieve this. With the current setup
of the Microsoft C runtime library, we need to continue to build with
VS 2008 "forever", in the 2.7 branch. While it would be possible to
include project files for VS 2012 (and fix the few places where the code
doesn't work on VS 2012), this wouldn't help:

If we release 2.7.5 (say) built with VS 2012 (say), then existing
third-party extension modules may break (depending how precisely they
use the CRT). Likewise, if a user choses to rebuild Python with VS 2012
themselves, they really ought to rebuild all extension modules that they
use as well. They probably won't recognize this requirement, and then
debug difficult-to-understand issues.

IOW, to update the tool chain, we would really have to call it
python28.dll (or start with a new approach of calling it
python27vs11.dll, which would create distinct universes where
each extension needs to be built for each universe).

So I believe that extension building is becoming more and more
painful on Windows for Python 2.7 as time passes (and it is already
way more painful than it is on Linux), and I see no way to do much
about that. The "stable ABI" would have been a solution, but it's
too late now for 2.7.

Regards,
Martin

[Barry Warsaw]

On Apr 06, 2013, at 05:02 PM, Benjamin Peterson wrote:

>This means we need to talk about how many more 2.7 releases there are
>going to be.

I'm all for putting stakes in the ground and clearly describing the future
life of Python 2.7, rather than the current indefinite status quo. We talked
about this at Pycon, and a final maintenance release of 2.7 when 3.4 is
released, plus a few years of security-only source-only releases after that
seems entirely reasonable.

I would like to make a definitive statement as to 2.7's EOL because I think
that will spur more people to work on porting. Just as 3.3 makes porting
easier than 3.2, I expect that as more people see the writing on the wall, and
we've reached the Python 3 tipping point (e.g. "wos" now means "wall of
superpowers :) we'll get even more feedback on porting difficulties that can
be alleviated in 3.4. (Example, I was against re-adding the u-prefix, but I
was wrong!)

Thankfully, after October, I won't have to worry about 2.6 any more.

-Barry

[Barry Warsaw]

On Apr 06, 2013, at 06:54 PM, Raymond Hettinger wrote:

>At this year's Pycon keynote, I surveyed the crowd (approx 2500 people)
>and all almost everyone indicated that they had tried out Python 3.x
>and almost no one was using it in production or writing code for it.
>That indicates that Python 2.7 will continue to be important for a good
>while.

Now that porting has reached the top of the food chain (e.g. Twisted, Django)
I think these numbers will change. Some from porters, but also from new
projects which can start with a clean slate and avoid endless UncodeErrors and
rafts of other problems. This will produce downward pressure on lagging
libraries to adopt Python 3 or get left behind, and that should increase the
momentum. Python 3 *is* being used in production, but today it's limited to
new code bases and ports where all the dependencies are already there. Now
we're identifying key bottlenecks, such as (for us) Xapian, and places in the
language or libraries where more help is needed. Some bottlenecks have
already been fixed (e.g. for us, dbus and OAuth, where the most popular
library is already abandoned upstream for 4 years, but there is thankfully a
great replacement that's Python 3 compatible).

I talked to someone at Pycon who was still using Python 1.5, which is probably
older than some of the people on this list ;).

[Steven D'Aprano]

On 08/04/13 07:41, Barry Warsaw wrote:

> I talked to someone at Pycon who was still using Python 1.5, which is probably
> older than some of the people on this list ;).

Awesome! :-)

--
Steven

[Stephen J. Turnbull]

Barry Warsaw writes:

> I would like to make a definitive statement as to 2.7's EOL because
> I think that will spur more people to work on porting.

I have to agree with the people who say that it's not a major spur.
Internal support for existing Python 2.7 installations is by now quite
a bit less than a full-time job (at least the part corresponding to
what python-dev does for a version in late maintenance releases[1]).
I don't see how it makes the choice between sticking with 2.7
vs. contributing ports to 3.x more stark than it already is.

Of course it does free up core developer time, especially the release
engineers. In maintaining 2.7 past 2015, are core developers really
doing anything that a business can't do cheaply and with maximum
social benefit?[2]

Footnotes:
[1] Maybe the Windows build process brings it close to that order of
magnitude, if users are building internally. But this should be a
saleable product.

[2] It has been proved that open source development styles *do*
provide benefits *beyond* what business can profitably provide,
because of network externalities among developers and users,
especially the ability of user-developers to contribute. But these
benefits mostly disappear when the developer-vs-user externality
disappears because the spec is fixed, and the implementation 99.44%
corresponds to the spec.

[Nick Coghlan]

On Mon, Apr 8, 2013 at 12:58 AM, Gregory P. Smith <gr...@krypto.org> wrote:
> You're not looking at it from the users perspective. They see:
>
> "we are pleased to announce that RHEL 4 will be supported until the year
> 3325"
>
> and continue to use everything that it ships with and only that. its their
> own loss for not investing in maintaining infrastructure of their own rather
> than investing in a support contract from their vendor but it is a valid
> choice none the less. it has nothing to do with what python-dev chooses to
> do release wise.

Right, people pay companies like Red Hat* good money to support
ancient versions of open source software. Upstream doesn't want to do
that (because it's tedious and not at all interesting), and *they
don't have to*. If people want things that volunteers aren't
interested in providing, then they have the option to pay to get the
software they want on the platforms they want (note that in the later
parts of a supported product's life, even we don't support running
ancient versions of RHEL directly on new hardware - we only support
running it as a VM inside a supported hypervisor that supports the new
hardware).

* In case anyone in the thread isn't already aware of my multiple
perspectives on this issue, note that I work on internal tools
development for Red Hat these days.

> We don't need to close the 2.7 branch to commits and bug fixes. Ever. But
> most of us will stop caring about making changes to it at some point.

+1000

> For
> me that point is after 3.4.

In terms of most of the stuff I work on that isn't a new feature, it's
either obscure enough, different enough between 2.x and 3.x or close
enough to the "new feature" line that I don't really care about
getting it changed in 2.7. So for me personally, the "stop worrying
about fixing 2.7" point is mostly passed already (fixing aspects of
the 2.7 *ecosystem* is still thoroughly on my radar, but that's about
improving external tools, not CPython itself).

Cheers,

Nick.

--
Nick Coghlan | ncog...@gmail.com | Brisbane, Australia

[Terry Jan Reedy]

On 4/7/2013 2:02 PM, Guido van Rossum wrote:

> There's not much of a point in fixing bugs that always existed in 2.7,

I has been suggested that backporting bugfix patches from current 3.x to
2.7 will make it easier to port from the atest 2.7.x to 3.x. I have no
idea how true that is.

> since must 2.7 users are by now used to working around these.

An exception is Idle, where the workaround is to grit one teeth and
perhaps yell 'Idle is broken' or to switch to something else. With
PEP343 accepted, this is rapidly being worked on. NEWS for 2.7.5 already
has 8 Idle items. Most of the credit goes to Roger Serwy.

tjr

[Ned Deily]

In article
<CAP7+vJLZB5XL8cxbmibunniG...@mail.gmail.com>,
Guido van Rossum <gu...@python.org> wrote:
[...]

> But perhaps we could change the focus for 2.7 development a bit:
> instead of fixing bugs (or bickering about whether something is a bug
> fix or a new feature) we could limit changes to ensuring that it works
> on newer platforms. Martin mentioned that building 2.7 for Windows
> with the same toolchain that was used for the 2.7.0 release is getting
> more and more problematic. I'm not sure, but I could imagine similar
> problems for future versions of OS X and even Linux (though the Linux
> distributions typically take care of issues themselves).

That's an excellent point. In the OS X world, my sense is that OS and
build tool updates are adopted more quickly by users than in less
homogenous platform environments so we've tried to be be pragmatic about
supporting new releases of Xcode built tools in Python maintenance
branches like 2.7. For example, in 2.7.4 there were some significant
changes to building Python and to Distutils to support extension module
building with the latest Xcode releases. (That's not to say we are
always as timely as we should be.) I don't think there has been any
major disagreements that doing those kinds of limited changes for
platform support are in scope.

There have also been some changes to better support cross-building for
platforms that have become more strategically important, like ARM.
These have been more controversial but a good case can be made for
considering such changes as pragmatic long-term investments. It might
be a good idea to have a more formal policy in place going forward for
2.7.x.

Beyond build tools is the issue of the components that Python depends on
at runtime, primarily third-party libraries. Many of these are also
under active development, with schedules and compatibility criteria that
differ from those we use. In some cases, security issues will force the
rapid adoption of new versions, in other cases, widespread adoption on
the platforms we support will force this. Again, pragmatically, we'll
need to continue to track these components and support newer versions as
necessary in order for maintained versions of Python to remain viable.

(And we need to step up the activity in some areas. Tcl/Tk 8.6 is now
official and starting to be adopted. Tkinter and IDLE are intimately
dependent on Tk and, AFAIK, we don't really have anyone closely
following the changes there and their implications for Python.
Thankfully, Serhiy has been doing some work with 8.6 already.)

--
Ned Deily,
n...@acm.org

[Brett Cannon]

On Sat, Apr 6, 2013 at 5:02 PM, Benjamin Peterson <benj...@python.org> wrote:

Per my last message, 2.7.4 has at long last been released. I apologize
for the long interval between 2.7.3 and 2.7.4. To create more
determinism in the future, I will be soon updating PEP 373 with
approximate dates of future 2.7 bugfix releases. I will be aiming for
6 month intervals.

This means we need to talk about how many more 2.7 releases there are

going to be. At the release of 2.7.0, I thought we promised 5 years of

bugfix maintenance, but my memory may be fuddled. At any rate, 2.7.0
was released in July 2010, which currently puts us within a few months
of 3 years of maintenance. Over the past year, I've been happy to see
a lot of movement towards 3 including the porting of important
codebases like Twisted and Django. However, there's also no doubt that
2.x is still widely used. Obviously, there will be people who would be
happy if we kept maintaining 2.7 until 2025, but I think at this
juncture 5 total years of maintenance is reasonable. This means there
will be approximately 4 more 2.7 releases.

Thoughts?

Since this has ended up with roughly 50 responses, I'm going to try and summarize where things stand for my own benefit.

First off, core devs almost all seem fine with declaring an end date to maintaining 2.7 and seeing these last releases happen every 6 months (since Benjamin volunteered and I think Martin and Ned said they are fine with that as well and it's really their call). The question for EOL seems to be whether to do one more release after 3.4 goes out in early 2014 or to see 2.7 through until early 2015.

The other question seems to be whether we should lock down the branch so people don't think we will continue to accept patches and such (much like Georg has done with the 3.2 pre-commit hook).

So those two points -- where to draw the line and whether to mothball the branch -- seem to be the only open questions.

For me, I think a possible compromise might work out. What if we say python-dev will see patches backported until the release following 3.4, but after that the last two releases (which sees us into 2015 as Benjamin originally proposed) will only be patched by contributions from the community? IOW we make it very clear that python-dev considers themselves off the hook after 3.4 in terms of feeling obliged to backport any of their own code, but we are willing to examine and commit patches as provided by external contributors as long as they apply to all applicable branches. E.g. if someone wants something fixed in 2.7 after 3.4 is out they need to supply the patches for both 2.7 and 3.4 so that python-dev is doing nothing more than acting and gatekeepers on the repo and doing the commits on behalf of the patch writer. And then once the final 2.7 release is out we lock it down to make it abundantly clear that python-dev is entirely done with Python 2.

[Stephen Hansen]

On Sun, Apr 7, 2013 at 6:53 AM, Christian Tismer <tis...@stackless.com> wrote:

On 07.04.13 14:10, Skip Montanaro wrote:

Where I work (a trading firm that uses Python as just one of many
different pieces of technology, not a company where Python is the core
technology upon which the firm is based) we are only just now
migrating from 2.4 to 2.7. I can't imagine we'll have migrated to
Python 3 in two years.  It's not like we haven't seen this coming, but
you can only justify moving so fast with technology that already
works, especially if, like Python, you use it with lots of other
packages (most/all of which themselves have to be ported to Python 3)
and in-house software.

I think the discussion should focus on who's left on 2.x and why, not,
"yeah, releases every six months for the next couple years ought to do
it."

when I read this, I was slightly shocked. You know what?
"""
We are pleased to announce the release of Python 2.4, final on November 30, 2004.
"""

I know that companies try to save (time? money?) something by not upgrading
software, and this is extremely annoying.

I'm in the same boat as Skip (just now moving from 2.4 to 2.7), and Python *is* a core technology for us. It has nothing really to do with saving time or money, its about priorities. The transition from 2.3 to 2.4 was actually fairly painful (don't ask me why, I don't even remember anymore), but we got stuck on 2.4 not by any specific decision -- it simply worked, and our time was always focused upon solving problems and improving our software itself. 

Could we have solved our problems easier if we upgraded Python and had new tools? Some, yes. (Some features we have added had me actually walking through third party code bases and backporting it -- converting with to try/finally is an amusing big one for example)

For one thing, even with this relatively ancient Python, we almost never ran into bugs. It just worked and worked fine, so when we looked at our development plan the list of feature requests and issues for various customers (especially those that were potential new clients) overrode "infrastructure" upgrades as priorities. 

However, in a huge system that has many tens of thousands of lines of code, doing a platform upgrade is just a serious endeavor -- and its often not even Python's fault itself, but the reality that it means we're going to be upgrading *everything* and involves a much more involved QA cycle and often runs into third party software. We are finally upgrading now because the time to work around certain bugs in both Python and third-party libraries that no longer support 2.4 are enough for us to say, okay, we finally really do need to get this done. 

Migration to Python 3 ... IF it ever happens is more of a question then when.

That's not a indictment of Python 3 or a problem with the current plan (for what its worth, the bugfix every 6 months until 5 years is up seems totally reasonable). 

Any new product we do, I'd seriously consider starting from Python 3. (Though PyPy supporting Py3 would help that argument a lot) The case for migrating existing products is a lot harder to make.

But I think every employee (including you) can quite easily put some pressure
on his company by claiming that Python 2.x is a dead end, and everybody is
about to move on to 3.x.
This does not have to be true, I just recognize that by claiming it and doing it
with your projects, the movement becomes a reality. Just say that we all need to
move on and cannot care about companies that ignore this necessity.

The thing is, 2.7 works. Some third-party libraries we rely upon have no clear sign for when they will be ported (such as wxPython), and though we are transitioning away from certain others (omniORB for Apache Thrift for example), that process itself is planned to be a gradual thing for the next year, at least.

My concern is for the health of my company, and happiness of my customers; I love Python and am an advocate for it, but in my day job, pushing things forward is just about at the bottom of my list of concerns. (Though, our migration to 2.7 is actually part of a long term strategic plan to embrace pypy)

And now I go back to lurking.

--Stephen

[Mark Lawrence]

On 08/04/2013 16:42, Stephen Hansen wrote:
>
> The thing is, 2.7 works. Some third-party libraries we rely upon have no
> clear sign for when they will be ported (such as wxPython), and though
> we are transitioning away from certain others (omniORB for Apache Thrift
> for example), that process itself is planned to be a gradual thing for
> the next year, at least.
>

From http://wiki.wxpython.org/ProjectPhoenix "WooHoo! Phoenix runs on
Python 3!! "

>
> --Stephen
>

--
If you're using GoogleCrap™ please read this
http://wiki.python.org/moin/GoogleGroupsPython.

Mark Lawrence

[Giampaolo Rodolà]

2013/4/8 Stephen Hansen <me+p...@ixokai.io>:

You might also think about rewriting the code so that it "kind of"
works on both 2.7 *and* 3.3.
By that I mean that your code on Python 3 should not necessarily work
but neither it should raise SyntaxError.
If from the start you use:

- six
- "except exception as:"
- "__future__ module’s from __future__ import division,
print_statement, unicode_literals"
- fix warnings signaled by "python -3 app.py"

...and other similar tricks, your ported code is likely to look nicer
and more modern and a future porting to Python 3 should be a lot less
painful.
At least, if the circumstances are right, I personally might see some
value in doing so.


--- Giampaolo
https://code.google.com/p/pyftpdlib/
https://code.google.com/p/psutil/
https://code.google.com/p/pysendfile/

[Matthias Klose]

Am 07.04.2013 20:02, schrieb Guido van Rossum:
> But perhaps we could change the focus for 2.7 development a bit:
> instead of fixing bugs (or bickering about whether something is a bug
> fix or a new feature) we could limit changes to ensuring that it works
> on newer platforms. Martin mentioned that building 2.7 for Windows
> with the same toolchain that was used for the 2.7.0 release is getting
> more and more problematic. I'm not sure, but I could imagine similar
> problems for future versions of OS X and even Linux (though the Linux
> distributions typically take care of issues themselves).

I would like this new focus :-) Note that for 2.7.4 we did backport the bsddb
module to build with recent db-5.x versions, the embedded libffi library to
build on new platforms. I would like to see a backport for #17536 too, a change
to support new web browsers in an updated runtime environment.

I would like to continue to backport cross build changes to 2.7.x, before all
these people with Raspberry Pi's get too much annoyed about slow native builds.

Support for new targets should be allowed after a review.

> There's not much of a point in fixing bugs that always existed in 2.7,
> since must 2.7 users are by now used to working around these. However,
> I do see a point in supporting builds targeting newer OS versions.

The upcoming Ubuntu 13.04 release uses mostly Python 3.3.1 for the desktop
images, but still ships with Python 2.7.4 too on the images. For now most third
party modules and extensions still have to be available for both versions. For
now these binary packages (in the sense of a package in a Linux distribution)
are built for Python 2 and 3 from the same source package, so keeping the build
procedures and support about the same way helps with this approach.

Of course I can patch things locally, but would prefer to push these changes
upstream. At the language summit I was surprised to hear about a common subset
of backports for other vendor branches.

Matthias

[Skip Montanaro]

> If from the start you use:
> - six

...

There's the rub. We are not blessed with Guido's time machine where I
work. Much of the Python code we run was written long before six was
a gleam in anybody's eye. Heck, some of it was probably written
before some active members of python-dev graduated from high school.
:-)

I'm really amazed at how many people seem to have the impression that
porting to Python 3 should be no big deal. Please go back and read
Guido's post in this thread from yesterday. He identified many
barriers to moving between versions. This is not really a
Python-specific problem. All large organizations encounter this, and
wind up supporting lots of legacy code, long after its original
authors are gone. Go to monster.com and search for COBOL or Ada.

As I wrote in my previous message, we are only now moving from 2.4 to
2.7. If moving to Python 3 wasn't going to be much more difficult, I
think we would have attempted that. 2.7 Seemed like the better step
though, especially considering its compatibility with 2.4 and the fact
that it has a lot of things backported from Python 3 to ease the
eventual transition to Python 3.

Skip

[Tres Seaver]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/08/2013 04:40 PM, Skip Montanaro wrote:

> I'm really amazed at how many people seem to have the impression that
> porting to Python 3 should be no big deal.

FWIW, the effort of porting the "modern" bits of the Zope ecosystem (the
ones I still use in Pyramid apps today, meaning the component
architecture, the ZODB, and a few others) soaked up basically all of my
FLOSS time between the two Santa Clara PyCons.

To be fair, some of that effort went into improving test coverage, docs,
etc., to ensure that the apps running against the ported librarties
wouldn't break, even on Python2: but is was *not* a trivial effort.


Tres.
- --
===================================================================
Tres Seaver +1 540-429-0999 tse...@palladion.com
Palladion Software "Excellence by Design" http://palladion.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with undefined - http://www.enigmail.net/

iEYEARECAAYFAlFjMdYACgkQ+gerLs4ltQ62mACfSxdVNlTpSusR5MGMmuIw7lhf
3yIAoIJd6P8KoewUAjJnViuziWQWPHb8
=Bpul
-----END PGP SIGNATURE-----

[Barry Warsaw]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Apr 08, 2013, at 05:08 PM, Tres Seaver wrote:

>FWIW, the effort of porting the "modern" bits of the Zope ecosystem (the
>ones I still use in Pyramid apps today, meaning the component
>architecture, the ZODB, and a few others) soaked up basically all of my
>FLOSS time between the two Santa Clara PyCons.
>
>To be fair, some of that effort went into improving test coverage, docs,
>etc., to ensure that the apps running against the ported librarties
>wouldn't break, even on Python2: but is was *not* a trivial effort.

I've ported a ton of stuff, most of it not written by me. The actual job of
porting (not counting convincing your manager to let you do it) will either be
easy and quick or painful and difficult <wink>. It's often hard to know
before you start. It almost always comes down to bytes vs. strings, IME.
Sometimes, the code you're porting has a clear model and you just have to
understand it, and then the porting goes fairly smoothly. Often, the model
isn't clear or there *is* no distinction, in which case your life will suck.

It's important to realize that everyone doing porting work now is also making
Python 3 better by helping to find the pain points in the language and stdlib.
The u-prefix is a perfect example of this. .format() on bytes (issue3982) and
some of the discussions around issue17445 are two examples where we're at
least identifying additional pain, if not yet fixing it.

Python 3.3 is easier to port to than 3.2 is. I hope that we'll be able to
take all of our experiences and funnel that into 3.4 to make it a better
porting target still. Then, even though people will still be using Python 2
when Orlijn is BDFL, we'll at least be making progress. We also want to make
3.4 and future Python 3 releases so compelling that starting new projects in
Python 3 will be a no-brainer, and we want to make sure that the batteries,
both in the stdlib and 3rd party are up to the task.

Eventually Python 2 programmers will be like today's COBOL programmers (which
is good for future employment prospects :), but there's more Python 3 code out
there waiting to be written than there is existing Python 2 code today. :)
Don't worry about what you *can't* port!

- -Barry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIcBAEBCAAGBQJRYz8jAAoJEBJutWOnSwa/lsQP/jyIYBzfl9eDXw81Ar4t+Uls
7JOYfQqQXhMXL2f1XLHivCplhso0YBZn2ZepXJ9kLJ4SnO7bPZbo+esD99IoAlhG
QXjlvUnrSsc9mQG16HeuQLHjRmiZPg/mT+ACPuv3/ixxZggaKga7Jdcr2Xpo4KIS
89WzG2MWYhVGr3o28AAgSkSN/4fbmXRzjwmox0QjyhPdM6CWbTLO5KkF1cOLIXi/
UyYmlZAwSqVxR6cVRsGVwLStUy417UwZnc0h71IJxgRwgXOZDXzVKPvy/JqbVsK7
451aWB/mTkiaKkp+Qi0ebjZLLmSyEITS8DOurZKIy4Qfppyqy+patwazsY113zAg
wdexiFfFc2W4zLFflxTScqULFJulYyL7KzSsQBHPcou1G5nDUVXBXoM+AC71EBtd
TE+tyAhZWE38/mfDtOBCJCkJzevzJWF4tpGVgm1Gd5hSU7M8Yb2NQcZLYY0UxzZK
weDItJUYTSYEQh6j9nBlZGaX9v62SnXPlZaV2s9/bbVFsHekwYQcEAFlpGUqeUxi
KFFzS1GUl8IE8ZcHJDVW6U3YXzBSUKdSBa55IHw5hD+I730WAj8wq8aH7yFhyyzv
jyFRdhtEFhapnA2zpxogFGVLPRjl9iOphfVnUR6wNuh7q+226GsqHyaMbkWBM9Cb
sg39ITeWH6C0jMMxiGfx
=ZAcF

[Antonio Cavallo]

> It almost always comes down to bytes vs. strings, IME.

Cool, next time I have to port an extension written in C/C++ I'll be looking only for bytes vs. strings problems.
I knew it was easy.

Thanks

[a.ca...@cavallinux.eu]

;) there's the missing bit.

btw apologies if that looked offensive: it wasn't intended.


I disagree on "bilingual extension modules are easier".

While #ifdef can sort some issues (compiling ones mostly) it won't be
much of a help if a module crash (and not much help from testing
either).

In that case debugging it involves a lot of steps as gatering the
core dumps (if available), having a readily build python debug version,
a debugger and
restoring the crashing system in a similar state.
All these steps might not be possible at all (imagine a secured
production server).

I'm not saying it is not possible but the caused downtime can quickly
escalate
(think of it in days terms more than hours).

These are hidden costs to a company and it is hard to convince anyone
to agressively port something to 3.x
if it is reliably working on let's say 2.x: especially under time
pressure conditions.

On the bright side there's some success moving into 2.7: and we can all
make sure the move to 3.x will
be as small as possible in case in future time/policy constraints are
relaxed.

Thanks,
Antonio


On 2013-04-09 00:48, Barry Warsaw wrote:

> On Apr 08, 2013, at 11:32 PM, Antonio Cavallo wrote:
>
>>Cool, next time I have to port an extension written in C/C++ I'll be
>> looking
>>only for bytes vs. strings problems. I knew it was easy.
>

> Since I didn't see a smiley, I'll assume that wasn't sarcastic. ;)
>
> In some ways bilingual extension modules are easier because of
> #ifdef, but
> the general principle still holds. If you have a clear bytes v.
> strings
> story, it's not really that difficult to port extension modules
> either, at
> least IME.
>
> -Barry

[Sturla Molden]

On 07.04.2013 21:50, "Martin v. Löwis" wrote:

> So I believe that extension building is becoming more and more
> painful on Windows for Python 2.7 as time passes (and it is already
> way more painful than it is on Linux), and I see no way to do much
> about that. The "stable ABI" would have been a solution, but it's
> too late now for 2.7.

I think extension building for Python 2.7 on Windows for this reason is
moving from VS2008 to GCC 4.7 (MinGW). When using VS, we are stuck with
an old compiler (i.e. the .NET 3.5 SDK). With GCC, there is no such
issue - we just link with whatever CRT is appropriate. Thus, providing
link libraries for GCC/MinGW (both for the Python and the CRT DLL)
somewhat alleviates the problem, unless using VS is mandatory.

A long-term solution might be to expose the CRT used by the Python 2.7
DLL with DLL forwarding. That way, linking with the Python DLL's import
library would also link the correct CRT.

Sturla