Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Python: Dev

Backporting PEP 414

 

 

Python dev RSS feed   Index | Next | Previous | View Threaded


ethan at stoneleaf

Feb 28, 2012, 12:27 PM

Post #1 of 16 (404 views)
Permalink
Backporting PEP 414

Here's what I know:

We don't add features to bug-fix releases.
u'' is considered a feature.
By not backporting to 3.1 and 3.2 we are not easing the migration pains
from 2.x.


Here's what I don't know:

Why is readding u'' a feature and not a bug? (Just had a thought about
this -- because the removal of u'' is documented.)

To take a different example: callable() had been removed from 3.0, and
was added back in 3.2. callable() is not a big deal as you can roll
your own quite easily -- and that is the huge difference: a user
*cannot* add u'' back to 3.0/3.1 (at least, not without modifying and
rebuilding the Python interpreter source).


If there is already a FAQ entry feel free to point me to it, but I would
still be curious why, in this instance, practicality does not beat purity?

My apologies if this type of question has been rehashed before.

~Ethan~
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


benjamin at python

Feb 28, 2012, 12:54 PM

Post #2 of 16 (388 views)
Permalink
Re: Backporting PEP 414 [In reply to]

2012/2/28 Ethan Furman <ethan [at] stoneleaf>:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.
>
>
> Here's what I don't know:
>
> Why is readding u'' a feature and not a bug?  (Just had a thought about this
> -- because the removal of u'' is documented.)

Because it's a new "thing" which doesn't fix obviously broken behavior.

>
>
> If there is already a FAQ entry feel free to point me to it, but I would
> still be curious why, in this instance, practicality does not beat purity?

Because it's practical not to break bugfix releases with new features.


--
Regards,
Benjamin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


brian at python

Feb 28, 2012, 12:59 PM

Post #3 of 16 (392 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Tue, Feb 28, 2012 at 14:27, Ethan Furman <ethan [at] stoneleaf> wrote:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.

Let's say it's 2013 and 3.3 has been out for a few months and you want
to port your library to Python 3. Why would you worry about 3.1 or
3.2?

You certainly see why we're not worried about 3.0.
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


chrism at plope

Feb 28, 2012, 1:23 PM

Post #4 of 16 (388 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
> 2012/2/28 Ethan Furman <ethan [at] stoneleaf>:
> > Here's what I know:
> >
> > We don't add features to bug-fix releases.
> > u'' is considered a feature.
> > By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> > 2.x.
> >
> >
> > Here's what I don't know:
> >
> > Why is readding u'' a feature and not a bug? (Just had a thought about this
> > -- because the removal of u'' is documented.)
>
> Because it's a new "thing" which doesn't fix obviously broken behavior.
>
> >
> >
> > If there is already a FAQ entry feel free to point me to it, but I would
> > still be curious why, in this instance, practicality does not beat purity?
>
> Because it's practical not to break bugfix releases with new features.

This change, by its nature, cannot break old programs.

- C


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


solipsis at pitrou

Feb 28, 2012, 1:33 PM

Post #5 of 16 (397 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Tue, 28 Feb 2012 16:23:40 -0500
Chris McDonough <chrism [at] plope> wrote:
> On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote:
> > 2012/2/28 Ethan Furman <ethan [at] stoneleaf>:
> > > Here's what I know:
> > >
> > > We don't add features to bug-fix releases.
> > > u'' is considered a feature.
> > > By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> > > 2.x.
> > >
> > >
> > > Here's what I don't know:
> > >
> > > Why is readding u'' a feature and not a bug? (Just had a thought about this
> > > -- because the removal of u'' is documented.)
> >
> > Because it's a new "thing" which doesn't fix obviously broken behavior.
> >
> > >
> > >
> > > If there is already a FAQ entry feel free to point me to it, but I would
> > > still be curious why, in this instance, practicality does not beat purity?
> >
> > Because it's practical not to break bugfix releases with new features.
>
> This change, by its nature, cannot break old programs.

Unless the implementation is buggy, or has unintended side-effects.
In theory, *most* changes done in feature releases cannot break old
programs. Reality is often a bit more surprising :)

Regards

Antoine.


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


barry at python

Feb 28, 2012, 1:48 PM

Post #6 of 16 (396 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:

>> If there is already a FAQ entry feel free to point me to it, but I would
>> still be curious why, in this instance, practicality does not beat purity?
>
>Because it's practical not to break bugfix releases with new features.

And because now your code is incompatible with three micro-release versions
(3.2.0, 3.2.1, and 3.2.2), two of which are bug fix releases. Which means for
example, you can't be sure which version of which distro your code will work
on.

Doesn't anybody else remember the True/False debacle in 2.2.1?

Cheers,
-Barry
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


chrism at plope

Feb 28, 2012, 2:17 PM

Post #7 of 16 (392 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Tue, 2012-02-28 at 16:48 -0500, Barry Warsaw wrote:
> On Feb 28, 2012, at 03:54 PM, Benjamin Peterson wrote:
>
> >> If there is already a FAQ entry feel free to point me to it, but I would
> >> still be curious why, in this instance, practicality does not beat purity?
> >
> >Because it's practical not to break bugfix releases with new features.
>
> And because now your code is incompatible with three micro-release versions
> (3.2.0, 3.2.1, and 3.2.2), two of which are bug fix releases. Which means for
> example, you can't be sure which version of which distro your code will work
> on.

That I do sympathize with.

> Doesn't anybody else remember the True/False debacle in 2.2.1?

I do. It was slightly different than this because the feature was added
twice, once in 2.2.1 with direct aliases to 0 and 1, which was found to
be lacking, and then later again in 2.3 with explicit types, so it was
sort of an extended-timeframe unpleasantness, and the feature's
minor-dot-introduction was only a contributing factor, IIRC.

But yeah. A year from now I wouldn't remember which version of 3.2 got
a new feature, and neither would anybody else. The no-new-features
guidelines are useful in the real world this way, because they represent
a coherent policy, as tempting as it is to just jam it in.

- C


_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ncoghlan at gmail

Feb 28, 2012, 3:25 PM

Post #8 of 16 (384 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Wed, Feb 29, 2012 at 8:17 AM, Chris McDonough <chrism [at] plope> wrote:
> But yeah.  A year from now I wouldn't remember which version of 3.2 got
> a new feature, and neither would anybody else.  The no-new-features
> guidelines are useful in the real world this way, because they represent
> a coherent policy, as tempting as it is to just jam it in.

Also, I think there may be some confusion about Armin's plan to handle
3.2 - he aims to write an *import hook* that accepts the u/U prefixes
during tokenisation, not a source-to-source transform like 2to3. It's
clumsier than the plan for native syntactic support in 3.3 (since
you'll need to make sure the import hook is installed, the presence of
the hook will add overhead during application startup, and any
attempts to compile affected modules that don't go through the import
machinery will fail with a syntax error), but the presence of
importlib in 3.2 makes it quite feasible. When loading from a cached
.pyc, the hook won't even have to do anything special (since the
tokenisation change only affects the compilation step).

Assuming Armin can get the hook working as intended, then long running
applications where startup overhead isn't a big deal will just need to
ensure the hook is in place before they import any modules that use
the old-style string literals. For cases where the startup overhead
isn't acceptable (such as command line applications), then approaches
that change the source in advance (i.e. separate branches or single
source with the unicode_literals future import) will continue to be
the preferred mechanism for providing 3.2 support.

Cheers,
Nick.

--
Nick Coghlan   |   ncoghlan [at] gmail   |   Brisbane, Australia
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 28, 2012, 4:13 PM

Post #9 of 16 (378 views)
Permalink
Re: Backporting PEP 414 [In reply to]

> Why is readding u'' a feature and not a bug?

There is a really simple litmus test for whether something is a bug:
does it deviate from the specification?

In this case, the specification is the grammar, and the implementation
certainly doesn't deviate from it. So it can't be a bug.

Regards,
Martin

P.S. Before anybody over-interprets this criterion: there is certain
"implicit behavior" assumed in Python that may not actually be documented,
such as "the interpreter will not core dump", and "the source code will
compile with any standard C compiler". Deviation from these implicit
assumption is also a bug. However, they don't apply here.

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


vinay_sajip at yahoo

Feb 28, 2012, 4:22 PM

Post #10 of 16 (368 views)
Permalink
Re: Backporting PEP 414 [In reply to]

Nick Coghlan <ncoghlan <at> gmail.com> writes:

> Also, I think there may be some confusion about Armin's plan to handle
> 3.2 - he aims to write an *import hook* that accepts the u/U prefixes
> during tokenisation, not a source-to-source transform like 2to3. It's

I must confess, I thought it was a source-to-source transform, because he called
it an installation-time hook (which of course makes you think of 2to3) and not
an import hook. That will have a much better chance of acceptable performance,
since it'll only touch changed stuff automatically.

I feel better about the prospects for 3.2 support :-)

Regards,

Vinay Sajip

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


regebro at gmail

Feb 28, 2012, 10:52 PM

Post #11 of 16 (367 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Tue, Feb 28, 2012 at 21:27, Ethan Furman <ethan [at] stoneleaf> wrote:
> Here's what I know:
>
> We don't add features to bug-fix releases.
> u'' is considered a feature.
> By not backporting to 3.1 and 3.2 we are not easing the migration pains from
> 2.x.

If this is added to 3.2.3, then some programs will work with 3.2.3,
but not 3.2.2. I'm pretty sure this will confuse people no end. :-)

//Lennart
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


devel at baptiste-carvello

Feb 29, 2012, 12:59 AM

Post #12 of 16 (371 views)
Permalink
Re: Backporting PEP 414 [In reply to]

Le 29/02/2012 00:25, Nick Coghlan a écrit :

> Also, I think there may be some confusion about Armin's plan to handle
> 3.2 - he aims to write an *import hook* that accepts the u/U prefixes
> during tokenisation, not a source-to-source transform like 2to3.
>

this needs to be emphasized. Read from the outside, the whole PEP 414
discussion could give the idea that 3.2 is a second class citizen for
porting, like 3.0 and 3.1 have been. If such an opinion would spread,
that would be bad PR for Python 3 as a whole.

Baptiste

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


ironfroggy at gmail

Feb 29, 2012, 2:06 PM

Post #13 of 16 (363 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Feb 28, 2012 7:14 PM, <martin [at] v> wrote:
>>
>> Why is readding u'' a feature and not a bug?
>
>
> There is a really simple litmus test for whether something is a bug:
> does it deviate from the specification?
>
> In this case, the specification is the grammar, and the implementation
> certainly doesn't deviate from it. So it can't be a bug.

I don't think anyone can assert that the specification itself is immune to
having "bugs".

>
> Regards,
> Martin
>
> P.S. Before anybody over-interprets this criterion: there is certain
> "implicit behavior" assumed in Python that may not actually be documented,
> such as "the interpreter will not core dump", and "the source code will
> compile with any standard C compiler". Deviation from these implicit
> assumption is also a bug. However, they don't apply here.
>
>
> _______________________________________________
> Python-Dev mailing list
> Python-Dev [at] python
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com


rdmurray at bitdance

Feb 29, 2012, 2:43 PM

Post #14 of 16 (361 views)
Permalink
Re: Backporting PEP 414 [In reply to]

On Wed, 29 Feb 2012 17:06:21 -0500, Calvin Spealman <ironfroggy [at] gmail> wrote:
> On Feb 28, 2012 7:14 PM, <martin [at] v> wrote:
> >>
> >> Why is readding u'' a feature and not a bug?
> >
> >
> > There is a really simple litmus test for whether something is a bug:
> > does it deviate from the specification?
> >
> > In this case, the specification is the grammar, and the implementation
> > certainly doesn't deviate from it. So it can't be a bug.
>
> I don't think anyone can assert that the specification itself is immune to
> having "bugs".

Yes, but specification bug fixes are new features :)

--David
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


martin at v

Feb 29, 2012, 3:02 PM

Post #15 of 16 (363 views)
Permalink
Re: Backporting PEP 414 [In reply to]

>> There is a really simple litmus test for whether something is a bug:
>> does it deviate from the specification?
>>
>> In this case, the specification is the grammar, and the implementation
>> certainly doesn't deviate from it. So it can't be a bug.
>
> I don't think anyone can assert that the specification itself is immune
> to having "bugs".

I can assert that - a specification inherently cannot be "incorrect". It
can only be "unintentional".

There are certainly documentation errors. They occur when the
documentation deviates from the implementation *and* from the intent.
They are easy to fix in a bug fix release (assuming the implementation
correctly reflects the intent).

But then, this isn't the case here, either: the *intent* of the current
grammar is that there is no u prefix in the Python 3 language. So the
specification clearly corresponds to the intent also.

Regards,
Martin
_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com


tjreedy at udel

Feb 29, 2012, 5:21 PM

Post #16 of 16 (361 views)
Permalink
Re: Backporting PEP 414 [In reply to]

Armin filed and argued for the addition in a PEP, a Python *Enhancement*
Proposal. He did not file a bugfix behavior issue on the tracker. Let us
leave it as that.

x.y is a specified language. We continuously improve the x.y docs that
describe and explain the specification. We also improve the
implementation of x.y and periodically release the improvements as x.y.z.

--
Terry Jan Reedy

_______________________________________________
Python-Dev mailing list
Python-Dev [at] python
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: http://mail.python.org/mailman/options/python-dev/list-python-dev%40lists.gossamer-threads.com

Python dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.