2007-08-24 23:26:07 -03:00
|
|
|
#ifndef STRINGLIB_UNICODEDEFS_H
|
|
|
|
#define STRINGLIB_UNICODEDEFS_H
|
|
|
|
|
|
|
|
/* this is sort of a hack. there's at least one place (formatting
|
|
|
|
floats) where some stringlib code takes a different path if it's
|
|
|
|
compiled as unicode. */
|
|
|
|
#define STRINGLIB_IS_UNICODE 1
|
|
|
|
|
2011-09-28 02:41:54 -03:00
|
|
|
#define FASTSEARCH fastsearch
|
|
|
|
#define STRINGLIB(F) stringlib_##F
|
2008-02-17 15:48:00 -04:00
|
|
|
#define STRINGLIB_OBJECT PyUnicodeObject
|
2011-10-11 18:22:22 -03:00
|
|
|
#define STRINGLIB_SIZEOF_CHAR Py_UNICODE_SIZE
|
2007-08-24 23:26:07 -03:00
|
|
|
#define STRINGLIB_CHAR Py_UNICODE
|
|
|
|
#define STRINGLIB_TYPE_NAME "unicode"
|
2007-09-01 07:56:01 -03:00
|
|
|
#define STRINGLIB_PARSE_CODE "U"
|
2007-08-24 23:26:07 -03:00
|
|
|
#define STRINGLIB_EMPTY unicode_empty
|
2010-01-13 04:07:53 -04:00
|
|
|
#define STRINGLIB_ISSPACE Py_UNICODE_ISSPACE
|
|
|
|
#define STRINGLIB_ISLINEBREAK BLOOM_LINEBREAK
|
2007-08-24 23:26:07 -03:00
|
|
|
#define STRINGLIB_ISDECIMAL Py_UNICODE_ISDECIMAL
|
|
|
|
#define STRINGLIB_TODECIMAL Py_UNICODE_TODECIMAL
|
|
|
|
#define STRINGLIB_STR PyUnicode_AS_UNICODE
|
|
|
|
#define STRINGLIB_LEN PyUnicode_GET_SIZE
|
|
|
|
#define STRINGLIB_NEW PyUnicode_FromUnicode
|
|
|
|
#define STRINGLIB_RESIZE PyUnicode_Resize
|
|
|
|
#define STRINGLIB_CHECK PyUnicode_Check
|
2009-11-29 21:01:42 -04:00
|
|
|
#define STRINGLIB_CHECK_EXACT PyUnicode_CheckExact
|
Merged revisions 63078 via svnmerge from
svn+ssh://pythondev@svn.python.org/python/trunk
When forward porting this, I added _PyUnicode_InsertThousandsGrouping.
........
r63078 | eric.smith | 2008-05-11 15:52:48 -0400 (Sun, 11 May 2008) | 14 lines
Addresses issue 2802: 'n' formatting for integers.
Adds 'n' as a format specifier for integers, to mirror the same
specifier which is already available for floats. 'n' is the same as
'd', but inserts the current locale-specific thousands grouping.
I added this as a stringlib function, but it's only used by str type,
not unicode. This is because of an implementation detail in
unicode.format(), which does its own str->unicode conversion. But the
unicode version will be needed in 3.0, and it may be needed by other
code eventually in 2.6 (maybe decimal?), so I left it as a stringlib
implementation. As long as the unicode version isn't instantiated,
there's no overhead for this.
........
2008-05-11 18:00:57 -03:00
|
|
|
#define STRINGLIB_GROUPING _PyUnicode_InsertThousandsGrouping
|
2009-04-03 11:45:06 -03:00
|
|
|
#define STRINGLIB_GROUPING_LOCALE _PyUnicode_InsertThousandsGroupingLocale
|
2008-02-17 15:48:00 -04:00
|
|
|
|
|
|
|
#if PY_VERSION_HEX < 0x03000000
|
|
|
|
#define STRINGLIB_TOSTR PyObject_Unicode
|
2008-06-11 15:37:52 -03:00
|
|
|
#define STRINGLIB_TOASCII PyObject_Repr
|
2008-02-17 15:48:00 -04:00
|
|
|
#else
|
2007-11-15 16:48:54 -04:00
|
|
|
#define STRINGLIB_TOSTR PyObject_Str
|
2008-06-11 15:37:52 -03:00
|
|
|
#define STRINGLIB_TOASCII PyObject_ASCII
|
2008-02-17 15:48:00 -04:00
|
|
|
#endif
|
2007-08-24 23:26:07 -03:00
|
|
|
|
2007-10-16 03:31:30 -03:00
|
|
|
#define STRINGLIB_WANT_CONTAINS_OBJ 1
|
|
|
|
|
2007-08-24 23:26:07 -03:00
|
|
|
#endif /* !STRINGLIB_UNICODEDEFS_H */
|