[issue17629] Expose string width to Python

2013-04-06 Thread Roy Smith
Roy Smith added the comment: Um, make that msg185972. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http:/

[issue17629] Expose string width to Python

2013-04-06 Thread Roy Smith
Roy Smith added the comment: I'm the guy who was searching for astral characters in msg18597. I should mention that while what I did was certainly inefficient, the database was so much slower that it didn't have any observable impact on the overall process time (a bit over 2 days to insert ap

[issue17629] Expose string width to Python

2013-04-06 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: See also the discussion at http://comments.gmane.org/gmane.comp.python.ideas/15640 . I agree with rejection. This is an implementation detail and different Python implementations (including future CPython versions) can have different internal string impleme

[issue17629] Expose string width to Python

2013-04-03 Thread Benjamin Peterson
Benjamin Peterson added the comment: This is an implementation detail we don't want to expose. (It might change someday!) -- nosy: +benjamin.peterson resolution: -> rejected status: open -> closed ___ Python tracker

[issue17629] Expose string width to Python

2013-04-03 Thread Terry J. Reedy
Terry J. Reedy added the comment: ord(max(s)) == max(map(ord,s)) == ord(max(s, key=ord)) Using a*3000 and mental counting, the first is clearly fastest (about 2 seconds) with a 3.4 build, which has the optimized string comparison patches from last October. The reduction to 3 categories take

[issue17629] Expose string width to Python

2013-04-03 Thread Ezio Melotti
Ezio Melotti added the comment: max(map(ord, s)) or your str_width(s) are not much more complicated than s.width(), just slower, so it's just a problem of performance. len() is a much more common operation so it makes sense to have a fast built-in function. -- ___

[issue17629] Expose string width to Python

2013-04-03 Thread Chris Angelico
Chris Angelico added the comment: CPython also knows the length of a string, which means that len(s) is a fast operation. I wouldn't expect anyone to rewrite len() as: def get_string_length(s): length=0 for ch in s: length+=1 return length even though that works. No, we have a built-

[issue17629] Expose string width to Python

2013-04-03 Thread STINNER Victor
STINNER Victor added the comment: "This is, on some occasions, useful to know; for instance, when testing string performance, it's handy to be able to very quickly throw something down that, without scanning the contents of all the strings used, can identify the width spread." When you test s

[issue17629] Expose string width to Python

2013-04-03 Thread Ezio Melotti
Ezio Melotti added the comment: Not sure this is a good idea. The fact that CPython knows the width is an implementation detail. The method you suggested might not be too fast but it works, so we would be adding a new function/method just to optimize a fairly uncommon operation that depends

[issue17629] Expose string width to Python

2013-04-03 Thread Chris Angelico
Chris Angelico added the comment: And of course, I make a copy/paste error in a trivial piece of example code. def str_width(s): width=1 for ch in map(ord,s): if ch > 0x: return 4 if ch > 0xFF: width=2 return width -- ___ Python tra

[issue17629] Expose string width to Python

2013-04-03 Thread Chris Angelico
New submission from Chris Angelico: As of PEP 393, a string's width is recorded in its header - effectively, a marker that says whether the highest codepoint in the string is >0x, >0xFF, or <=0xFF. This is, on some occasions, useful to know; for instance, when testing string performance, i