On Mon, 13 Jun 2016 11:36 pm, Random832 wrote:
> On Mon, Jun 13, 2016, at 06:35, Steven D'Aprano wrote:
>> But this is a Python forum, and Python 3 is a language that tries
>> very, very hard to keep a clean separation between bytes and text,
>
> Yes, but that doesn't mean that you're right
As
On Mon, Jun 13, 2016, at 19:12, Gregory Ewing wrote:
> They could maybe be made a bit cheaper still by arranging
> some way for a bytes object and an ascii-only str object
> to share underlying storage.
While we're at it, why not allow bytes to share storage with FSR latin-1
strings and the cached
Chris Angelico wrote:
Maybe what Python needs is an "ascii" type that's a subclass of both
str and bytes, and requires that the contents be <0x80. It is text, so
it can be combined with text strings; but it is also bytes, so when
you combine it with bytes strings, it'll behave as most people expe
Michael Torrie wrote:
On 06/12/2016 11:16 PM, Steven D'Aprano wrote:
Squirt it down a wire as bytes? Almost certainly.
Sometimes yes. But not always.
And even when the ultimate destination is a wire, a Python
programmer is more likely to be accessing the wire through
some high-level interf
On Tue, Jun 14, 2016 at 1:15 AM, Michael Torrie wrote:
>> Looking at this from the high-level perspective of Python, that makes it
>> conceptually bytes not text.
>
> I don't see how this is always the case. From a high-level python
> perspective it's definitely text. That's the whole point of b
On 06/12/2016 11:16 PM, Steven D'Aprano wrote:
> "Safe to transmit in text protocols" surely should mean "any Unicode code
> point", since all of Unicode is text. What's so special about the base64
> ones?
>
> Well, that depends on your context. For somebody who cares about sending
> bits over a p
On Mon, Jun 13, 2016, at 06:35, Steven D'Aprano wrote:
> But this is a Python forum, and Python 3 is a language that tries
> very, very hard to keep a clean separation between bytes and text,
Yes, but that doesn't mean that you're right about which side of that
divide base64 output belongs on.
>
On Mon, 13 Jun 2016 03:33 pm, Random832 wrote:
> Why do you say these things like you assume I will agree with them.
Because I gave you the benefit of the doubt that you were a reasonable
person open to good-faith discussion, rather than playing John Cleese's
role in your own personal version of
Random832 :
> base64 characters are *characters*, not *bytes*
Ok, I ran into the same surprise just two days ago. But is this a big
deal?
Marko
--
https://mail.python.org/mailman/listinfo/python-list
On Mon, Jun 13, 2016, at 01:16, Steven D'Aprano wrote:
> Suppose instead it returned the Unicode string 'AUERFg=='. That's all
> well and good, but what are you going to do with it? You can't
> transmit it over a serial cable, because that almost surely is going
> to expect bytes, so you have to en
On Mon, 13 Jun 2016 01:20 pm, Random832 wrote:
> On Sun, Jun 12, 2016, at 22:22, Steven D'Aprano wrote:
>> That's because base64 is a bytes-to-bytes transformation. It has
>> nothing to do with unicode encodings.
>
> Nonsense. base64 is a binary-to-text encoding scheme. The output range
> is spec
On Sun, Jun 12, 2016, at 22:22, Steven D'Aprano wrote:
> That's because base64 is a bytes-to-bytes transformation. It has
> nothing to do with unicode encodings.
Nonsense. base64 is a binary-to-text encoding scheme. The output range
is specifically chosen to be safe to transmit in text protocols.
On Mon, 13 Jun 2016 04:56 am, Marcin Rak wrote:
> Hi to everyone.
>
> Let's say I have some binary data, be it whatever, in the 'data' variable.
> After calling the following line
>
> b64_encoded_data = base64.b64encode(data)
>
> my b64_encoded_data variables holds, would you believe it, a str
Marcin Rak :
> b64_encoded_data = base64.b64encode(data)
>
> my b64_encoded_data variables holds, would you believe it, a string as
> bytes!.
It doesn't much matter one way or another. The logic is that whenever
you encode objects, you typically want the output as bytes. However,
it's trivial to
14 matches
Mail list logo
