Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I mean unicode strings, period. I can't imagine what unicode strings
which do not contain data could be.
Binary data as opposed to text. Input to a array.fromstring(),
struct.unpack(), etc.
You can't/shouldn't put
Please take this to the py3k list.
It's still open which methods to add; it'll depend on the needs we
discover while using bytes to write the I/O library.
I don't believe we should add everything we can; rather, I'd like to
keep the API small until we have a clear need for a particular method.
Before I get into my reply, I'm going to start out by defining a new
term:
operationX - the operation of interpreting information differently than
how it is presented, generally by constructing a data structure based on
the input information.
eg; programming language source file - parse
Josiah Carlson wrote:
Certainly that is the case. But how would you propose embedded bytes
data be represented? (I talk more extensively about this particular
issue later).
Can't answer: I don't know what embedded bytes data are.
Ok. I think I would use base64, of possibly compressed
This discussion seems to have gotten a bit out of hand. I believe it
belongs on the python-3000 list.
As a quick commentary, I see good points made by both sides. My
personal view is that we should *definitely* not introduce a third
type, and that *most* text-based activities should be done in
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Certainly that is the case. But how would you propose embedded bytes
data be represented? (I talk more extensively about this particular
issue later).
Can't answer: I don't know what embedded bytes data are.
Ok. I think
Guido van Rossum [EMAIL PROTECTED] wrote:
This discussion seems to have gotten a bit out of hand. I believe it
belongs on the python-3000 list.
I accidentally jumped the gun on hitting 'send' on my most recent reply,
I'll repost it in the Py3k list and expect further discussion to proceed
Martin v. Löwis wrote:
Ok. I think I would use base64, of possibly compressed content. It's
more compact than your representation, as it only uses 1.3 characters
per byte, instead of the up-to-four bytes that the img2py uses.
only if you're shipping your code as PY files. in PYC format
Guido van Rossum [EMAIL PROTECTED] wrote:
On 4/29/06, Josiah Carlson [EMAIL PROTECTED] wrote:
I understand the underlying implementation of str.join can be a bit
convoluted (with the auto-promotion to unicode and all), but I don't
suppose there is any chance to get str.join to support
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing something?
I think what you are missing is that algorithms
On 4/30/06, Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing
At 08:22 AM 4/30/2006 -0700, Guido van Rossum wrote:
Still, I expect that having a bunch of string-ish methods on bytes
arrays would be convenient for certain types of data handling. Of
course, only those methods that don't care about character types would
be added, but that's a long list:
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
Specifically in the case of bytes.join(), the current common use-case of
literal.join(...) would become something similar to
bytes(literal).join(...), unless bytes objects got a syntax... Or
maybe I'm missing something?
I
Josiah Carlson wrote:
I think what you are missing is that algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
By character strings can I assume you mean unicode strings which
contain data,
Martin v. Löwis [EMAIL PROTECTED] wrote:
Josiah Carlson wrote:
I think what you are missing is that algorithms that currently operate
on byte strings should be reformulated to operate on character strings,
not reformulated to operate on bytes objects.
By character strings can I
Josiah Carlson wrote:
I mean unicode strings, period. I can't imagine what unicode strings
which do not contain data could be.
Binary data as opposed to text. Input to a array.fromstring(),
struct.unpack(), etc.
You can't/shouldn't put such data into character strings: you need
an encoding
16 matches
Mail list logo
