2007-08-25 04:26:07 +02:00
|
|
|
#ifndef STRINGLIB_STRINGDEFS_H
|
|
|
|
#define STRINGLIB_STRINGDEFS_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 0
|
|
|
|
|
2008-02-17 20:48:00 +01:00
|
|
|
#define STRINGLIB_OBJECT PyStringObject
|
2007-08-25 04:26:07 +02:00
|
|
|
#define STRINGLIB_CHAR char
|
|
|
|
#define STRINGLIB_TYPE_NAME "string"
|
2007-09-01 12:56:01 +02:00
|
|
|
#define STRINGLIB_PARSE_CODE "S"
|
2008-02-17 20:48:00 +01:00
|
|
|
#define STRINGLIB_EMPTY nullstring
|
2007-08-25 04:26:07 +02:00
|
|
|
#define STRINGLIB_ISDECIMAL(x) ((x >= '0') && (x <= '9'))
|
|
|
|
#define STRINGLIB_TODECIMAL(x) (STRINGLIB_ISDECIMAL(x) ? (x - '0') : -1)
|
2008-02-17 20:48:00 +01:00
|
|
|
#define STRINGLIB_TOUPPER toupper
|
|
|
|
#define STRINGLIB_TOLOWER tolower
|
2007-08-25 04:26:07 +02:00
|
|
|
#define STRINGLIB_FILL memset
|
|
|
|
#define STRINGLIB_STR PyString_AS_STRING
|
|
|
|
#define STRINGLIB_LEN PyString_GET_SIZE
|
|
|
|
#define STRINGLIB_NEW PyString_FromStringAndSize
|
|
|
|
#define STRINGLIB_RESIZE _PyString_Resize
|
|
|
|
#define STRINGLIB_CHECK PyString_Check
|
|
|
|
#define STRINGLIB_CMP memcmp
|
|
|
|
#define STRINGLIB_TOSTR PyObject_Str
|
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 23:00:57 +02:00
|
|
|
#define STRINGLIB_GROUPING _PyString_InsertThousandsGrouping
|
2007-08-25 04:26:07 +02:00
|
|
|
|
|
|
|
#endif /* !STRINGLIB_STRINGDEFS_H */
|