[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_SimpleString("from time import time,ctime\n"
"print('Today is', ctime(time()))\n");
Py_Finalize();
return 0;
}
contradicts the actual implementation of the code:
http://hg.python.org/cpython/file/tip/Include/pythonrun.h#l25
which leads to compiler errors. To fix them, ugly wchar_t to char conversions
are needed.
Also, I was hoping, Python 3.3 finally switched from wchar_t to char and UTF-8.
at least that's how I understood PEP 393 http://python.org/dev/peps/pep-0393/
see also:
http://stackoverflow.com/questions/21591908/python-3-3-c-string-handling-wchar-t-vs-char
=> Are the docs wrong (which i hope are not, the example is straightforward and
simple-stupid with a char*),
or is cpython wrong?
--
components: Unicode
messages: 224327
nosy: ezio.melotti, haypo, thejj
priority: normal
severity: normal
status: open
title: python c api wchar_t*/char* passing contradiction
type: compile error
versions: Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issue22108>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue22108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 is only needed for the user input software (xorg, keyboard input) and user output (-> your terminal emulator, the gui, ...). No matter what stuff your program receives, the encoding only matters for the actual output display software to select the correct visual representation. Requiring a conversion to wide chars just increases the interface complexity and adds really unneeded data transformations that are completely obsolete with UTF-8. 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*). This allows super-easy integration in C projects that probably all just use char as their string type (see the doc example mentioned earlier). PEP 393 states: "(..) the specification chooses UTF-8 as the recommended way of exposing strings to C code." And for that, I think using char instead of wchar_t is a better solution for interface developers. -- ___ Python tracker <http://bugs.python.org/issue22108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <http://bugs.python.org/issue22108> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22270] cache version selection for documentation
New submission from Jonas Jelten: The Python version selection for the documentation should be cached. It's very annoying having to select the preferred version each time one follows a link, e.g. search result, irc post, etc. I'd like to see caching the preferred version in a cookie and automatically switching to this python version when opening doc pages. -- assignee: docs@python components: Documentation messages: 225847 nosy: docs@python, thejj priority: normal severity: normal status: open title: cache version selection for documentation type: enhancement versions: Python 2.7, Python 3.1, Python 3.2, Python 3.3, Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue22270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22270] cache version selection for documentation
Jonas Jelten added the comment: it should rather be a opt-in feature. and when the redirection triggered, one should be able do click (you know it from wikipedia) back to page where one was redireced from. -- ___ Python tracker <http://bugs.python.org/issue22270> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26532] build fails with address sanitizer
Changes by Jonas Jelten : -- nosy: +jj ___ Python tracker <http://bugs.python.org/issue26532> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
