Prev: IMAP Problems
Next: The real problem with Python 3 - no business case forconversion (was "I strongly dislike Python 3")
From: Ben Finney on 7 Jul 2010 23:32
geremy condra <debatem1(a)gmail.com> writes:

> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney <ben+python(a)benfinney.id.au> wrote:
> > [backward-]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?

Conversely, why would you support Python 3.1?

> > 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.

Why do you have to support Python 3 at all? Will you expect to continue
maintaining a single code base that supports PYthon 2.x and Python 3.2,
then 3.3, and so on?

The only point being made here is to answer the question of why people
are saying that a single code base for both 2.x and 3.x is a maintenance
burden. If, in your case, at the present time, that's not the case, then
good for you! But it will get increasingly harder to do, and the reasons
why have now been explained. Apply them as you see fit.

--
\ “I'm a born-again atheist.” —Gore Vidal |
`\ |
_o__) |
Ben Finney
From: Paul Rubin on 7 Jul 2010 23:49
Ben Finney <ben+python(a)benfinney.id.au> writes:
>> 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?

It's just logic. As I understand it, future versions of Python 3 are
supposed to not break programs that work under current versions of
Python 3. So any Python 2 program that is a valid Python 3 program
today has to stay valid.
From: geremy condra on 7 Jul 2010 23:52
On Wed, Jul 7, 2010 at 11:32 PM, Ben Finney <ben+python(a)benfinney.id.au> wrote:
> geremy condra <debatem1(a)gmail.com> writes:
>
>> On Wed, Jul 7, 2010 at 9:14 PM, Ben Finney <ben+python(a)benfinney.id.au> wrote:
>> > [backward-]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?
>
> Conversely, why would you support Python 3.1?

Because in 10 years the percentage of people who have Python 2.x
installed will be the same as the percentage that have Python 1.x
installed today.

>> > 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.
>
> Why do you have to support Python 3 at all?

See above.

> Will you expect to continue
> maintaining a single code base that supports PYthon 2.x and Python 3.2,
> then 3.3, and so on?

Yes, with the occasional feature or bugfix. Is there an alternate
interpretation I'm missing?

> The only point being made here is to answer the question of why people
> are saying that a single code base for both 2.x and 3.x is a maintenance
> burden. If, in your case, at the present time, that's not the case, then
> good for you! But it will get increasingly harder to do, and the reasons
> why have now been explained. Apply them as you see fit.

I see you stating that it will become harder but I don't see why that
should be the case.

Geremy Condra
From: Terry Reedy on 7 Jul 2010 23:52
On 7/7/2010 9:14 PM, Ben Finney wrote:

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

For the purpose of maintaining least-common-denominator multi-version
code, it is only deletions and semantic changes that matter. Feature
additions will be more common, at least for awhile. The problem of
backporting 3.x code that uses 3.x features definitely will increase.


--
Terry Jan Reedy

From: Terry Reedy on 8 Jul 2010 00:11
On 7/7/2010 10:49 PM, Ben Finney wrote:

> 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.

Code that works in 3.1 *is* 3.1 code. Leaving aside bug fixes and
additions that makes code that once raised an exception do something
instead, I do not know that 3.1 broke and 3.0 code and I do not know of
any deprecations in 3.1 that will become removals in 3.2.

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

For the core syntax, not too likely. In any case, the usually 3 version
pending-deprecation, deprecation, removal process would apply. Some of
the library modules that do not work well for 3.1 will see more changes.

>> 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?

3.0 was stated to be a special case. I will let you look.

--
Terry Jan Reedy

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")