On 01/12/2014 06:11 PM, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
On 01/12/2014 04:47 PM, Guido van Rossum wrote:
%s seems the trickiest: I think with a bytes argument it should just
insert those bytes (and the padding modifiers should work too), and
for othe
On 1/12/2014 6:11 PM, Guido van Rossum wrote:
On Sun, Jan 12, 2014 at 5:27 PM, Ethan Furman wrote:
>On 01/12/2014 04:47 PM, Guido van Rossum wrote:
>>%s seems the trickiest: I think with a bytes argument it should just
>>insert those bytes (and the padding modifiers should work too), and
>>for
On 01/12/2014 02:32 PM, Mark Lawrence wrote:
I've just tried asciistr using your test code (having corrected the typo, it's
assertIsInstance, not assertIsinstance :)
and it looks like a very good starting point. Have you, or anyone else for
that matter, actually tried asciistr out?
Ah, than
On 1/12/2014 8:00 PM, Ethan Furman wrote:
Okay, I've thought somewhat. Under the definition above would it be
fair to say that Db3Table (a class in my dbf module) is a boundary
type? It sits between the actual file and the program, and transforms
bytes into actual Python types.
Yes. Tha
On 1/12/2014 4:08 PM, Stephen J. Turnbull wrote:
Glenn Linderman writes:
> the proposals to embed binary in Unicode by abusing Latin-1
> encoding.
Those aren't "proposals", they are currently feasible techniques in
Python 3 for *some* use cases.
The question is why infecting Python 3 with
On 13 January 2014 09:55, Guido van Rossum wrote:
> There's a lot of discussion about PEP 460 and I haven't read it all.
> Maybe you all have already reached the same conclusion that I have. In
> that case I apologize (but the PEP should be updated). Here's my
> contribution:
>
> PEP 460 itself cu
On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote:
> So then the question is whether to proceed with 3.4, delay this feature to
> 3.5, or to delay 3.4 to include this feature, both have been discussed, with
> the justification for the latter being to make 3.4 the ultimate Python 3
> porting
On 13 January 2014 16:52, Donald Stufft wrote:
>
> On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote:
>
> So then the question is whether to proceed with 3.4, delay this feature to
> 3.5, or to delay 3.4 to include this feature, both have been discussed, with
> the justification for the latter
On Jan 13, 2014, at 1:59 AM, Nick Coghlan wrote:
> On 13 January 2014 16:52, Donald Stufft wrote:
>>
>> On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote:
>>
>> So then the question is whether to proceed with 3.4, delay this feature to
>> 3.5, or to delay 3.4 to include this feature, both
On Sun, Jan 12, 2014 at 10:59 PM, Nick Coghlan wrote:
> On 13 January 2014 16:52, Donald Stufft wrote:
>>
>> On Jan 13, 2014, at 12:45 AM, Glenn Linderman wrote:
>>
>> So then the question is whether to proceed with 3.4, delay this feature to
>> 3.5, or to delay 3.4 to include this feature, both
On 01/12/2014 10:51 PM, Nick Coghlan wrote:
I am a strong -1 on the more lenient proposal, as it makes binary
interpolation in Python 3 an *unsafe operation* for ASCII incompatible
binary formats.
No more unsafe that calling .upper() on ASCII incompatible streams.
The existing binary operat
101 - 111 of 111 matches
Mail list logo
