Re: [Python-Dev] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
Le vendredi 29 juillet 2011 19:01:06, Guido van Rossum a écrit : On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Fri, Aug 12, 2011 at 8:21 AM, Terry Reedy tjre...@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 | 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@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. ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@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 | 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Fri, Jul 29, 2011 at 8:37 AM, Nick Coghlan ncogh...@gmail.com wrote: On Sat, Jul 30, 2011 at 1:17 AM, Antoine Pitrou solip...@pitrou.net wrote: On Thu, 28 Jul 2011 11:28:43 +0200 Victor Stinner victor.stin...@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) ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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/ ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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/ ___ 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
[Python-Dev] 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 ___ 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
[Python-Dev] 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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Wed, Jul 27, 2011 at 2:53 PM, Victor Stinner victor.stin...@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) ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
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 ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Wed, Jul 27, 2011 at 4:11 PM, Victor Stinner victor.stin...@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) ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@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 | 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@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) ___ 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] Status of the PEP 400? (deprecate codecs.StreamReader/StreamWriter)
2011/7/27 Guido van Rossum gu...@python.org: On Wed, Jul 27, 2011 at 6:00 PM, Nick Coghlan ncogh...@gmail.com wrote: On Thu, Jul 28, 2011 at 9:38 AM, Guido van Rossum gu...@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 ___ 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
