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, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 28 2011)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 29 2011)
Python/Zope Consulting and Support ... http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/
::: Try our new mxODBC.Connect Python Database Interface for free ! :::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 -- --Guido van Rossum (python.org/~guido)
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. -- Terry Jan Reedy
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. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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