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
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 rep...@bugs.python.org
http://bugs.python.org/issue22108
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 rep...@bugs.python.org
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*.
--
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 C
Changes by Zachary Ware zachary.w...@gmail.com:
--
stage: - resolved
versions: -Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22108
___
Martin v. Löwis added the comment:
Jonas, why do you say that?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22108
___
___
Python-bugs-list
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.
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
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,
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 Python.h
int
main(int argc, char *argv[])
{
Py_SetProgramName(argv[0]); /* optional but recommended */
Py_Initialize();
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
STINNER Victor added the comment:
This issue is why I created the issue #18395.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue22108
___
___
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
14 matches
Mail list logo
