Victor Stinner 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 3.x, use
codec
On Sat, May 28, 2011 at 6:30 AM, Terry Reedy 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 change prec
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 tempor
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 ou
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
Le vendredi 27 mai 2011 16:01:14, Nick Coghlan a écrit :
> On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg 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 w
2011/5/27 Victor Stinner :
> Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit :
>> 2011/5/27 Victor Stinner :
>> > 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 b
Le vendredi 27 mai 2011 15:33:07, Benjamin Peterson a écrit :
> 2011/5/27 Victor Stinner :
> > 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
On Fri, May 27, 2011 at 11:42 PM, M.-A. Lemburg 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 need to be
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(
2011/5/27 Victor Stinner :
> 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 someone's head.
--
Rega
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-seekab
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
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 ne
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.
>
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 optimization
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
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 cas
On 24/05/2011, Victor Stinner 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 io.TextIOWrapper. I wou
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, y
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
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 co
On Tue, 24 May 2011 12:16:49 +0200
Walter Dörwald 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 implement shortcu
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 i
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
> StreamReader/Strea
On Tue, 24 May 2011 20:25:11 +1000
Nick Coghlan 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 part of the
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 StreamRea
On Tue, May 24, 2011 at 6:58 PM, Victor Stinner
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, and
> so the usecases are
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 s
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 Stream
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 b
Victor Stinner 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: nontrivial
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 y
Le mardi 24 mai 2011 à 15:24 +1000, Nick Coghlan a écrit :
> On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
> 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 unive
On Tue, May 24, 2011 at 10:08 AM, Victor Stinner
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(..., newline='') to keep the
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 wri
36 matches
Mail list logo
