[Patches] [ python-Patches-536241 ] string.zfill and unicode
noreply@sourceforge.net
noreply@sourceforge.net
Wed, 17 Apr 2002 13:50:56 -0700
Patches item #536241, was opened at 2002-03-28 08:26
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536241&group_id=5470
Category: Library (Lib)
Group: None
Status: Open
Resolution: Accepted
Priority: 5
Submitted By: Walter Dörwald (doerwalter)
Assigned to: Walter Dörwald (doerwalter)
Summary: string.zfill and unicode
Initial Comment:
This patch makes the function string.zfill work with
unicode instances (and instances of str and unicode
subclasses). Currently string.zfill(u"123", 10)
results in "0000u'123'". With this patch the result is
u'0000000123'.
Should zfill be made a real str und unicode method? I
noticed that a zfill implementation is available in
unicodeobject.c, but commented out.
----------------------------------------------------------------------
>Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-17 16:50
Message:
Logged In: YES
user_id=6380
The test seems fine, and a good addition. Don't worry too
much about how to report the failure (though perhaps
including the key word "subtype" in the error output might
help).
I noticed that when I change the Unicode function fixup() to
not do a check for subclasses, I only get very few failures:
one for capitalize, two for lower, one for upper. I think
this is because the test suite doesn't have enough sample
cases where the output is the same as the input. Maybe some
could be added.
But go ahead and check in diff3.txt.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-17 14:55
Message:
Logged In: YES
user_id=89016
Diff3.txt adds these tests to Lib/test/test_unicode.py and
Lib/test/test_string.py. All tests pass (except that
currently test_unicode.py fails the unicode_internal
roundtripping test with --enable-unicode=ucs4) and when I
change zfill back to always return self they properly fail.
I don't know whether the fail message should be made
better, and how this would interact with "make test" and
whether the "Prefer string methods over string module
functions" part in test_string.py might pose problems.
And maybe the code could be simplyfied to always use the
subclasses without first trying str und unicode?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 14:48
Message:
Logged In: YES
user_id=6380
If you want to be thorough, yes, that's a good test to add!
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-15 14:47
Message:
Logged In: YES
user_id=89016
Checked in as:
Objects/stringobject.c 2.159
Objects/unicodeobject.c 2.139
Maybe we could add a test to Lib/test/test_unicode.py and
Lib/test/test_string.py that makes sure that no method
returns a str/unicode subinstance even when called for a
str/unicode subinstance?
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 14:29
Message:
Logged In: YES
user_id=6380
Yes, that's the right thing. Reopened this for now.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-15 14:23
Message:
Logged In: YES
user_id=89016
Currently zfill returns the original if nothing has to be
done. Should I change this to only do it, if it's a real
str or unicode instance? (as it was done lots of methods
for bug http://www.python.org/sf/460020)
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 10:47
Message:
Logged In: YES
user_id=6380
Yes, please open a separate bug report for those (I'd open a
separate report for each file with warnings, unless you have
an obvious fix).
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-15 10:43
Message:
Logged In: YES
user_id=89016
> Does your compiler not warn you? Or did
> you ignore warnings?
> (The latter's a sin in Python-land :-).
The warning was just lost in the long list of outputs.
Now that you mention it, there are still a few warnings
(gcc 2.96 on Linux):
Objects/unicodeobject.c: In function `PyUnicodeUCS4_Format':
Objects/unicodeobject.c:5574: warning: int format, long int
arg (arg 3)
Objects/unicodeobject.c:5574: warning: unsigned int format,
long unsigned int arg (arg 4)
libpython2.3.a(posixmodule.o): In function `posix_tmpnam':
Modules/posixmodule.c:5150: the use of `tmpnam_r' is
dangerous, better use `mkstemp'
libpython2.3.a(posixmodule.o): In function `posix_tempnam':
Modules/posixmodule.c:5100: the use of `tempnam' is
dangerous, better use `mkstemp'
Modules/pwdmodule.c: In function `initpwd':
Modules/pwdmodule.c:161: warning: unused variable `d'
Modules/readline.c: In function `set_completer_delims':
Modules/readline.c:273: warning: passing arg 1 of `free'
discards qualifiers from pointer target type
Modules/expat/xmlrole.c:7: warning: `RCSId' defined but not
used
Should I open a separate bug report for that?
> I've also folded some long lines that weren't
> your fault -- but I noticed that elsewhere you
> checked in some long lines;
> please try to limit line length to 78.
I noticed your descrobject.c checkin message.
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-15 09:53
Message:
Logged In: YES
user_id=6380
Thanks, Walter! Some nits:
The string_zfill() code you checked in caused two warnings
about modifying data pointed to by a const pointer. I've
removed the const, but I'd like to understand how come you
didn't catch this. Does your compiler not warn you? Or did
you ignore warnings? (The latter's a sin in Python-land :-).
I've also folded some long lines that weren't your fault --
but I noticed that elsewhere you checked in some long lines;
please try to limit line length to 78.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-15 09:41
Message:
Logged In: YES
user_id=89016
Checked in as:
Doc/lib/libstdtypes.tex 1.88
Lib/UserString.py 1.12
Lib/string.py 1.63
test/string_tests.py 1.13
test/test_unicode.py 1.54
Misc/NEWS 1.388
Objects/stringobject.c 2.157
Objects/unicodeobject.c 2.138
----------------------------------------------------------------------
Comment By: Guido van Rossum (gvanrossum)
Date: 2002-04-12 21:00
Message:
Logged In: YES
user_id=6380
I'm for making them methods. Walter, just check it in!
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-04-12 14:37
Message:
Logged In: YES
user_id=89016
Now that test_userstring.py works and fails (rev 1.6)
should we add zfill as str and unicode methods or change
UserString.zfill to use string.zfill?
I've made a patch (attached) that implements zfill as
methods (i.e. activates the version in unicodeobject.c that
was commented out and implements the same in stringobject.c)
(And it adds the test for unicode support back in.)
----------------------------------------------------------------------
Comment By: Martin v. Löwis (loewis)
Date: 2002-04-12 10:51
Message:
Logged In: YES
user_id=21627
Re: optional Unicode: Walter is correct; configuring with
--disable-unicode currently breaks the string module. One
might consider using types.StringTypes; OTOH, pulling in
types might not be desirable.
As for str vs. repr: Python was always using repr in zfill,
so changing it may break things.
So I recommend that Walter reverts Andrew's check-in and
applies his change.
----------------------------------------------------------------------
Comment By: Michael Hudson (mwh)
Date: 2002-03-30 06:25
Message:
Logged In: YES
user_id=6656
Hah, I was going to say that but was distracted by IE
wiping out the machine I'm sitting at.
Re-opening.
----------------------------------------------------------------------
Comment By: Walter Dörwald (doerwalter)
Date: 2002-03-30 06:16
Message:
Logged In: YES
user_id=89016
But Python could be compiled without unicode support (by
undefining PY_USING_UNICODE), and string.zfill should work
even in this case.
What about making zfill a real str and unicode method?
----------------------------------------------------------------------
Comment By: A.M. Kuchling (akuchling)
Date: 2002-03-29 11:24
Message:
Logged In: YES
user_id=11375
Thanks for your patch! I've checked it into CVS, with two
modifications. First, I removed the code to handle the case
where Python doesn't have a unicode() built-in; there's no
expection that
you can take the standard library for Python version N and use
it with version N-1, so this code isn't needed.
Second, I changed string.zfill() to take the str() and not the repr()
when it gets a non-string object because that seems to make
more sense.
----------------------------------------------------------------------
You can respond by visiting:
http://sourceforge.net/tracker/?func=detail&atid=305470&aid=536241&group_id=5470