Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Feb 28, 2012 7:14 PM, mar...@v.loewis.de 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Wed, 29 Feb 2012 17:06:21 -0500, Calvin Spealman ironfro...@gmail.com wrote: On Feb 28, 2012 7:14 PM, mar...@v.loewis.de 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
2012/2/28 Ethan Furman et...@stoneleaf.us: 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Tue, Feb 28, 2012 at 14:27, Ethan Furman et...@stoneleaf.us 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote: 2012/2/28 Ethan Furman et...@stoneleaf.us: 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Tue, 28 Feb 2012 16:23:40 -0500 Chris McDonough chr...@plope.com wrote: On Tue, 2012-02-28 at 15:54 -0500, Benjamin Peterson wrote: 2012/2/28 Ethan Furman et...@stoneleaf.us: 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Wed, Feb 29, 2012 at 8:17 AM, Chris McDonough chr...@plope.com 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 | ncogh...@gmail.com | Brisbane, Australia ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Backporting PEP 414
On Tue, Feb 28, 2012 at 21:27, Ethan Furman et...@stoneleaf.us 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@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
