4 ms·

> This is the first time I encounter the idiom Unix strings The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C. >> [...] proba

by dded 13y ago

> This is the first time I encounter the idiom Unix strings The usual idiom is C-strings, but I wanted to emphasize the OS, not the language C. >> [...] probably a vain hope that Unix strings will vanish [...] >If only we wait for them to vanish, doing nothing to improve. The article is about the lack of Python3 adoption. In my case, Python3's poor handling of Unix/C strings is friction. It sounds like you believe that Unix/C strings can be made to go away in the near future. I do not believe this. (I'm not even certain that it's a good idea.)

gkya 13y ago
I do not insist that C strings must die, I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present. I fully support strings to be Unicode-by-default in Python, as most people will put text in between double quotes, not a bunch of bytes represented by textual characters. I do not expect C or Unix interpretations of strings to change, but I believe that they must be considered low-level and require higher-level language user to explicitly request the compiler to interpret a piece of data in such fashion. My first name is "Göktuğ". Honestly, which one of the following is rather desirable for me, do you think? Python 2.7.4 (default, Sep 26 2013, 03:20:26) >>> "Göktuğ" 'G\xc3\xb6ktu\xc4\x9f' or Python 3.3.1 (default, Sep 25 2013, 19:29:01) >>> "Göktuğ" 'Göktuğ'
- dded 13y ago
  I'm not arguing against you. I just don't write any code that has to deal with people's names, so that's just not a problem that I face. I fully acknowledge that lack of Unicode is a big problem of Python2, but it's not my problem. A Unix filename, on the other hand, might be any sort of C string. This sort of thing is all over Unix, not just filenames. (When I first ever installed Python3 at work back when 3.0 (3.1?) came out, one of the self tests failed when it tried to read an unkosher string in our /etc/passwd file.) When I code with Python2, or Perl, or C, or Emacs Lisp, I don't need to worry about these C strings. They just work. My inquiry, somewhere up this thread, is whether or not it would be possible to solve both problems. (Perhaps by defaulting to utf-8 instead of ASCII. I don't know, I'm not a language designer.)
- dded 13y ago
  > I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present OK, maybe I do see one small point to argue. A C string, such as one that might be used in Unix, is not necessarily text. But text, represented as utf-8, is a C string. It seems like there's something to leverage here, at least for those points at which Python3 interacts with the OS.

by dded 13y ago

gkya 13y ago

I do not insist that C strings must die, I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present. I fully support strings to be Unicode-by-default in Python, as most people will put text in between double quotes, not a bunch of bytes represented by textual characters. I do not expect C or Unix interpretations of strings to change, but I believe that they must be considered low-level and require higher-level language user to explicitly request the compiler to interpret a piece of data in such fashion. My first name is "Göktuğ". Honestly, which one of the following is rather desirable for me, do you think? Python 2.7.4 (default, Sep 26 2013, 03:20:26) >>> "Göktuğ" 'G\xc3\xb6ktu\xc4\x9f' or Python 3.3.1 (default, Sep 25 2013, 19:29:01) >>> "Göktuğ" 'Göktuğ'

dded 13y ago
I'm not arguing against you. I just don't write any code that has to deal with people's names, so that's just not a problem that I face. I fully acknowledge that lack of Unicode is a big problem of Python2, but it's not my problem. A Unix filename, on the other hand, might be any sort of C string. This sort of thing is all over Unix, not just filenames. (When I first ever installed Python3 at work back when 3.0 (3.1?) came out, one of the self tests failed when it tried to read an unkosher string in our /etc/passwd file.) When I code with Python2, or Perl, or C, or Emacs Lisp, I don't need to worry about these C strings. They just work. My inquiry, somewhere up this thread, is whether or not it would be possible to solve both problems. (Perhaps by defaulting to utf-8 instead of ASCII. I don't know, I'm not a language designer.)
dded 13y ago
> I insist that C strings are indeed arrays of bytes, and we cannot use them to represent text correctly at present OK, maybe I do see one small point to argue. A C string, such as one that might be used in Unix, is not necessarily text. But text, represented as utf-8, is a C string. It seems like there's something to leverage here, at least for those points at which Python3 interacts with the OS.