➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author christian.heimes
Recipients christian.heimes
Date 2007-10-12.03:10:47
SpamBayes Score 0.00046038307
Marked as misclassified No
Message-id <1192158648.5.0.179668399301.issue1268@psf.upfronthosting.co.za>
In-reply-to
Content 
The array module is using a different typecode for unicode array
depending on UCS2 or UCS4:

#define Py_UNICODE_SIZE 4

#if Py_UNICODE_SIZE >= 4
#define Py_UNICODE_WIDE
#endif

#ifdef Py_UNICODE_WIDE
#define PyArr_UNI 'w'
#define PyArr_UNISTR "w"
#else
#define PyArr_UNI 'u'
#define PyArr_UNISTR "u"
#endif

It's causing a bunch of unit test to fail which depend on 'u' as the
type code for an unicode array. I don't see the benefit from specifying
an alternative typecode for wide unicode arrays. It may be useful to
have an additional typecode that fails for UCS-2 builds.

My patch keeps 'u' in every build and adds 'w' as an alias for 'u' in
UCS-4 builds only. It also introduces the new module variable typecodes
which is a unicode string containing all valid typecodes.
Files
File name Uploaded
py3k_array_typecode.patch christian.heimes, 2007-10-12.03:10:47
History
Date User Action Args
2007-10-12 03:10:49christian.heimessetspambayes_score: 0.000460383 -> 0.00046038307
recipients: + christian.heimes
2007-10-12 03:10:48christian.heimessetspambayes_score: 0.000460383 -> 0.000460383
messageid: <1192158648.5.0.179668399301.issue1268@psf.upfronthosting.co.za>
2007-10-12 03:10:48christian.heimeslinkissue1268 messages
2007-10-12 03:10:47christian.heimescreate