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 (Z
"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" <[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 dat
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 the
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 compre
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 tree
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.
Fo
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.
> Um...struct.unpack() already works on unicode...
> >
"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 c
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
"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
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
> conta
"Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Specifically in the case of bytes.join(), the current common use-case of
> > .join(...) would become something similar to
> > bytes().join(...), unless bytes objects got a syntax... Or
> > maybe I'm missing something?
>
> I
Guido van Rossum wrote:
> Well, yes, in most cases, but while attempting to write an I/O library
> I already had the urge to collect "chunks" I've read in a list and
> join them later, instead of concatenating repeatedly. I guess I should
> suppress this urge, and plan to optimize extending a bytes
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: star
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
> > .join(...) would become something similar to
> > bytes().join(...), unless bytes objects got a syntax... Or
> > maybe I'm missing somethi
Josiah Carlson wrote:
> Specifically in the case of bytes.join(), the current common use-case of
> .join(...) would become something similar to
> bytes().join(...), unless bytes objects got a syntax... Or
> maybe I'm missing something?
I think what you are missing is that algorithms that currently
"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
18 matches
Mail list logo
