unicode, bytes redux

[willie]

(beating a dead horse)

Is it too ridiculous to suggest that it'd be nice
if the unicode object were to remember the
encoding of the string it was decoded from?
So that it's feasible to calculate the number
of bytes that make up the unicode code points.

# U+270C
# 11100010 10011100 10001100
buf = "\xE2\x9C\x 8C"

u = buf.decode('UTF-8')

# ... later ...

u.bytes() -3

(goes through each code point and calculates
the number of bytes that make up the character
according to the encoding)

[Duncan Booth]

willie <wi****@jamots. comwrote:

Is it too ridiculous to suggest that it'd be nice
if the unicode object were to remember the
encoding of the string it was decoded from?
So that it's feasible to calculate the number
of bytes that make up the unicode code points.

So what sort of output do you expect from this:

>>a = '\xc9'.decode(' latin1')
b = '\xc3\x89'.deco de('utf8')
print (a+b).bytes()

???

And if you say that's an unfair question because you expected all the byte
strings to be using the same encoding then there's no point storing it on
every unicode object; you might as well store it once globally.

[Paul Rubin]

willie <wi****@jamots. comwrites:

# U+270C
# 11100010 10011100 10001100
buf = "\xE2\x9C\x 8C"
u = buf.decode('UTF-8')
# ... later ...
u.bytes() -3

(goes through each code point and calculates
the number of bytes that make up the character
according to the encoding)

Duncan Booth explains why that doesn't work. But I don't see any big
problem with a byte count function that lets you specify an encoding:

u = buf.decode('UTF-8')
# ... later ...
u.bytes('UTF-8') -3
u.bytes('UCS-4') -4

That avoids creating a new encoded string in memory, and for some
encodings, avoids having to scan the unicode string to add up the
lengths.

[Leif K-Brooks]

Paul Rubin wrote:

Duncan Booth explains why that doesn't work. But I don't see any big
problem with a byte count function that lets you specify an encoding:

u = buf.decode('UTF-8')
# ... later ...
u.bytes('UTF-8') -3
u.bytes('UCS-4') -4

That avoids creating a new encoded string in memory, and for some
encodings, avoids having to scan the unicode string to add up the
lengths.

It requires a fairly large change to code and API for a relatively
uncommon problem. How often do you need to know how many bytes an
encoded Unicode string takes up without needing the encoded string itself?

[Paul Rubin]

Leif K-Brooks <eu*****@ecritt ers.bizwrites:

It requires a fairly large change to code and API for a relatively
uncommon problem. How often do you need to know how many bytes an
encoded Unicode string takes up without needing the encoded string
itself?

Shrug. I don't see a real large change--the code would just check for
an optional arg and process accordingly. I don't know if the issue
comes up often enough to be worth making such accomodations for. I do
know that we had an extensive newsgroup thread about it, from which
this discussion came, but I haven't paid that much attention.

[John Machin]

willie wrote:

(beating a dead horse)

Is it too ridiculous to suggest that it'd be nice
if the unicode object were to remember the
encoding of the string it was decoded from?

Where it's been is irrelevant. Where it's going to is what matters.

So that it's feasible to calculate the number
of bytes that make up the unicode code points.

# U+270C
# 11100010 10011100 10001100
buf = "\xE2\x9C\x 8C"

u = buf.decode('UTF-8')

# ... later ...

u.bytes() -3

(goes through each code point and calculates
the number of bytes that make up the character
according to the encoding)

Suppose the unicode object was decoded using some encoding other than
the one that's going to be used to store the info in the database:

| >>sg = '\xc9\xb5\xb9\x cf'
| >>len(sg)
| 4
| >>u = sg.decode('gb23 12')

later:
u.bytes() =4

but

| >>len(u.encode( 'utf8'))
| 6

and by the way, what about the memory overhead of storing the name of
the encoding (in the above case 7 (6 + overhead))?

What would u"abcdef".bytes () produce? An exception?

HTH,
John

[John Machin]

Paul Rubin wrote:

Leif K-Brooks <eu*****@ecritt ers.bizwrites:

It requires a fairly large change to code and API for a relatively
uncommon problem. How often do you need to know how many bytes an
encoded Unicode string takes up without needing the encoded string
itself?

Shrug. I don't see a real large change--the code would just check for
an optional arg and process accordingly. I don't know if the issue
comes up often enough to be worth making such accomodations for. I do
know that we had an extensive newsgroup thread about it, from which
this discussion came, but I haven't paid that much attention.

Actually, what Willie was concerned about was some cockamamie DBMS
which required to be fed Unicode, which it encoded as UTF-8, but
silently truncated if it was more than the n in varchar(n) ... or
something like that.

So all he needs is a boolean result: u.willitfit(enc oding, width)

This can of course be optimised with simple early-loop-exit tests:
if n_bytes_so_far + n_remaining_uch ars width: return False
elif n_bytes_so_far + n_remaining_uch ars * M <= width: return True
# where M is the maximum #bytes per Unicode char for the encoding
that's being used.

Tell you what, why don't you and Willie get together and write a PEP?

Cheers,
John

[Paul Rubin]

"John Machin" <sj******@lexic on.netwrites:

Actually, what Willie was concerned about was some cockamamie DBMS
which required to be fed Unicode, which it encoded as UTF-8,

Yeah, I remember that.

Tell you what, why don't you and Willie get together and write a PEP?

If enough people care about the problem, I'd say just submit a code
patch. I haven't needed it myself, but I haven't (so far) had to deal
with unicode that often. It's a reasonably logical thing to want.
Imagine if the normal length(string) function required copying the
string around.

[John Machin]

Paul Rubin wrote:

"John Machin" <sj******@lexic on.netwrites:

Actually, what Willie was concerned about was some cockamamie DBMS
which required to be fed Unicode, which it encoded as UTF-8,

Yeah, I remember that.

Tell you what, why don't you and Willie get together and write a PEP?

If enough people care about the problem, I'd say just submit a code
patch. I haven't needed it myself, but I haven't (so far) had to deal
with unicode that often. It's a reasonably logical thing to want.
Imagine if the normal length(string) function required copying the
string around.

Almost as bad: just imagine a language that had a normal strlen(string)
function that required mucking all the way through the string until you
hit some cockamamie in-band can't-happen-elsewhere sentinel.

Cheers,
John

[Steven D'Aprano]

On Mon, 25 Sep 2006 00:45:29 -0700, Paul Rubin wrote:

willie <wi****@jamots. comwrites:

># U+270C
# 11100010 10011100 10001100
buf = "\xE2\x9C\x 8C"
u = buf.decode('UTF-8')
# ... later ...
u.bytes() -3

(goes through each code point and calculates
the number of bytes that make up the character
according to the encoding)

Duncan Booth explains why that doesn't work. But I don't see any big
problem with a byte count function that lets you specify an encoding:

u = buf.decode('UTF-8')
# ... later ...
u.bytes('UTF-8') -3
u.bytes('UCS-4') -4

That avoids creating a new encoded string in memory, and for some
encodings, avoids having to scan the unicode string to add up the
lengths.

Unless I'm misunderstandin g something, your bytes code would have to
perform exactly the same algorithmic calculations as converting the
encoded string in the first place, except it doesn't need to store the
newly encoded string, merely the number of bytes of each character.

Here is a bit of pseudo-code that might do what you want:

def bytes(unistring , encoding):
length = 0
for c in unistring:
length += len(c.encode(en coding))
return length

At the cost of some speed, you can avoid storing the entire encoded string
in memory, which might be what you want if you are dealing with truly
enormous unicode strings.

Alternatively, instead of calling encode() on each character, you can
write a function (presumably in C for speed) that does the exact same
thing as encode, but without storing the encoded characters, merely adding
their lengths. Now you have code duplication, which is usually a bad idea.
If for no other reason, some poor schmuck has to maintain them both! (And
I bet it won't be Willie, for all his enthusiasm for the idea.)

This whole question seems to me like an awful example of premature
optimization. Your computer has probably got well in excess of 100MB, and
you're worried about duplicating a few hundred or thousand (or even
hundred thousand) bytes for a few milliseconds (just long enough to grab
the length)?
--
Steven D'Aprano