On Wed, Jan 7, 2009 at 2:35 PM, Brett Cannon wrote:
> On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg wrote:
> [SNIP]
>> BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just
>> like all Unicode support source files). Someone apparently has added
>> tabs when adding support for Py_buf
Guido van Rossum wrote:
OK, ignore my previous comment. Sounds like the inidividual codecs
need to tighten their type checking though -- perhaps *that* can be
fixed in 3.0.1? I really don't see why any codec used to convert
between text and bytes should support its output type as input.
--Guido
On Wed, Jan 7, 2009 at 10:57, M.-A. Lemburg wrote:
[SNIP]
> BTW: The _codecsmodule.c file is a 4 spaces indent file as well (just
> like all Unicode support source files). Someone apparently has added
> tabs when adding support for Py_buffers.
>
It looks like this formatting mix-up is just going
OK, ignore my previous comment. Sounds like the inidividual codecs
need to tighten their type checking though -- perhaps *that* can be
fixed in 3.0.1? I really don't see why any codec used to convert
between text and bytes should support its output type as input.
--Guido
On Wed, Jan 7, 2009 at 10
On 2009-01-07 19:32, Antoine Pitrou wrote:
> M.-A. Lemburg egenix.com> writes:
>> No, that's something I explicitly readded to Python 3k, since the
>> codecs interface is independent of the input and output types (the
>> codecs decide which combinations to support).
>
> But why would the utf8 dec
M.-A. Lemburg egenix.com> writes:
>
> No, that's something I explicitly readded to Python 3k, since the
> codecs interface is independent of the input and output types (the
> codecs decide which combinations to support).
But why would the utf8 decoder accept unicode as input?
On Wed, Jan 07, 2009, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> Sounds like yet another remnant of the old philosophy, which indeed
>> supported encode and decode operations on both string types.
>
> How do we go for fixing it? Is it ok to raise a TypeError in 3.0.1?
T
On 2009-01-07 16:34, Guido van Rossum wrote:
> Sounds like yet another remnant of the old philosophy, which indeed
> supported encode and decode operations on both string types. :-(
No, that's something I explicitly readded to Python 3k, since the
codecs interface is independent of the input and o
On Wed, Jan 7, 2009 at 9:46 AM, Guido van Rossum wrote:
> A -3 warning should be added to 2.6 about this too IMO.
A Py3k warning when attempting to decode a unicode string? Wouldn't
that open the door to adding warnings to everywhere a unicode string
is used where a byte string is? I thought that
That depends a bit on how much code we find that breaks as a result.
If you find you have to do a big cleanup in the stdlib after that
change, it's likely that 3rd party code could have the same problem,
and I'd be reluctant. I'd be okay with adding a warning in that case.
OTOH if there's no cleanu
Guido van Rossum python.org> writes:
>
> Sounds like yet another remnant of the old philosophy, which indeed
> supported encode and decode operations on both string types.
How do we go for fixing it? Is it ok to raise a TypeError in 3.0.1?
___
Pyth
Sounds like yet another remnant of the old philosophy, which indeed
supported encode and decode operations on both string types. :-(
On Wed, Jan 7, 2009 at 5:39 AM, Antoine Pitrou wrote:
> Hello,
>
> I've just noticed that in py3k, the decoding functions in the codecs module
> accept str objects
Hello,
I've just noticed that in py3k, the decoding functions in the codecs module
accept str objects as well as bytes:
# import codecs
# c = codecs.getdecoder('utf8')
# c('aa')
('aa', 2)
# c('éé')
('éé', 4)
# c = codecs.getdecoder('latin1')
# c('aa')
('aa', 2)
# c('éé')
('éé', 4)
I
13 matches
Mail list logo
