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\x8C"

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'.decode('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\x8C"
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*****@ecritters.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\x8C"

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\xcf'
| >>len(sg)
| 4
| >>u = sg.decode('gb2312')

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*****@ecritters.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(encoding, width)

This can of course be optimised with simple early-loop-exit tests:
if n_bytes_so_far + n_remaining_uchars width: return False
elif n_bytes_so_far + n_remaining_uchars * 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******@lexicon.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******@lexicon.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\x8C"
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 misunderstanding 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(encoding))
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

[Fredrik Lundh]

John Machin wrote:

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(encoding, width)

at what point in the program would that method be used ?

how large are the strings, for typical cases ?

</F>

[John Roth]

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?
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\x8C"

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)

Yup, it's a dead horse. As suggested elsewhere in
the thread, the unicode object is not the proper
place for this functionality. Also, as suggested,
it's not even the desired functionality: what's really
wanted is the ability to tell how long the string
is going to be in various encodings.

That's easy enough to do today - just encode the
darn thing and use len(). I don't see any reason
to expand the language to support a data base
product that goes out of its way to make it difficult
for developers.

John Roth

[John Machin]

Fredrik Lundh wrote:

John Machin wrote:

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(encoding, width)

at what point in the program would that method be used ?

Never, I hope. Were you taking that as a serious suggestion? Fredrik,
perhaps your irony detector needs a little preventative maintenance :-)

>
how large are the strings, for typical cases ?

He did mention it several posts ago -- I recall varchar(50) or
something like that. IOW as Duncan Booth said in effect at the start of
the 1st thread, the OP's got more problems that just doubling up on
u.encode('utf8') ...

Cheers,
John

[Fredrik Lundh]

John Machin wrote:

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

at what point in the program would that method be used ?

Never, I hope. Were you taking that as a serious suggestion? Fredrik,
perhaps your irony detector needs a little preventative maintenance :-)

well, Willie did ask for something like that, didn't he ? I'm just gathering
requirements...

>how large are the strings, for typical cases ?

He did mention it several posts ago -- I recall varchar(50) or
something like that.

ok. wake me up when he's dealing with columns defined as
varchar(50000000) or so...

</F>

[Walter Dörwald]

Steven D'Aprano wrote:

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

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

>># U+270C
# 11100010 10011100 10001100
buf = "\xE2\x9C\x8C"
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 misunderstanding 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(encoding))
return length

That wouldn't work for stateful encodings:

>>len(u"abc".encode("utf-16"))

8

>>bytes(u"abc", "utf-16")

12

Use a stateful encoder instead:

import codecs
def bytes(unistring, encoding):
length = 0
enc = codecs.getincrementalencoder(encoding)()
for c in unistring:
length += len(enc.encode(c))
return length

Servus,
Walter