left padding zeroes on a string...

[cjl]

Hey all:

I want to convert strings (ex. '3', '32') to strings with left padded
zeroes (ex. '003', '032'), so I tried this:

string1 = '32'
string2 = "%03s" % (string1)
print string2

32

This doesn't work. If I cast string1 as an int it works:

string1 = '32'
int2 = "%03d" % (int(string1))
print int2

032

Of course, I need to cast the result back to a string to use it. Why
doesn't the first example work?

-cjl

 

[Peter Hansen]

Hey all:

I want to convert strings (ex. '3', '32') to strings with left padded
zeroes (ex. '003', '032'), so I tried this:

string1 = '32'
string2 = "%03s" % (string1)

string1.zfill(3)

-Peter

 

[George Sakkis]

Hey all:

I want to convert strings (ex. '3', '32') to strings with left padded
zeroes (ex. '003', '032'), so I tried this:

string1 = '32'
string2 = "%03s" % (string1)
print string2


This doesn't work.

Actually in this case string2 is padded with spaces, instead of zeros.

If I cast string1 as an int it works:

string1 = '32'
int2 = "%03d" % (int(string1))
print int2


Of course, I need to cast the result back to a string to use it. Why
doesn't the first example work?

That's not correct; int2 is a string so you can use it directly (and probably rename it to something
more appropriate).

-cjl

Regards,
George


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"To see victory only when it is within the ken of the common herd is not
the acme of excellence."

Sun Tzu, 'The Art of War'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[M.E.Farmer]

Your first conversion works fine.
string1 = '32'
string2 = "%04s" % (string1)
print string2
' 32'
Notice that it returns a string with spaces padding the left side.
If you want to pad a number with 0's on the left you need to use
zfill()
'32'.zfill(4)
'0032'
Be sure to study up on string methods, it will save you time and
sanity.
Py> dir('')
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
'__mul__', '__ne__', '__new__', '__reduce__', '__repr__', '__rmul__',
'__setattr__', '__str__', 'capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum',
'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper',
'join', 'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex',
'rjust', 'rstrip', 'split', 'splitlines', 'startswith', 'strip',
'swapcase', 'title', 'translate', 'upper', 'zfill']
Py> help(''.zfill)
Help on built-in function zfill:

zfill(...)
S.zfill(width) -> string

Pad a numeric string S with zeros on the left, to fill a field
of the specified width. The string S is never truncated.
Hth,
M.E.Farmer

 

[John Machin]

I want to convert strings (ex. '3', '32') to strings with left padded
zeroes (ex. '003', '032'), so I tried this:

string1 = '32'
string2 = "%03s" % (string1)
print string2


This doesn't work.

Documentation == """
Flag Meaning
0 The conversion will be zero padded for numeric values.
"""

"Numeric values" means when converting from a numeric value as in
"%03d", but not "%03s". If you think "numeric values" is vague or
misleading -- K&R (v2 p243) has "numeric conversions" -- then submit a
documentation patch.

If I cast string1 as an int it works:

Python doesn't have casts. You mean "convert".

You may like to consider the zfill method of string objects:
'00003'

or the even more versatile rjust method:

HTH,
John

 

[Kent Johnson]

Hey all:

I want to convert strings (ex. '3', '32') to strings with left padded
zeroes (ex. '003', '032')

In Python 2.4 you can use rjust with the optional fill argument:'003'

In earlier versions you can define your own: ... return ( c*l + s )[-l:]
...'032'

Kent

 

[George Sakkis]

[snipped]

Be sure to study up on string methods, it will save you time and
sanity.
Py> dir('')
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
'__mul__', '__ne__', '__new__', '__reduce__', '__repr__', '__rmul__',
'__setattr__', '__str__', 'capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum',
'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper',
'join', 'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex',
'rjust', 'rstrip', 'split', 'splitlines', 'startswith', 'strip',
'swapcase', 'title', 'translate', 'upper', 'zfill']

I'm getting off-topic here, but it strikes me that strings have so many methods (some of which are
of arguable utility, e.g. swapcase), while proposing two useful methods (http://tinyurl.com/5nv66)
for dicts -- a builtin with a considerably smaller API than str -- meets so much resistance. Any
insight ?

George


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Oh divine art of subtlety and secrecy! Through you we learn to be
invisible, through you inaudible and hence we can hold the enemy's fate
in our hands."

Sun Tzu, 'The Art of War'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[Larry Bates]

Once it is in everyone is hesitant to take it out for fear of
breaking someone's code that uses it (no matter how obscure).
Putting in new methods should be difficult and require lots
of review for that reason and so we don't have language bloat.

Larry Bates

[snipped]

Be sure to study up on string methods, it will save you time and
sanity.
Py> dir('')
['__add__', '__class__', '__contains__', '__delattr__', '__doc__',
'__eq__', '__ge__', '__getattribute__', '__getitem__', '__getslice__',
'__gt__', '__hash__', '__init__', '__le__', '__len__', '__lt__',
'__mul__', '__ne__', '__new__', '__reduce__', '__repr__', '__rmul__',
'__setattr__', '__str__', 'capitalize', 'center', 'count', 'decode',
'encode', 'endswith', 'expandtabs', 'find', 'index', 'isalnum',
'isalpha', 'isdigit', 'islower', 'isspace', 'istitle', 'isupper',
'join', 'ljust', 'lower', 'lstrip', 'replace', 'rfind', 'rindex',
'rjust', 'rstrip', 'split', 'splitlines', 'startswith', 'strip',
'swapcase', 'title', 'translate', 'upper', 'zfill']

I'm getting off-topic here, but it strikes me that strings have so many methods (some of which are
of arguable utility, e.g. swapcase), while proposing two useful methods (http://tinyurl.com/5nv66)
for dicts -- a builtin with a considerably smaller API than str -- meets so much resistance. Any
insight ?

George


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Oh divine art of subtlety and secrecy! Through you we learn to be
invisible, through you inaudible and hence we can hold the enemy's fate
in our hands."

Sun Tzu, 'The Art of War'
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

 

[George Sakkis]

Once it is in everyone is hesitant to take it out for fear of
breaking someone's code that uses it (no matter how obscure).
Putting in new methods should be difficult and require lots
of review for that reason and so we don't have language bloat.

Larry Bates

Language bloat is subjective of course, but I fail to see why putting in dict.reset and dict.add
should be harder than, say, str.swapcase or str.capitalize.

George

 

[Robert Kern]

Language bloat is subjective of course, but I fail to see why putting in dict.reset and dict.add
should be harder than, say, str.swapcase or str.capitalize.

Those were functions in the string module for, well much longer than I
can remember. When string methods were innovated, they became methods
along with the rest of the string module functions.

Adding functions was easier back then; the standard library was rather
smaller. There is no reason that the criteria for inclusion now must be
the same as then and plenty of good reasons for them to be more
restrictive now.

--
Robert Kern
(e-mail address removed)

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter

 

[Ron_Adam]

I'm getting off-topic here, but it strikes me that strings have so many methods (some of which are
of arguable utility, e.g. swapcase), while proposing two useful methods (http://tinyurl.com/5nv66)
for dicts -- a builtin with a considerably smaller API than str -- meets so much resistance. Any
insight ?

George

I did a quick check.
27

We need more tuple methods! jk

Looks like the data types, strings, int an float; have more methods
than dict, list, and tuple. I would expect that because there is more
ways to manipulate data than is needed to manage containers.

Ron

 

[Bengt Richter]

I did a quick check.

27

We need more tuple methods! jk

Looks like the data types, strings, int an float; have more methods
than dict, list, and tuple. I would expect that because there is more
ways to manipulate data than is needed to manage containers.

More data:
... if isinstance(v, type))): print '%4s: %s' %(n,k)
...
12: basestring
12: object
13: classmethod
13: staticmethod
14: enumerate
15: reversed
16: super
16: xrange
17: slice
18: property
23: buffer
27: tuple
27: type
34: file
34: open
37: frozenset
40: dict
42: list
45: float
48: complex
50: set
53: bool
53: int
53: long
60: unicode
63: str

Hm, I guess that includes inheritance, and they should be callable, so maybe (not researched)
... for k,v in ((k,v) for k,v in vars(__builtins__).items()
... if isinstance(v, type))): print '%4s: %s' %(n,k)
...
1: basestring
4: classmethod
4: enumerate
4: staticmethod
5: reversed
5: super
6: property
6: slice
7: xrange
9: bool
10: object
10: type
16: buffer
19: tuple
22: file
22: open
30: frozenset
33: dict
35: list
38: float
39: complex
44: set
46: int
46: long
53: unicode
56: str

Regards,
Bengt Richter