Message135372
| Author |
dcoles |
| Recipients |
dcoles, lemburg, loewis, pitrou, vstinner |
| Date |
2011年05月06日.21:42:10 |
| SpamBayes Score |
4.671525e-08 |
| Marked as misclassified |
No |
| Message-id |
<BANLkTin_etyvNB1ZQOAzAF-3_W2rtqEv8Q@mail.gmail.com> |
| In-reply-to |
<1304717095.82.0.106731542637.issue12010@psf.upfronthosting.co.za> |
| Content |
On Fri, May 6, 2011 at 2:24 PM, Martin v. Löwis <report@bugs.python.org> wrote:
>
> Martin v. Löwis <martin@v.loewis.de> added the comment:
>
> I think what they mean is a better representation from an Android API, such as UChar32 from utils/AndroidUnicode.h.
Ah. Sadly I don't think that's exposed in the NDK yet.
> I agree that it's not worthwhile trying to port Python to those Android versions that have a single-byte wchar_t definition.
Yup. Will be using Android 2.3+. If I'm forced to use an earlier
version of Android I think it would be more sensible to use the 2.x
series of Python.
> David, I think you are misunderstanding the purpose of HAVE_USABLE_WCHAR_T: It does *not* specify whether wchar_t can be used. Instead, it specifies whether wchar_t can be used as the datatype for Py_UNICODE. Calling it HAVE_A_WCHAR_T_DEFINITION_THAT_IS_SUITABLE_FOR_USE_AS_BASE_TYPE_OF_PY_UNICODE was just a little too tedious :-)
Haha :). Yes. My initial reading of the pyconfig.h was wrong. Got a
bit suspicious when my Linux box was not defining it. Then I saw them
memcpy and it made sense. |
|