Follow-up Comment #9, bug #64445 (project health):
[comment #8 comment #8:] > > [comment #7 comment #7:] > > > > > 42[Y] 11[M] 9[D] > > looks good. I have update the code, and find the result is not good, looks not beautiful, so I prefer zero widht space. you can update to this changeset to test: https://hg.savannah.gnu.org/hgweb/health/rev/dae8c77285e8 > > > > > Going back to this representation, I think is the best approach. > > Easy to split and get elements, and it could allow more than 1 char, although I also think that translation should be kept to 1 character. > > > what about use "zero-width space" New code use 'zero width space', seem to works well: See https://hg.savannah.gnu.org/hgweb/health/rev/79ddda7c36c5 > > >>> print('hello\u200bworld') > helloworld > >>> 'hello\u200bworld'.split('\u200b') > ['hello', 'world'] > > > > > > Question.. how about non-ascii chars, and non-latin representation? (like in the case of Chinese..) Can we represent it with a single char? > > Yes, Chinese only use a single char. > > year = 年 or 岁 > month = 月 > day = 日 or 天 > > > > Today we have the ascii-escaped representation, that would take more than one char. > > I think at the moment 'ascii-escaped' only exist in json string, we always load the json string, so it seem to no problem. > > > > > We'll go back to the debate on ensure_ascii argument in json.dumps. Let's explore this more. > > > > Best > > Luis > > > > _______________________________________________________ Reply to this item at: <https://savannah.gnu.org/bugs/?64445> _______________________________________________ Message sent via Savannah https://savannah.gnu.org/
