[issue22108] python c api wchar_t*/char* passing contradiction

Changes by Zachary Ware : -- stage: -> resolved versions: -Python 3.3 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsub

[issue22108] python c api wchar_t*/char* passing contradiction

Martin v. Löwis added the comment: Jonas: Python's string type is a Unicode character type, unlike C's (which is wishy-washy when it comes to characters outside of the "basic execution character set"). So just declaring that all APIs take UTF-8 will *not* allow for easy integration with other

[issue22108] python c api wchar_t*/char* passing contradiction

STINNER Victor added the comment: > I still pledge for Python 4? always using char* internally to make this > conversion obsolete ;) (except for windows) I don't understand your proposition. We try to have duplicating functions for char* and wchar*. -- ___

[issue22108] python c api wchar_t*/char* passing contradiction

Jonas Jelten added the comment: Indeed, that should do it, thanks. I still pledge for Python 4? always using char* internally to make this conversion obsolete ;) (except for windows) -- ___ Python tracker ___

[issue22108] python c api wchar_t*/char* passing contradiction

STINNER Victor added the comment: I updated the embedding and extending examples but I didn't try them. @Jonas: Can you please try the updated examples? -- ___ Python tracker __

[issue22108] python c api wchar_t*/char* passing contradiction

Roundup Robot added the comment: New changeset 94d0e842b9ea by Victor Stinner in branch 'default': Issue #18395, #22108: Update embedded Python examples to decode correctly http://hg.python.org/cpython/rev/94d0e842b9ea -- nosy: +python-dev ___ Python

[issue22108] python c api wchar_t*/char* passing contradiction

STINNER Victor added the comment: > What I'd really like to see in CPython is that the internal storage (and the > way it's exposed in the C-API) is just raw bytes (=> char*). Python is portable, we care of Windows. On Windows, wchar_t* is the native type for strings (ex: command line, environ

[issue22108] python c api wchar_t*/char* passing contradiction

Jonas Jelten added the comment: Martin, i think the most intuitive and easiest way for working with strings in C are just char arrays. Starting with the main() argv being char*, probably most programmers just go with char* and all the encoding just works. This is because contact with encoding

[issue22108] python c api wchar_t*/char* passing contradiction

Zachary Ware added the comment: See also issue20466 (which has a patch for this, but I cannot speak for its effectiveness). I'd be in favor of closing that issue and this one as duplicates of #18395, and noting in #18395 that the embedding example must be updated before that issue is closed.

[issue22108] python c api wchar_t*/char* passing contradiction

Martin v. Löwis added the comment: Jonas, why do you say that? -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe

[issue22108] python c api wchar_t*/char* passing contradiction

Jonas Jelten added the comment: I'd say Python should definitely change its internal string type to char*. Exposing "handy" wchar_t->char conversion functions don't resolve the data represenation enhancement. -- ___ Python tracker

[issue22108] python c api wchar_t*/char* passing contradiction

STINNER Victor added the comment: This issue is why I created the issue #18395. -- ___ Python tracker ___ ___ Python-bugs-list mailing

[issue22108] python c api wchar_t*/char* passing contradiction

Martin v. Löwis added the comment: You were misinterpreting PEP 393 - it is only about the representation of string objects, and doesn't affect any pre-existing API. Changing Py_SetProgramName is not possible without breaking existing code, so it could only happen in Python 4. A proper solut

[issue22108] python c api wchar_t*/char* passing contradiction

New submission from Jonas Jelten: The documentation and the code example at https://docs.python.org/3.5/extending/embedding.html#very-high-level-embedding #include int main(int argc, char *argv[]) { Py_SetProgramName(argv[0]); /* optional but recommended */ Py_Initialize(); PyRun_Simple