Victor Stinner victor.stinner at haypocalc.com writes:
It's difficult for an user to choose between between open() and
codecs.open().
Is it? How about the following decision process?
If writing code for Python 3.x only, use open().
If writing code which has to work under both Python 2.x and
Victor Stinner wrote:
Le mercredi 25 mai 2011 à 15:43 +0200, M.-A. Lemburg a écrit :
For UTF-16 it would e.g. make sense to always read data in blocks
with even sizes, removing the trial-and-error decoding and extra
buffering currently done by the base classes. For UTF-32, the
blocks should
Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a écrit :
I think that the readahead algorithm is much more faster than trying to
avoid partial input, and it's not a problem to have partial input if you
use an incremental decoder.
Depends on where you're coming from. For non-seekable
2011/5/27 Victor Stinner victor.stin...@haypocalc.com:
You have until the release of Python 3.3 to prove that StreamReader and/or
StreamWriter can be faster than TextIOWrapper. If you can prove it using a
patch and a benchmark, I will be ok to revert my commit.
Please don't hold commits over
Victor Stinner wrote:
Le vendredi 27 mai 2011 10:17:29, M.-A. Lemburg a écrit :
I am still -1 on deprecating the StreamReader/Writer parts of
the codec APIs. I've given numerous reasons on why these are
useful, what their intention is, why they were added to Python 1.6.
codecs.open() now
On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg m...@egenix.com wrote:
Wrong order: first write a PEP, then discuss, then get approval,
then patch.
Indeed.
If another committer says please revert and better justify this
change then we revert it. We don't get into commit wars.
Something does
Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit :
2011/5/27 Victor Stinner victor.stin...@haypocalc.com:
You have until the release of Python 3.3 to prove that StreamReader
and/or StreamWriter can be faster than TextIOWrapper. If you can prove
it using a patch and a benchmark, I
2011/5/27 Victor Stinner victor.stin...@haypocalc.com:
Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit :
2011/5/27 Victor Stinner victor.stin...@haypocalc.com:
You have until the release of Python 3.3 to prove that StreamReader
and/or StreamWriter can be faster than
Le vendredi 27 mai 2011 16:01:14, Nick Coghlan a écrit :
On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg m...@egenix.com wrote:
Wrong order: first write a PEP, then discuss, then get approval,
then patch.
Indeed.
If another committer says please revert and better justify this
change
Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a écrit :
If we'd go by your reasoning for deprecating and eventually
removing parts of the stdlib or Python's subsystems, we'll end
up with a barebone version of Python. That's not what we want
and it's not what our users want.
I don't want to
Victor Stinner wrote:
Le vendredi 27 mai 2011 15:42:10, M.-A. Lemburg a écrit :
If we'd go by your reasoning for deprecating and eventually
removing parts of the stdlib or Python's subsystems, we'll end
up with a barebone version of Python. That's not what we want
and it's not what our users
On 5/27/2011 11:08 AM, Victor Stinner wrote:
Tell me if I am wrong, but only Marc-Andre is against deprecating StreamReader
While I am, in general, in favor of removing some duplication, I was and
am against doing this change precipitously. So I was for the reversion
(noted), at least
On Sat, May 28, 2011 at 6:30 AM, Terry Reedy tjre...@udel.edu wrote:
On 5/27/2011 11:08 AM, Victor Stinner wrote:
Tell me if I am wrong, but only Marc-Andre is against deprecating
StreamReader
While I am, in general, in favor of removing some duplication, I was and am
against doing this
Walter Dörwald wrote:
On 24.05.11 12:58, Victor Stinner wrote:
Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
I don't see which usecase is not covered by TextIOWrapper. But I know
some cases which are not
Le mercredi 25 mai 2011 à 11:38 +0200, M.-A. Lemburg a écrit :
You are missing the point: we have StreamReader and StreamWriter APIs
on codecs to allow each codecs to implement more efficient ways of
encoding and decoding streams.
Examples of such optimizations are reading the stream in
Victor Stinner wrote:
Le mercredi 25 mai 2011 à 11:38 +0200, M.-A. Lemburg a écrit :
You are missing the point: we have StreamReader and StreamWriter APIs
on codecs to allow each codecs to implement more efficient ways of
encoding and decoding streams.
Examples of such optimizations are
Le mercredi 25 mai 2011 à 15:43 +0200, M.-A. Lemburg a écrit :
For UTF-16 it would e.g. make sense to always read data in blocks
with even sizes, removing the trial-and-error decoding and extra
buffering currently done by the base classes. For UTF-32, the
blocks should have size % 4 == 0.
Le mercredi 25 mai 2011 à 13:10 +0200, Victor Stinner a écrit :
codecs is always faster (between 1.07 and 1.15 times faster than io) to
read the whole content of file using read(-1). Something should maybe be
optimized in TextIOWrapper.read() ;-)
Oh, I understood: it's maybe the universal
Le mardi 24 mai 2011 à 15:24 +1000, Nick Coghlan a écrit :
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
It's trivial to replace a call to codecs.open() by a call to open(),
because the two API are very close. The main different is that
codecs.open()
Victor Stinner wrote:
Hi,
In Python 2, codecs.open() is the best way to read and/or write files
using Unicode. But in Python 3, open() is preferred with its fast io
module. I would like to deprecate codecs.open() because it can be
replaced by open() and io.TextIOWrapper. I would like your
Victor Stinner victor.stinner at haypocalc.com writes:
I opened an issue for this idea. Brett and Marc-Andree Lemburg don't
want to deprecate codecs.open() friends because they want to be able
to write code working on Python 2 and on Python 3 without any change. I
don't think it's realistic:
Le mardi 24 mai 2011 à 08:16 +, Vinay Sajip a écrit :
So I would also want to keep codecs.open() and friends, at least for now
Well, I would agree to keep codecs.open() (if we patch it to reuse
TextIOWrapper and add a note to say that it is kept for backward
compatibiltiy and open() should
Le mardi 24 mai 2011 à 10:03 +0200, M.-A. Lemburg a écrit :
Please read PEP 100 regarding StreamReader and StreamWriter.
Those codecs parts were explicitly designed to be stateful,
unlike the stateless encoder/decoder methods.
Yes, it is possible to implement stateful StreamReader and
Victor Stinner wrote:
Le mardi 24 mai 2011 à 10:03 +0200, M.-A. Lemburg a écrit :
Please read PEP 100 regarding StreamReader and StreamWriter.
Those codecs parts were explicitly designed to be stateful,
unlike the stateless encoder/decoder methods.
Yes, it is possible to implement stateful
On Tue, May 24, 2011 at 6:58 PM, Victor Stinner
victor.stin...@haypocalc.com wrote:
StreamReader, StreamWriter, TextIOWrapper and StreamReaderWriter all
have a file-like API: tell(), seek(), read(), readline(), write(), etc.
The implementation is maybe different, but the API is just the same,
On 24.05.11 02:08, Victor Stinner wrote:
[...]
codecs.open() and StreamReader, StreamWriter and StreamReaderWriter
classes of the codecs module don't support universal newlines, still
have some issues with stateful codecs (like UTF-16/32 BOMs), and each
codec has to implement a StreamReader
On Tue, 24 May 2011 20:25:11 +1000
Nick Coghlan ncogh...@gmail.com wrote:
Just as PEP 302 defines how module importers should be written, PEP
100 defines how text codecs should be written (i.e. in terms of
StreamReader and StreamWriter).
PEP 3116 then defines how such codecs can be used as
Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
I don't see which usecase is not covered by TextIOWrapper. But I know
some cases which are not supported by StreamReader/StreamWriter.
This could be be partially fixed by implementing generic
Le mardi 24 mai 2011 à 08:16 +, Vinay Sajip a écrit :
I opened an issue for this idea. Brett and Marc-Andree Lemburg don't
want to deprecate codecs.open() friends because they want to be able
to write code working on Python 2 and on Python 3 without any change. I
don't think it's
On Tue, 24 May 2011 12:16:49 +0200
Walter Dörwald wal...@livinglogic.de wrote:
and so it's not possible to write a generic fix for
all child classes in the codecs module. Each stateful codec has to
handle special cases like seek() problems.
Yes, which in theory makes it possible to
Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
I don't see which usecase is not covered by TextIOWrapper. But I know
some cases which are not supported by StreamReader/StreamWriter.
This could be be
On 24.05.11 12:58, Victor Stinner wrote:
Le mardi 24 mai 2011 à 12:42 +0200, Łukasz Langa a écrit :
Wiadomość napisana przez Walter Dörwald w dniu 2011-05-24, o godz. 12:16:
I don't see which usecase is not covered by TextIOWrapper. But I know
some cases which are not supported by
On 5/24/2011 6:14 AM, M.-A. Lemburg wrote:
I have no idea why TextIOWrapper was added to the stdlib
instead of making StreamReaderWriter more capable,
since StreamReaderWriter had already been available in Python
since Python 1.6 (and this is being used by codecs.open()).
As I understand it,
On 24/05/2011, Victor Stinner victor.stin...@haypocalc.com wrote:
In Python 2, codecs.open() is the best way to read and/or write files
using Unicode. But in Python 3, open() is preferred with its fast io
module. I would like to deprecate codecs.open() because it can be
replaced by open() and
Hi,
In Python 2, codecs.open() is the best way to read and/or write files
using Unicode. But in Python 3, open() is preferred with its fast io
module. I would like to deprecate codecs.open() because it can be
replaced by open() and io.TextIOWrapper. I would like your opinion and
that's why I'm
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
victor.stin...@haypocalc.com wrote:
It's trivial to replace a call to codecs.open() by a call to open(),
because the two API are very close. The main different is that
codecs.open() doesn't support universal newline, so you have to use
open(...,
36 matches
Mail list logo
