Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Hi,
Three weeks ago, I posted a draft on my PEP on this mailing list. I tried to include all remarks you made, and the PEP is now online:
http://www.python.org/dev/peps/pep-0400/
It's now unclear to me if the PEP will be accepted or rejected. I don't know what to do to move forward.
Victor
Victor Stinner wrote:
Hi,
Three weeks ago, I posted a draft on my PEP on this mailing list. I tried to include all remarks you made, and the PEP is now online:
http://www.python.org/dev/peps/pep-0400/
It's now unclear to me if the PEP will be accepted or rejected. I don't know what to do to move forward.
The PEP still compares apples and oranges, issues and features, and doesn't cover the fact that it is proposing to not just deprecate a feature, but a part of a design concept which will then no longer be available in Python.
I'm still -1 on that part of the PEP.
As I mentioned before, having codecs.open() changed to be a wrapper around io.open() in Python 3.3, should be investigated. If it doesn't cause too much trouble, this would be a good idea. Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers.
Thanks,
Le 28/07/2011 11:03, M.-A. Lemburg a écrit :
Victor Stinner wrote:
Hi,
Three weeks ago, I posted a draft on my PEP on this mailing list. I tried to include all remarks you made, and the PEP is now online:
http://www.python.org/dev/peps/pep-0400/It's now unclear to me if the PEP will be accepted or rejected. I don't know what to do to move forward.
The PEP still compares apples and oranges, issues and features,
I don't know how to write a PEP and this is my first PEP. I think that it is possible to compare two classes using a list of issues and features. How should I change the PEP to compare comparable things?
and doesn't cover the fact that it is proposing to not just deprecate a feature, but a part of a design concept which will then no longer be available in Python.
The "Usage of StreamReader and StreamWriter" section tries to list usages of these classes, and "Deprecate StreamReader and StreamWriter" section explains that these classes will be removed. I agree that these sections are short, but I don't know what to add.
Could you please enhance these sections?
I'm still -1 on that part of the PEP.
Ok.
As I mentioned before, having codecs.open() changed to be a wrapper around io.open() in Python 3.3, should be investigated. If it doesn't cause too much trouble, this would be a good idea.
I did already try on the full Python test suite, and all test pass. I don't know if it's representative.
Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers.
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
* rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
Add a new function to Python 3.3 means that we will have to maintain it for later versions. It's just the opposite of my proposition :-)
Victor
Le 28/07/2011 11:28, Victor Stinner a écrit :
Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers.
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
I added your proposal to the PEP as an "Alternative Approache".
Victor
Victor Stinner wrote:
Le 28/07/2011 11:28, Victor Stinner a écrit :
Please do keep the original implementation around (e.g. renamed to codecs.open_stream()), though, so that it's still possible to get easy-to-use access to codec StreamReader/Writers.
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
I added your proposal to the PEP as an "Alternative Approache".
Thanks.
On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stinner@haypocalc.com wrote:
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing.
Regards
Antoine.
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stinner@haypocalc.com wrote:
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
* rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing.
Indeed. I'm also heavily influenced by MAL's opinion on this particular topic, so the fact he's OK with this approach counts for a lot. It achieves the main benefit I'm interested in (transparently migrating users of the codecs.open API to the new IO stack), while paving the way for eliminating the redundancy at some point in the future.
Cheers, Nick.
On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solipsis@pitrou.net wrote:
On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stinner@haypocalc.com wrote:
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
* rename codecs.open() to codecs.open_stream() * change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing.
Indeed. I'm also heavily influenced by MAL's opinion on this particular topic, so the fact he's OK with this approach counts for a lot. It achieves the main benefit I'm interested in (transparently migrating users of the codecs.open API to the new IO stack), while paving the way for eliminating the redundancy at some point in the future.
+1
Le 29/07/2011 19:01, Guido van Rossum a écrit :
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(...)
+1
Ok, most people prefer this option. Should I modify the PEP to "move" this option has the first/main proposition (move my proposition as an alternative?), or can the PEP be validated in the current state?
Victor
On 8/11/2011 3:31 PM, Victor Stinner wrote:
Le 29/07/2011 19:01, Guido van Rossum a écrit :
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(...)
+1
Ok, most people prefer this option. Should I modify the PEP to "move" this option has the first/main proposition (move my proposition as an alternative?), or can the PEP be validated in the current state?
I would relabel the above as the Minimal Change Alternative or M.A.L. alternative or whatever and possibly move it but in any case note that Guido (and others) accepted that alternative with consideration of more drastic changes deferred to later. And add an explicit reference to the email you quoted.
On Fri, Aug 12, 2011 at 8:21 AM, Terry Reedy tjreedy@udel.edu wrote:
On 8/11/2011 3:31 PM, Victor Stinner wrote:
Ok, most people prefer this option. Should I modify the PEP to "move" this option has the first/main proposition (move my proposition as an alternative?), or can the PEP be validated in the current state?
I would relabel the above as the Minimal Change Alternative or M.A.L. alternative or whatever and possibly move it but in any case note that Guido (and others) accepted that alternative with consideration of more drastic changes deferred to later. And add an explicit reference to the email you quoted.
Yeah, definitely retitle/rewrite/rearrange to be clear what Guido accepted and then state that any future deprecation of components in the codecs module will be dealt with as a new PEP.
Regards, Nick.
Le vendredi 29 juillet 2011 19:01:06, Guido van Rossum a écrit :
On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan ncoghlan@gmail.com wrote:
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solipsis@pitrou.net
wrote:
On Thu, 28 Jul 2011 11:28:43 +0200
Victor Stinner victor.stinner@haypocalc.com wrote:
I will add your alternative to the PEP (except if you would like to do that yourself?). If I understood correctly, you propose to:
- rename codecs.open() to codecs.open_stream()
- change codecs.open() to reuse open() (and so io.TextIOWrapper)
(and don't deprecate anything)
This may be an interesting approach. In a few years, we can evaluate whether users are calling open_stream(), and if there aren't any, we can deprecate the whole thing.
Indeed. I'm also heavily influenced by MAL's opinion on this particular topic, so the fact he's OK with this approach counts for a lot. It achieves the main benefit I'm interested in (transparently migrating users of the codecs.open API to the new IO stack), while paving the way for eliminating the redundancy at some point in the future.
+1
I updated the PEP 400 to no longer *remove* deprecated functions in Python 3.4. I don't like the idea of adding a *new* function (codecs.open_stream()) which emits a DeprecatingWarning. New functions are not supposed to be (indirectly) deprecated.
Short summary of the updated PEP 400:
- patch codecs.open() to make it reuse TextIOWrapper to access text files (instead of Stream* classes) - instanciate Stream* classes emit a DeprecationWarning - that's all
So you can still get stream reader/writer using codecs.getreader() and codecs.getwriter() functions.
Victor
participants (6)
-
Antoine Pitrou -
Guido van Rossum -
M.-A. Lemburg -
Nick Coghlan -
Terry Reedy -
Victor Stinner