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. I asked Guido in private, but I didn't get any answer. Victor
On Wed, Jul 27, 2011 at 2:53 PM, Victor Stinner <victor.stinner@haypocalc.com> 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. I asked Guido in private, but I didn't get any answer.
Victor
Sorry Victor, I somehow didn't see that message even though I received it (I probably thought it was a continuation of the python-dev thread which I've been ignoring). Unfortunately I don't have time to go back and read the whole thread. I think I haven't used codecs.StreamReader/Writer myself, and I don't think I've seen much use of them either (which doesn't mean there isn't). My gut feeling is that yes, they should eventually go away, but no, there's no particular hurry, and no, I don't think you should change codecs.open() to call io.open(). I think the best thing is to campaign (e.g. in docs) for people to stop using codecs.open/StreamReader/Writer and start deprecating them formally once we feel that most users have switched. It's possible that that could happen before 3.3 is released, but I'm kind of doubtful about that myself. Sorry again for missing your private emails! -- --Guido van Rossum (python.org/~guido)
Le 28/07/2011 00:36, Guido van Rossum a écrit :
Sorry Victor, I somehow didn't see that message even though I received it (I probably thought it was a continuation of the python-dev thread which I've been ignoring).
No problem.
no, there's no particular hurry
That's why it's a deprecation process and the removal is schedule for later: "3.4 (or maybe later)". I added "or maybe later" before reopening a new thread on this list.
no, I don't think you should change codecs.open() to call io.open()
The PEP is useless without this change. If we don't deprecate any class and don't change codecs.open(), it's better to just reject the PEP.
start deprecating them formally once we feel that most users have switched
Users of codecs.open() or users of codecs.Stream* classes? Victor
On Wed, Jul 27, 2011 at 4:11 PM, Victor Stinner <victor.stinner@haypocalc.com> wrote:
Le 28/07/2011 00:36, Guido van Rossum a écrit :
Sorry Victor, I somehow didn't see that message even though I received it (I probably thought it was a continuation of the python-dev thread which I've been ignoring).
No problem.
no, there's no particular hurry
That's why it's a deprecation process and the removal is schedule for later: "3.4 (or maybe later)". I added "or maybe later" before reopening a new thread on this list.
That still sounds fairly aggressive.
no, I don't think you should change codecs.open() to call io.open()
The PEP is useless without this change. If we don't deprecate any class and don't change codecs.open(), it's better to just reject the PEP.
Why? (Not that I am against rejecting the PEP. I feel weakly opinioned in this case, about -0.)
start deprecating them formally once we feel that most users have switched
Users of codecs.open() or users of codecs.Stream* classes?
I would think both. Is there any reason to continue using codecs.open()? -- --Guido van Rossum (python.org/~guido)
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum <guido@python.org> wrote:
Users of codecs.open() or users of codecs.Stream* classes?
I would think both. Is there any reason to continue using codecs.open()?
It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x. The problem is that naive 2.x code will migrate to the optimised IO stack automatically on the 2.x -> 3.x transition, while code that tried to do the right thing has to be changed manually (either in 3.x only, or by switching to the io module for 2.x as well) in order to adjust for the differences in argument order. The idea behind changing codecs.open to be a wrapper around io.open was to allow such code to switch to the new optimised IO stack as easily as code that just uses the open builtin. If it's acceptable for the builtin behaviour to change (far more substantially), why not change codecs.open as well? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum <guido@python.org> wrote:
Users of codecs.open() or users of codecs.Stream* classes?
I would think both. Is there any reason to continue using codecs.open()?
It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x.
Even on 2.6, where the io module exists?
The problem is that naive 2.x code will migrate to the optimised IO stack automatically on the 2.x -> 3.x transition, while code that tried to do the right thing has to be changed manually (either in 3.x only, or by switching to the io module for 2.x as well) in order to adjust for the differences in argument order.
The idea behind changing codecs.open to be a wrapper around io.open was to allow such code to switch to the new optimised IO stack as easily as code that just uses the open builtin. If it's acceptable for the builtin behaviour to change (far more substantially), why not change codecs.open as well?
Aren't the cases different? Using built-in open() just means you want to open a file in the default way. Using codecs.open() presumably means that you've thought about Unicode. TBH, I said I was only -0 on the PEP, and if the stream returned by codecs.open() in 3.3 is sufficiently compatible with the stream returned the same function returns in 3.2, I am okay with it. (Except I also want you to cut a trillion dollars from the non-military budget, without raising taxes. :-) -- --Guido van Rossum (python.org/~guido)
2011/7/27 Guido van Rossum <guido@python.org>:
On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum <guido@python.org> wrote:
Users of codecs.open() or users of codecs.Stream* classes?
I would think both. Is there any reason to continue using codecs.open()?
It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x.
Even on 2.6, where the io module exists?
io on 2.6 is fairly broken and dead slow. The advantage of codecs.open is it hasn't changed in the very long time. It still has the same reliable buggy behavior no matter what version you're on. I don't see the problem with leaving codecs.open() to rot a few more releases before deprecating it while leaving messaging in the docs suggesting io.*.
The problem is that naive 2.x code will migrate to the optimised IO stack automatically on the 2.x -> 3.x transition, while code that tried to do the right thing has to be changed manually (either in 3.x only, or by switching to the io module for 2.x as well) in order to adjust for the differences in argument order.
The idea behind changing codecs.open to be a wrapper around io.open was to allow such code to switch to the new optimised IO stack as easily as code that just uses the open builtin. If it's acceptable for the builtin behaviour to change (far more substantially), why not change codecs.open as well?
Aren't the cases different? Using built-in open() just means you want to open a file in the default way. Using codecs.open() presumably means that you've thought about Unicode.
TBH, I said I was only -0 on the PEP, and if the stream returned by codecs.open() in 3.3 is sufficiently compatible with the stream returned the same function returns in 3.2, I am okay with it. (Except I also want you to cut a trillion dollars from the non-military budget, without raising taxes. :-)
May I suggest you include the military budget? :) -- Regards, Benjamin
Le 28/07/2011 06:10, Benjamin Peterson a écrit :
there any reason to continue using codecs.open()?
It's the easiest way to write Unicode friendly code that spans both 2.x and 3.x.
Even on 2.6, where the io module exists?
io on 2.6 is fairly broken and dead slow. The advantage of codecs.open is it hasn't changed in the very long time. It still has the same reliable buggy behavior no matter what version you're on.
I don't see the problem with leaving codecs.open() to rot a few more releases before deprecating it while leaving messaging in the docs suggesting io.*.
All these points were already discussed before. There is a subsection in "Backwards Compatibility" section in the PEP 400 explaining why codecs.open is NOT deprecated: http://www.python.org/dev/peps/pep-0400/#keep-the-public-api-codecs-open "codecs.open() can be replaced by the builtin open() function. open() has a similar API but has also more options. Both functions return file-like objects (same API). codecs.open() was the only way to open a text file in Unicode mode until Python 2.6. Many Python 2 programs uses this function. Removing codecs.open() implies more work to port programs from Python 2 to Python 3, especially projets using the same code base for the two Python versions (without using 2to3 program). codecs.open() is kept for backward compatibility with Python 2." Victor
participants (4)
-
Benjamin Peterson -
Guido van Rossum -
Nick Coghlan -
Victor Stinner