Prev: IMAP Problems
Next: The real problem with Python 3 - no business case forconversion (was "I strongly dislike Python 3")
From: John Bokma on 7 Jul 2010 18:04
John Nagle <nagle(a)animats.com> writes:

> Python 3 is a nice cleanup of some legacy syntax issues. But
> that's just not enough. Perl 6 is a nice cleanup of Perl 5,

Eh, I wouldn't call Perl 6 a "nice cleanup". It's much better to
consider it a new language with roots in Perl 5 (amongst others). Or
to quote from http://dev.perl.org/perl6/:

"Perl 5 and Perl 6 are two languages in the Perl family, but of
different lineages."

> and look how that went. Ten years on, it's not even mainstream, let
> alone dominant.

I don't think that's the point of Perl 6 (if one can even say such a
thing, that is). Right now, (I) think of Perl 6 as a test bed for features
that couldn't be put in Perl 5 in an easy manner. Or (I) think of it as a
programming language lab.

My best guess is that with coming Christmas there will be a Perl 6
comparable to Python 3. But huge disclaimer: I hardly follow Perl 6
development.

--
John Bokma j3b

Hacking & Hiking in Mexico - http://johnbokma.com/
http://castleamber.com/ - Perl & Python Development
From: Ben Finney on 7 Jul 2010 21:14
geremy condra <debatem1(a)gmail.com> writes:

> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007brendan(a)gmail.com> wrote:
> > Python 3.x will continue to change.  The incompatibilities between
> > 3.x and 2.x will only become more numerous.  If your goal is to
> > support 2.x, and 3.x, you'd be best supporting them separately.
>
> I maintain two projects that have to work from 2.5 to 3.1. On one of
> them (~5kloc) we took the separate support route, and on the other
> (~30kloc) I decided to keep a single codebase. IME the maintenance
> burden on the former is substantially higher than the latter.

The point, one more time with feeling, is that the incompatibilities
between 2.x and 3.x will *increase* over time.

If you now have a code base that is relatively easy to maintain for both
Python 2.x and 3.x, that is a result of much back-porting efforts and of
a new-feature moratorium that is currently in effect. Enjoy that
situation as you may, because it is guaranteed not to last.

Indeed, the feature moratorium is designed in part to help slow-moving
codebases migrate to Python 3.x before Python resumes its normal pace of
change again. If you're choosing to use that time to further entrench
codebases for Python 2.x, I think that's a short-sighted choice.

Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
New 3.x features will begin to appear after the moratorium ends. The
combination of those two means that *the single-codebase burden will
only increase over time* as Python 3.x diverges further from what Python
2.x can support.

--
\ “Programs must be written for people to read, and only |
`\ incidentally for machines to execute.” —Abelson & Sussman, |
_o__) _Structure and Interpretation of Computer Programs_ |
Ben Finney
From: Paul Rubin on 7 Jul 2010 22:27
Ben Finney <ben+python(a)benfinney.id.au> writes:
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.

The issue is less the "incompatibilities" than the -backwards-
incompatibilities. Yes, Python 3 may introduce forward
incompatibilities by adding features absent from Python 2. But it will
be possible to maintain a common codebase simply by not using those
features. On the other hand, the door appears closed for Python 3
adding more stuff that breaks Python 2 code.

From: geremy condra on 7 Jul 2010 22:32
On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney <ben+python(a)benfinney.id.au> wrote:
> geremy condra <debatem1(a)gmail.com> writes:
>
>> On Wed, Jul 7, 2010 at 8:26 PM, Brendan Abel <007brendan(a)gmail.com> wrote:
>> > Python 3.x will continue to change.  The incompatibilities between
>> > 3.x and 2.x will only become more numerous.  If your goal is to
>> > support 2.x, and 3.x, you'd be best supporting them separately.
>>
>> I maintain two projects that have to work from 2.5 to 3.1. On one of
>> them (~5kloc) we took the separate support route, and on the other
>> (~30kloc) I decided to keep a single codebase. IME the maintenance
>> burden on the former is substantially higher than the latter.
>
> The point, one more time with feeling, is that the incompatibilities
> between 2.x and 3.x will *increase* over time.

....and? I don't get to use features from 2.7, why would I expect to
use features from 3.3?

> If you now have a code base that is relatively easy to maintain for both
> Python 2.x and 3.x, that is a result of much back-porting efforts and of
> a new-feature moratorium that is currently in effect. Enjoy that
> situation as you may, because it is guaranteed not to last.

I have to target the oldest version of Python I want to support. New
features are irrelevant. I'm not sure why I should need to explain
that to you.

> Indeed, the feature moratorium is designed in part to help slow-moving
> codebases migrate to Python 3.x before Python resumes its normal pace of
> change again. If you're choosing to use that time to further entrench
> codebases for Python 2.x, I think that's a short-sighted choice.

I welcome the day that I can stop supporting 2.x. Until then, I have to
support both and your argument is irrelevant.

> Python 2.7 is the last 2.x, no further 3.x features will be back-ported.
> New 3.x features will begin to appear after the moratorium ends. The
> combination of those two means that *the single-codebase burden will
> only increase over time* as Python 3.x diverges further from what Python
> 2.x can support.

See above.

Geremy Condra
From: Ben Finney on 7 Jul 2010 22:49
Paul Rubin <no.email(a)nospam.invalid> writes:

> Ben Finney <ben+python(a)benfinney.id.au> writes:
> > The point, one more time with feeling, is that the incompatibilities
> > between 2.x and 3.x will *increase* over time.
>
> The issue is less the "incompatibilities" than the -backwards-
> incompatibilities.

Yes, that's what I meant. Python 3 is deliberately under no obligation
to support code that works in Python 2. If something needs fixing, and
that fix would involve breaking Python 2 code, then that's not a
consideration any more.

The predictable result is that Python 3 will continue to gain
backward-incompatible changes in future.

> On the other hand, the door appears closed for Python 3 adding more
> stuff that breaks Python 2 code.

What gives you that idea? Can you reference a specific statement from
the PYthon developers that says that?

--
\ “Not to be absolutely certain is, I think, one of the essential |
`\ things in rationality.” —Bertrand Russell |
_o__) |
Ben Finney
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5
Prev: IMAP Problems
Next: The real problem with Python 3 - no business case forconversion (was "I strongly dislike Python 3")