Add additional isxxx functions to string object.

[ehuss]

BPO	825313
Nosy	@malemburg, @loewis, @brettcannon, @gaul
Files	stringobject.c.patch: Add missing isxxx functions to stringobject.c.

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2003-10-24.20:49:46.000>
created_at = <Date 2003-10-17.05:47:23.000>
labels = ['interpreter-core']
title = 'Add additional isxxx functions to string object.'
updated_at = <Date 2003-10-24.20:49:46.000>
user = 'https://bugs.python.org/ehuss'

bugs.python.org fields:

activity = <Date 2003-10-24.20:49:46.000>
actor = 'brett.cannon'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['Interpreter Core']
creation = <Date 2003-10-17.05:47:23.000>
creator = 'ehuss'
dependencies = []
files = ['5638']
hgrepos = []
issue_num = 825313
keywords = ['patch']
message_count = 8.0
messages = ['44782', '44783', '44784', '44785', '44786', '44787', '44788', '44789']
nosy_count = 5.0
nosy_names = ['lemburg', 'loewis', 'brett.cannon', 'gaul', 'ehuss']
pr_nums = []
priority = 'low'
resolution = 'rejected'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue825313'
versions = ['Python 2.4']

[ehuss]

This patch adds the following ctype.h functions to the
string object.

iscntrl
isgraph
isprint
ispunct
isxdigit

These are pretty standard C functions...I'm not sure
why they were left out.

It also deletes a lot of duplicated code.

This patch might not be 100% useful because it does
not have the unicode equivalents. Thoughts?

[gaul]

Logged In: YES
user_id=139865

I like shedding ~80 lines with is_helper, especially if you
add inline. Otherwise, function call overhead might be
incurred for every call to C isfoo() instead of inlining the
comparison. I dislike increasing the distinction between
ASCII and Unicode strings, although Unicode strings already
have isdecimal and isnumeric methods which ASCII strings
lack. I would at least add iscntrl, ispunct, and isxdigit
to Unicode strings if they are added to ASCII strings.

[brettcannon]

Logged In: YES
user_id=357491

I don't really see a good use for any of these. Chances that most
people are going to need most of these is very minor (heck, I
don't even know what isgraph would test for).

isxdigit might be slightly helpful if you renamed it isnum, but you
can fake that already with x.isalnum() and not x.isalpha().

But in general I am -1 on these. str has enough methods as it is.

[loewis]

Logged In: YES
user_id=21627

The patch is incomplete, as it comes without documentation
and test cases. Eric, I would normally request these at this
point, but I'm also with Brett that wrapping these functions
might be useless.

What is the rationale for including them?

[ehuss]

Logged In: YES
user_id=393416

isprint is useful to make sure there are "safe" characters in a
string. In a tty-based application, and you have potentially
hostile text to display to the user, you want to make sure
that no terminal control characters are sent.

isgraph is exactly the same as isprint, except it does not
include the space character.

I do not understand Brett's comment about isxdigit. I would
avoid renaming it since the naming convention already follows
the C functions. And it is not the same as isalnum and
isalpha...which is the same as isdigit (which already exists).
isxdigit tests for a hexadecimal character (0-9 a-f A-F).

I think it would be mildly useful. I can follow up with a patch
for documentation and unit tests. As for Unicode support,
unforutnately I do not know where to begin to update
makeunicodedata.py.

[brettcannon]

Logged In: YES
user_id=357491

You don't need to understand my comment because I goofed. For
some reason I remember reading help(str.isdigit) and it
saying it only worked for a single character.

I still don't find these that useful. isgraph seems especially
useless since you could easily just strip the whitespace out and
then call isprint on it.

For the argument of keeping the names with C, that is not valid.
This is being introduced into Python for the first time and thus
should have a proper name. There is not enough of a widespread
connection to C in terms of these functions to have to worry about
keeping the name the same.

Regardless of all of this I am still -1 on all of the methods.

[malemburg]

Logged In: YES
user_id=38388

-1 from here. You can have the same using a regular expression
character group built using the unicodedata(base) or just
using a static mapping for 8-bit chars.

There are too few use cases for these methods that it would
make sense adding extra logic and static data to make the
mapping fast enough.

Brett, feel free to close this request.

[brettcannon]

Logged In: YES
user_id=357491

OK, having MA, Martin, and me say "no" works for me. This patch
is rejected. Sorry, Eric.

What you might want to do, though, Eric, is see if you could help
out with the proposed textutil module that has recently been
proposed on python-dev. Basically the only thing that would go
into this mystical module is a new string substitution function, but
this might have a place there. That thread is entitled "Can we
please have a better dict interpolation syntax?" from this month
(October 2003).