Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #63381 > unrolled thread

Re: the Gravity of Python 2

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-07 11:19 +1100
    Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 13:54 +0100
      Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 17:07 +0100
        Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-07 17:42 +0100
          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-08 04:00 +1100
            Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 13:36 +0100
              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-08 23:46 +1100
                Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:08 +0100
              Re: the Gravity of Python 2 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-09 00:01 +1100
                Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:08 +0000
                Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:22 +0100
                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 02:39 +1100
                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 15:50 +0000
                  Re: the Gravity of Python 2 Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2014-01-09 08:55 +1100
              Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 09:15 -0500
                Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:30 +0000
                  Re: the Gravity of Python 2 Martijn Faassen <faassen@startifact.com> - 2014-01-08 16:26 +0100
                  Re: the Gravity of Python 2 Kevin Walzer <kw@codebykevin.com> - 2014-01-08 18:42 -0500
                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 20:27 -0500
                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 12:47 +1100
                        Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 21:25 -0500
                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 14:17 +1100
                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 22:35 -0500
                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:03 +1100
                                Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 23:29 -0500
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:34 +1100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:38 +1100
                                  Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-08 21:31 -0800
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 17:34 +1100
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 17:57 +1100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 18:56 +1100
                                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:14 -0500
                                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 01:57 +1100
                                        Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 08:21 -0800
                                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 16:30 +0000
                                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:07 -0800
                                              Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 18:20 +0000
                                              Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 10:29 -0800
                                          Re: the Gravity of Python 2 Tim Golden <mail@timgolden.me.uk> - 2014-01-09 16:41 +0000
                                          RE: the Gravity of Python 2 Nick Cash <nick.cash@npcinternational.com> - 2014-01-09 16:42 +0000
                                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 16:50 +0000
                                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 07:35 +1100
                                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 12:54 -0800
                                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 08:12 +1100
                                      Re: the Gravity of Python 2 Dan Sommers <dan@tombstonezero.net> - 2014-01-09 15:01 +0000
                                        Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 02:17 +1100
                                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 07:56 -0800
                                  Re: the Gravity of Python 2 Kushal Kumaran <kushal.kumaran@gmail.com> - 2014-01-09 11:36 +0530
                                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 08:53 +0000
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 20:03 +1100
                                  Re: the Gravity of Python 2 Kushal Kumaran <kushal.kumaran@gmail.com> - 2014-01-09 14:51 +0530
                                    Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 12:26 +0100
                                  Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 09:51 +0000
                                  Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-10 00:35 +1100
                                    Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:32 -0500
                          Re: the Gravity of Python 2 Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 14:34 +1100
                            Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-08 22:44 -0500
                          Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 14:42 +1100
                            Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 15:06 +0100
                              Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 01:34 +1100
                                Re: the Gravity of Python 2 Roy Smith <roy@panix.com> - 2014-01-09 09:44 -0500
                                Re: the Gravity of Python 2 Piet van Oostrum <piet@vanoostrum.org> - 2014-01-09 17:51 +0100
                                  Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-10 07:43 +1100
                          Time zones and why they change so damned often (was: the Gravity of Python 2) Ben Finney <ben+python@benfinney.id.au> - 2014-01-09 14:54 +1100
                          Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Chris Angelico <rosuav@gmail.com> - 2014-01-09 15:14 +1100
                            Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Peter Pearson <ppearson@nowhere.invalid> - 2014-01-10 18:22 +0000
                              Re: Time zones and why they change so damned often MRAB <python@mrabarnett.plus.com> - 2014-01-10 18:48 +0000
                              Re: Time zones and why they change so damned often Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-10 18:53 +0000
                                Re: Time zones and why they change so damned often Grant Edwards <invalid@invalid.invalid> - 2014-01-10 19:55 +0000
                                  Re: Time zones and why they change so damned often Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-10 19:45 -0500
                                  Re: Time zones and why they change so damned often Gene Heskett <gheskett@wdtv.com> - 2014-01-10 21:53 -0500
                              Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2014-01-10 19:43 -0500
                              Re: Time zones and why they change so damned often (was: the Gravity of Python 2) Roy Smith <roy@panix.com> - 2014-01-10 19:49 -0500
                          Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 07:10 +0000
                          Re: Time zones and why they change so damned often Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 07:17 +0000
                            Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-09 12:07 +0000
                              Re: Time zones and why they change so damned often Bob Martin <bob.martin@excite.com> - 2014-01-10 07:31 +0000
                                Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-10 09:04 +0000
                                  Re: Time zones and why they change so damned often Bob Martin <bob.martin@excite.com> - 2014-01-11 07:52 +0000
                                    Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:10 +0000
                                      Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:14 +0000
                                      Re: Time zones and why they change so damned often Alister <alister.ware@ntlworld.com> - 2014-01-11 11:14 +0000
                          Re: Time zones and why they change so damned often (was: the Gravity
 of Python 2) Dave Angel <davea@davea.name> - 2014-01-09 10:34 -0500
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-08 17:52 -0800
                      Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 13:09 +1100
                      Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 08:42 +0000
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 08:01 -0800
                      Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-09 18:18 +0000
                      Re: the Gravity of Python 2 Ethan Furman <ethan@stoneleaf.us> - 2014-01-09 10:33 -0800
                Re: the Gravity of Python 2 Pedro Larroy <pedro.larroy.lists@gmail.com> - 2014-01-08 15:45 +0100
                Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 01:50 +1100
                  Re: the Gravity of Python 2 Grant Edwards <invalid@invalid.invalid> - 2014-01-08 15:06 +0000
                    Re: the Gravity of Python 2 Chris Angelico <rosuav@gmail.com> - 2014-01-09 02:31 +1100
                Re: the Gravity of Python 2 Terry Reedy <tjreedy@udel.edu> - 2014-01-08 15:45 -0500
              Re: the Gravity of Python 2 Mark Lawrence <breamoreboy@yahoo.co.uk> - 2014-01-08 14:15 +0000

Page 1 of 5  [1] 2 3 4 5  Next page →

#63381 — Re: the Gravity of Python 2

On Tue, Jan 7, 2014 at 6:26 AM, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> http://blog.startifact.com/posts/python-2-gravity.html
>
> "A Way Forward - How to go forward then? I think it makes sense to work as
> hard as possible to lift those Python 2 codebases out of the gravity well."
>
> I think this is complete nonsense.  There's only been five years since the
> first release of Python 3.  Surely much more time should be made available
> for people using Python 2 to plan for a migration?

"""And to make it even more obvious, we need Python 2.x releases where
the deprecated stuff is removed, incrementally. Breaking code is
making it as obvious as you can get! But you don't want to break it
all at once, because then people will be inclined to give up before
they even start."""

Suppose there's a Python 2.8 that breaks just some of the things that
might break in 2.7->3.3 migration. What does it achieve?

1) Everything that has to be fixed before moving onto 3.3+ will still
need to be fixed.
2) Instead of ONE code-breaking shift with a major version number to
highlight it, there are now TWO code-breaking shifts.

Can we get a run-down of everything that actually must be broken in
2.7 -> 3.3, that can't be backported via __future__, so we can start
cherry-picking which bits to break in 2.8? The biggest one is going to
be Unicode strings, for a large number of people (the print statement
and division operators can be __future__'d, lots of other stuff got
backported into 2.7). I'd be prepared to bet money that that one will
NOT be broken in 2.8, meaning that it achieves nothing on that score.
So how much easier will the migration actually be?

ChrisA

[toc] | [next] | [standalone]

#63426

On 01/07/2014 01:19 AM, Chris Angelico wrote:

> Can we get a run-down of everything that actually must be broken in
> 2.7 -> 3.3, that can't be backported via __future__, so we can start
> cherry-picking which bits to break in 2.8? The biggest one is going to
> be Unicode strings, for a large number of people (the print statement
> and division operators can be __future__'d, lots of other stuff got
> backported into 2.7). I'd be prepared to bet money that that one will
> NOT be broken in 2.8, meaning that it achieves nothing on that score.
> So how much easier will the migration actually be?

That's a good question. I envision support for per-module upgrades, 
though I'm not 100% sure that it would work. This way a large project 
can incrementally start porting modules to the Python 3 unicode behavior.

The 'future' module (python-future.org) effectively backports the Python 
3 str and bytes into Python 2.7. The question is then what happens when 
they interact with Python 2 str and unicode.

I'm speculating about the behavior of the 'future' module here, but 
here's what I could imagine.

First the Python 3 behavior:

py3str + py3str = py3str

py3bytes + py3bytes = py3bytes

py3str + py3bytes = error

Then the behavior of when Python 3 str/bytes are mixed with Python 2 str 
and unicode:

py3str + py2unicode = py2unicode

py3str + py2str = py2unicode

py3bytes + py2str = py2str

Plus the regular old Python 2 behavior.

I'm quite sure I could be getting something wrong; it's only a few days 
since I saw 'future' and started thinking along these lines.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63432

Hi there,

I just tried this out with the future module to see what it actually 
does, and I got this:

On 01/07/2014 01:54 PM, Martijn Faassen wrote:

> First the Python 3 behavior:
>
> py3str + py3str = py3str

Yup, of course.

> py3bytes + py3bytes = py3bytes

Again of course.

> py3str + py3bytes = error

Yup, that's an error.

> Then the behavior of when Python 3 str/bytes are mixed with Python 2 str
> and unicode:
>
> py3str + py2unicode = py2unicode

This didn't work as I expected; I'd have expected py2unicode for 
compatibility reasons, as py3str cannot be combined with py2str (but in 
fact it *can*, odd).

> py3str + py2str = py2unicode

This in fact returns py3str, which I didn't expect either.

> py3bytes + py2str = py2str

And this gets me py3bytes.

I'll get in touch with the author of the 'future' module to try to 
understand why his reasoning is different from mine, i.e. where I'm wrong.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63435

Hi,

I've posted a documentation issue to the 'future' module which includes 
a further evolution of my thinking. As I expected, the author of the 
'future' module has thought this through more than I had:

https://github.com/PythonCharmers/python-future/issues/27

To get back to a hypothetical Python 2.8, it could implement this kind 
of behavior, and I think it would help support incremental upgrades. As 
long as you're using Py 3 bytes and str in your code, you'll be aware of 
errors and be forced to think about it. Other Python code in the system 
can remain unchanged, and to the magic of ducktyping will continue to 
work. You can then tackle things incrementally.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63439

On Wed, Jan 8, 2014 at 3:42 AM, Martijn Faassen <faassen@startifact.com> wrote:
> To get back to a hypothetical Python 2.8, it could implement this kind of
> behavior, and I think it would help support incremental upgrades. As long as
> you're using Py 3 bytes and str in your code, you'll be aware of errors and
> be forced to think about it. Other Python code in the system can remain
> unchanged, and to the magic of ducktyping will continue to work. You can
> then tackle things incrementally.

I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the
touted upgrade path is simply a Python 2.7 installer plus a few handy
libraries/modules that will now be preinstalled? These modules look
great (I can't say, as I don't have a huge Py2 codebase to judge based
on), and they presumably work on the existing Pythons.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63470

Hi there,

On 01/07/2014 06:00 PM, Chris Angelico wrote:
> I'm still not sure how Python 2.8 needs to differ from 2.7. Maybe the
> touted upgrade path is simply a Python 2.7 installer plus a few handy
> libraries/modules that will now be preinstalled? These modules look
> great (I can't say, as I don't have a huge Py2 codebase to judge based
> on), and they presumably work on the existing Pythons.

Well, in the original article I argue that it may be risky for the 
Python community to leave the large 2.7 projects behind because they 
tend to be the ones that pay us in the end.

I also argue that for those projects to move anywhere, they need a 
clear, blessed, official, as simple as possible, incremental upgrade 
path. That's why I argue for a Python 2.8.

Pointing out the 'future' module is existence proof that further 
incremental steps could be taken on top of what Python 2.7 already does.

I may be that these points are wrong or should be weighed differently. 
It's possible that:

* the risk of losing existing big 2.x projects is low, they'll port 
anyway, the money will keep flowing into our community, they won't look 
at other languages, etc.

* these big 2.x projects are going to all find the 'future' module 
themselves and use it as incremental upgrade path, so there's no need 
for a new blessed Python 2.x.

* the approach of the 'future' module turns out to be fatally flawed 
and/or doesn't really help with incremental upgrades after all.

But that's how I reason about it, and how I weigh things. I think the 
current strategy is risky.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63471

On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen <faassen@startifact.com> wrote:
> Well, in the original article I argue that it may be risky for the Python
> community to leave the large 2.7 projects behind because they tend to be the
> ones that pay us in the end.
>
> I also argue that for those projects to move anywhere, they need a clear,
> blessed, official, as simple as possible, incremental upgrade path. That's
> why I argue for a Python 2.8.
>
> Pointing out the 'future' module is existence proof that further incremental
> steps could be taken on top of what Python 2.7 already does.

Yep, but suppose it were simply that the future module is blessed as
the official, simple, incremental upgrade path. That doesn't violate
PEP 404, it allows the future module to continue to be expanded
without worrying about the PSF's schedules (more stuff might be added
to it in response to Python 3.5, but this is all in the hands of
future's maintainer), and it should be relatively simple to produce an
installer that goes and grabs it.

I'm all in favour of changes that don't require core support :) Let's
see how much can be done without touching the Python language in any
way at all. Maybe it'll turn out that there's some tiny change to
Python that would facilitate a huge improvement in commonality, but we
won't know without first trying to solve the problem under the
restriction of "there will be no Py2.8".

As Mark Rosewater is fond of saying, restrictions breed creativity.
Can the porting community take the PEP 404 restriction and be creative
within it? I suspect it'll go a long way.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63484

On 01/08/2014 01:46 PM, Chris Angelico wrote:
> On Wed, Jan 8, 2014 at 11:36 PM, Martijn Faassen <faassen@startifact.com> wrote:
>> Well, in the original article I argue that it may be risky for the Python
>> community to leave the large 2.7 projects behind because they tend to be the
>> ones that pay us in the end.
>>
>> I also argue that for those projects to move anywhere, they need a clear,
>> blessed, official, as simple as possible, incremental upgrade path. That's
>> why I argue for a Python 2.8.
>>
>> Pointing out the 'future' module is existence proof that further incremental
>> steps could be taken on top of what Python 2.7 already does.
>
> Yep, but suppose it were simply that the future module is blessed as
> the official, simple, incremental upgrade path. That doesn't violate
> PEP 404, it allows the future module to continue to be expanded
> without worrying about the PSF's schedules (more stuff might be added
> to it in response to Python 3.5, but this is all in the hands of
> future's maintainer), and it should be relatively simple to produce an
> installer that goes and grabs it.

That would be better than nothing, but would break the: "upgrade path 
should be totally obvious" guideline. Also the core developers are 
generally not in the habit of blessing external projects except by 
taking them into the stdlib, so that'd be a first.

> As Mark Rosewater is fond of saying, restrictions breed creativity.
> Can the porting community take the PEP 404 restriction and be creative
> within it? I suspect it'll go a long way.

How many actively maintained applications on Python 2.7 are being 
ported? Do we know? If not many, is this a problem? As problems also 
breed creativity.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63472

Martijn Faassen wrote:

> I also argue that for those projects to move anywhere, they need a
> clear, blessed, official, as simple as possible, incremental upgrade
> path. That's why I argue for a Python 2.8.

That incremental upgrade path is Python 2.7.

Remember, when Python 3 first came out, the current version of Python was
2.5. 2.6 came out roughly simultaneously with Python 3. So the expected
upgrade path is:


"Bleeding edge" adaptors:
2.5 -> 3.0

Early adaptors:
2.5 -> 2.6 -> 3.1 or 3.2

Slower adaptors:
2.5 -> 2.6 -> 2.7 -> 3.3 or 3.4

Late adaptors:
2.5 -> 2.6 -> 2.7 -> 3.5 (expected to be about 18-24 months)

Laggards who wait until support for 2.7 is dropped:
2.5 -> 2.6 -> 2.7 -> 3.6 or 3.7

Adding 2.8 doesn't help. It just gives people another excuse to delay
migrating. Then, in another two or three years, they'll demand 2.9, and put
it off again. Then they'll insist that 15 years wasn't long enough to
migrate their code, and demand 2.10.

I have no objection to people delaying migrating. There were lots of risks
and difficulties in migrating to 3.1 or 3.2, there are fewer risks and
difficulties in migrating to 3.3 and 3.4, and there will be even fewer by
the time 3.5 and 3.6 come out. People should migrate when they are
comfortable. They may even decide to stick to 2.7 for as long as they can
find a computer capable of running it, security updates or no security
updates. That's all fine.

What's not fine though is people holding the rest of us back with their
negativity and FUD that Python 3 is a mistake.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63475

On 08/01/2014 13:01, Steven D'Aprano wrote:
> Martijn Faassen wrote:
>
>> I also argue that for those projects to move anywhere, they need a
>> clear, blessed, official, as simple as possible, incremental upgrade
>> path. That's why I argue for a Python 2.8.
>
> That incremental upgrade path is Python 2.7.
>
> Remember, when Python 3 first came out, the current version of Python was
> 2.5. 2.6 came out roughly simultaneously with Python 3. So the expected
> upgrade path is:
>
>
> "Bleeding edge" adaptors:
> 2.5 -> 3.0
>
> Early adaptors:
> 2.5 -> 2.6 -> 3.1 or 3.2
>
> Slower adaptors:
> 2.5 -> 2.6 -> 2.7 -> 3.3 or 3.4
>
> Late adaptors:
> 2.5 -> 2.6 -> 2.7 -> 3.5 (expected to be about 18-24 months)
>
> Laggards who wait until support for 2.7 is dropped:
> 2.5 -> 2.6 -> 2.7 -> 3.6 or 3.7
>
> Adding 2.8 doesn't help. It just gives people another excuse to delay
> migrating. Then, in another two or three years, they'll demand 2.9, and put
> it off again. Then they'll insist that 15 years wasn't long enough to
> migrate their code, and demand 2.10.
>
> I have no objection to people delaying migrating. There were lots of risks
> and difficulties in migrating to 3.1 or 3.2, there are fewer risks and
> difficulties in migrating to 3.3 and 3.4, and there will be even fewer by
> the time 3.5 and 3.6 come out. People should migrate when they are
> comfortable. They may even decide to stick to 2.7 for as long as they can
> find a computer capable of running it, security updates or no security
> updates. That's all fine.
>
> What's not fine though is people holding the rest of us back with their
> negativity and FUD that Python 3 is a mistake.
>
>

Big +1 from me to all the above.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63487

Hey,

I'm pointing out possible improvements that Python 2.8 could offer that 
would help incremental porting efforts of applications. I'm pointing 
about that helping application developers move forward incrementally may 
be a worthwhile consideration. Like, there's money there.

You can point out that 2.6 and 2.7 were already such releases, and I 
will then point out that many people *have* upgraded their applications 
to these releases. Is there now going to be a giant leap forward to 
Python 3 by these projects, or is the jump still too far? Opinions differ.

On 01/08/2014 02:01 PM, Steven D'Aprano wrote:
> Adding 2.8 doesn't help. It just gives people another excuse to delay
> migrating. Then, in another two or three years, they'll demand 2.9, and put
> it off again. Then they'll insist that 15 years wasn't long enough to
> migrate their code, and demand 2.10.

I can play this kind of rhetorical game too, including demands and such 
fun. Who is demanding who does what?

It's not really a surprise that people expect there to be a compatible 
release of a programming language. We'll have to see whether the demand 
for it is strong enough to tear out community apart, or whether all will 
be right in the end.

> What's not fine though is people holding the rest of us back with their
> negativity and FUD that Python 3 is a mistake.

That's not what I believe I've been doing. Though if people do this, is 
the Python community really so fragile it can't deal with a little bit 
of pushback?

What's not fine is that people who think all is well tell the people who 
disagree to shut up. Maybe we should introduce the concept of "check 
your Python 3 privilege".

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63490

On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen <faassen@startifact.com> wrote:
> I'm pointing out possible improvements that Python 2.8 could offer that
> would help incremental porting efforts of applications. I'm pointing about
> that helping application developers move forward incrementally may be a
> worthwhile consideration. Like, there's money there.

I'm not sure who's actually paying the PSF to develop a 2.8, so I'm
not sure why you can say there's money there. Are you offering? Or do
you have reason to believe someone else will?

> You can point out that 2.6 and 2.7 were already such releases, and I will
> then point out that many people *have* upgraded their applications to these
> releases. Is there now going to be a giant leap forward to Python 3 by these
> projects, or is the jump still too far? Opinions differ.

Still waiting for a solid suggestion as to what would actually be
different in 2.8 that can't be done with a module. If there's a really
brilliant module that massively eases the burden of porting, then
python.org / the PSF might well even add it to the stdlib, or at least
point people to it from the home page. That would make for an
excellent "smooth upgrade" path, dealing with the renamed modules and
so on, and it takes no language changes at all.

I'm pretty sure most people here are in broad agreement with your goal
of making it easy to migrate to Py3. What we're not seeing - or at
least, what I'm not seeing - is how a Python 2.8 would achieve that;
and what several of us ARE seeing is how a Python 2.8 actually makes
it harder.

ChrisA

[toc] | [prev] | [next] | [standalone]

#63491

On 08/01/2014 15:39, Chris Angelico wrote:
> On Thu, Jan 9, 2014 at 2:22 AM, Martijn Faassen <faassen@startifact.com> wrote:
>> I'm pointing out possible improvements that Python 2.8 could offer that
>> would help incremental porting efforts of applications. I'm pointing about
>> that helping application developers move forward incrementally may be a
>> worthwhile consideration. Like, there's money there.
>
> I'm not sure who's actually paying the PSF to develop a 2.8, so I'm
> not sure why you can say there's money there. Are you offering? Or do
> you have reason to believe someone else will?
>

There can be £1,000,000 in the PSF kitty but if the core developers 
don't want to do the work it won't happen!!!

Personally I still think the whole idea of a 2.8 is nonsense that would 
only serve to divert already scarce resources.  Fixing some of the 4,000 
(?) open issues on the bug tracker would come higher up my list, 
particularly as some of them have been sitting there for ten years.  Or 
how about finally getting the "new" regex module into the standard library?

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63525

Martijn Faassen wrote:

> Hey,
> 
> I'm pointing out possible improvements that Python 2.8 could offer that
> would help incremental porting efforts of applications. I'm pointing
> about that helping application developers move forward incrementally may
> be a worthwhile consideration. Like, there's money there.

Why don't you grab it? If you think people will pay for somebody to backport
Python 3 to Python 2.8, just go ahead and do it and rake the money in.
Python is open source, you don't have to ask anyone's permission. The only
thing you may not be able to do is call it "Python 2.8", but the name isn't
important.


> You can point out that 2.6 and 2.7 were already such releases, and I
> will then point out that many people *have* upgraded their applications
> to these releases. Is there now going to be a giant leap forward to
> Python 3 by these projects, or is the jump still too far? Opinions differ.

It's not a giant leap. 95% of the migration can be handled by a relatively
simple script, 2to3. The hardest part is supporting 2 *and* 3 in a single
project, but for end-user applications that target a single Python version,
rather than libraries and frameworks that target many different versions,
migrating is a once-off cost, and for most apps, not a large one.

Certainly much less than re-writing the app in another language.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#63477

As somebody who is still firmly in the 2.x world, I'm worried about the 
idea of a 2.x fork.  While I have my doubts that 3.x was a good idea, 
the fact is, it's here.  Having the community fractured between the two 
camps is not good.  Let's say I'm somebody who wants to contribute some 
OSS.  I have three basic choices:

1) I can make it 3.x only.  Now, (nominally) half of the python 
community is unable to realize value from my contribution.

2) I can make it 2.x only.  Same thing in reverse.

3) I can make it work on both 2.x and 3.x, which means I'm investing 
more effort than I had to if it were single platform.

Any of those alternatives is worse than ideal.  Forking 2.x to create an 
unofficial 2.8 release would just prolong the situation.  As I've stated 
before, I don't see any urgency in moving to 3.x, and don't imagine 
doing there for another couple of years, but I absolutely can't imagine 
moving to a 2.8 fork.

[toc] | [prev] | [next] | [standalone]

#63479

On 08/01/2014 14:15, Roy Smith wrote:
> As somebody who is still firmly in the 2.x world, I'm worried about the
> idea of a 2.x fork.  While I have my doubts that 3.x was a good idea,
> the fact is, it's here.  Having the community fractured between the two
> camps is not good.  Let's say I'm somebody who wants to contribute some
> OSS.  I have three basic choices:
>
> 1) I can make it 3.x only.  Now, (nominally) half of the python
> community is unable to realize value from my contribution.
>
> 2) I can make it 2.x only.  Same thing in reverse.
>
> 3) I can make it work on both 2.x and 3.x, which means I'm investing
> more effort than I had to if it were single platform.
>
> Any of those alternatives is worse than ideal.  Forking 2.x to create an
> unofficial 2.8 release would just prolong the situation.  As I've stated
> before, I don't see any urgency in moving to 3.x, and don't imagine
> doing there for another couple of years, but I absolutely can't imagine
> moving to a 2.8 fork.
>

The above strikes me as common sense.  Surely that's out of place on 
this list? :)

But to be serious why not stick with 2.x if there's no compelling reason 
to move?  Whatever happened to "if it ain't broke, don't fix it"?  And 
before anyone says anything please don't start on about the bytes versus 
string debate, I'm fairly certain that there are a substantial number of 
application areas that don't run into these problems.

-- 
My fellow Pythonistas, ask not what our language can do for you, ask 
what you can do for our language.

Mark Lawrence

[toc] | [prev] | [next] | [standalone]

#63488

Hey,

On 01/08/2014 03:30 PM, Mark Lawrence wrote:

> But to be serious why not stick with 2.x if there's no compelling reason
> to move?  Whatever happened to "if it ain't broke, don't fix it"?

That's fine for static applications that don't have to change.

Successful applications tend to grow new features over the years. It's 
not fun to do so if new capabilities are growing out of reach in Python 
3 land.

It's possible if enough features exist in Python 3 land bosses of 
successful applications will fund a port, with all the risks of 
introducing bugs that this entails. But a smoother upgrade path would 
help those applications more. And as I pointed out before, these 
applications are where a lot of money and development resources are 
coming from in our community.

Of course it's possible my assessment of the importance of these 
applications, their development resources, and the bump a Python 3 port 
presents for them, is off.

Regards,

Martijn

[toc] | [prev] | [next] | [standalone]

#63536

On 1/8/14, 9:30 AM, Mark Lawrence wrote:
> But to be serious why not stick with 2.x if there's no compelling reason
> to move?  Whatever happened to "if it ain't broke, don't fix it"?  And
> before anyone says anything please don't start on about the bytes versus
> string debate, I'm fairly certain that there are a substantial number of
> application areas that don't run into these problems.

+1 to this.

I haven't updated my Python apps to 3.x because there's nothing in 3.x 
that offers benefits to my users.

I deal with constant API churn as a Mac developer. I have no interest in 
adding to this complexity and headaches by switching from 2.x to 3.x.

I imagine I'll update someday, but not anytime soon.

--Kevin

-- 
Kevin Walzer
Code by Kevin/Mobile Code by Kevin
http://www.codebykevin.com
http://www.wtmobilesoftware.com

[toc] | [prev] | [next] | [standalone]

#63550

In article <laknps$umv$1@dont-email.me>,
 Kevin Walzer <kw@codebykevin.com> wrote:

> I haven't updated my Python apps to 3.x because there's nothing in 3.x 
> that offers benefits to my users.

I almost found a reason to move to Python 3 today.  Then I got smacked.

I had a datetime.  I needed a unix timestamp.  People need to go back 
and forth between these two things all the time and in Python 2 it's the 
very definition of impedance mismatch.  What should be a dead simple 
operation involves long threads on stackoverflow discussing which of 
several amalgamations of duct tape is the least ugly.

Anyway, I discovered that Python 3.3's datetime has a .timestamp() 
method.  Yeah.  Finally.  Exactly what the world had needed for years.  
Then I kept reading and found:

Note: There is no method to obtain the POSIX timestamp directly from a 
naive datetime instance representing UTC time.

Ugh.  So, we're back to square one.  They go on to suggest one of two 
workarounds, either calling datetime.replace() to insert a timezone, or 
subtracting from the epoch manually.

Naive datetimes are what everybody uses.  It's what utcnow() gives you.  
So why make life difficult for everybody?  Python 3 didn't win a convert 
today.

[toc] | [prev] | [next] | [standalone]

#63552

On Thu, Jan 9, 2014 at 12:27 PM, Roy Smith <roy@panix.com> wrote:
> Anyway, I discovered that Python 3.3's datetime has a .timestamp()
> method.  Yeah.  Finally.  Exactly what the world had needed for years.
> Then I kept reading and found:
>
> Note: There is no method to obtain the POSIX timestamp directly from a
> naive datetime instance representing UTC time.

In my experiments (admittedly with 3.4, not 3.3, but I don't know that
there's any difference), I was able to round-trip a time_t through
datetime with no problems. Why not simply use a UTC datetime instead
of a naive one? What do you gain by using a naive datetime? You seem
to know what timezone it's in anyway.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 1 of 5  [1] 2 3 4 5  Next page →

Back to top | Article view | comp.lang.python

csiph-web