change the first character of the line to uppercase in a text file

[powah]

How to change the first character of the line to uppercase in a text
file?
e.g.
input is:
abc xyz
Bd ef
gH ij

output should be:
Abc xyz
Bd ef
GH ij

 

[Emile van Sebille]

On 6/26/2009 12:43 PM powah said...

How to change the first character of the line to uppercase in a text
file?
e.g.
input is:
abc xyz
Bd ef
gH ij

output should be:
Abc xyz
Bd ef
GH ij

How far have you gotten?

Emile

 

[Chris Rebert]

How to change the first character of the line to uppercase in a text
file?
e.g.
input is:
abc xyz
Bd ef
gH ij

output should be:
Abc xyz
Bd ef
GH ij

We're not in the business of doing homework. Some hints though:

`s.upper()` converts the string in variable `s` to all upper case
(e.g. "aBcD".upper() --> "ABCD")
`for line in afile:` iterates over each line in a file object. `afile`
is the file object and `line` gets assigned each line in turn.
`s[x]` gets you the (x+1)-th character in the string `s` (e.g.
"abcd"[2] --> "c")

And here are the docs on working with files:
http://docs.python.org/library/functions.html#open
http://docs.python.org/library/stdtypes.html#file-objects

That should be enough to get you started.

Cheers,
Chris

 

[Tim Chase]

How to change the first character of the line to uppercase in a text
file?
e.g.
input is:
abc xyz
Bd ef
gH ij

output should be:
Abc xyz
Bd ef
GH ij

While you're asking the Python list, I'd just use GNU sed:

sed -i 's/./\U&/' myfile.txt

I don't know if the "\U"=="make the replacement uppercase" is a
GNU-sed specific thing, but it works here on my Debian box's
version 4.1.5 when I tested it.

-tkc

 

[powah]

How to change the first character of the line to uppercase in a text
file?
e.g.
input is:
abc xyz
Bd ef
gH ij

output should be:
Abc xyz
Bd ef
GH ij

We're not in the business of doing homework. Some hints though:

`s.upper()` converts the string in variable `s` to all upper case
(e.g. "aBcD".upper() --> "ABCD")
`for line in afile:` iterates over each line in a file object. `afile`
is the file object and `line` gets assigned each line in turn.
`s[x]` gets you the (x+1)-th character in the string `s` (e.g.
"abcd"[2] --> "c")

And here are the docs on working with files:http://docs.python.org/library/func...python.org/library/stdtypes.html#file-objects

That should be enough to get you started.

Cheers,
Chris
--http://blog.rebertia.com

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

 

[Angus Rodgers]

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

 

[Angus Rodgers]

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

Strangely enough, it seems to do so, but why?

 

[Peter Otten]

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

Strangely enough, it seems to do so, but why?

Because there aren't any. When you read lines from a file there will always
be at least the newline character. Otherwise it would indeed fail:
.... print line[0].upper() + line[1:]
....
Peter
Paul
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
IndexError: string index out of range

 

[Angus Rodgers]

Strangely enough, it seems to do so, but why?

Because there aren't any. When you read lines from a file there will always
be at least the newline character. Otherwise it would indeed fail:
... print line[0].upper() + line[1:]
...
Peter
Paul
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
IndexError: string index out of range

Hmm ... the \r\n sequence at the end of a Win/DOS file seems to be
treated as a single character.

 

[Angus Rodgers]

the \r\n sequence at the end of a Win/DOS file

Of course, I meant the end of a line of text, not the end of
the file.

(I promise I'll try to learn to proofread my posts. This is
getting embarrassing!)

 

[Angus Rodgers]

Hmm ... the \r\n sequence at the end of a Win/DOS file seems to be
treated as a single character.

For instance, if test001A.txt is this file:

abc xyz
Bd ef

gH ij

and test001E.py is this:

f = open('test001A.txt', 'r')
for line in f:
print repr(line)

then the output from "python test001E.py > temp.txt" is this:

'abc xyz\n'
'Bd ef\n'
'\n'
'gH ij\n'

and indeed the output from "print repr(f.read())" is this:

'abc xyz\nBd ef\n\ngH ij\n'

How do you actually get to see the raw bytes of a file in Windows?

OK, this seems to work:

f = open('test001A.txt', 'rb') # Binary mode
print repr(f.read())

Output:

'abc xyz\r\nBd ef\r\n\r\ngH ij\r\n'

Indeed, when a Windows file is opened for reading in binary mode,
the length of an "empty" line is returned as 2. This is starting
to make some sense to me now.

 

[Peter Otten]

On Sat, 27 Jun 2009 11:39:28 +0100, I asked rhetorically:

Will your program handle empty lines of input correctly?

Strangely enough, it seems to do so, but why?

Because there aren't any. When you read lines from a file there will
always be at least the newline character. Otherwise it would indeed fail:

for line in "peter\npaul\n\nmary".splitlines():

... print line[0].upper() + line[1:]
...
Peter
Paul
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
IndexError: string index out of range

Hmm ... the \r\n sequence at the end of a Win/DOS
line

seems to be treated as a single character.

Yes, but "\n"[1:] will return an empty string rather than fail.

 

[Angus Rodgers]

Angus Rodgers wrote:

On Sat, 27 Jun 2009 11:39:28 +0100, I asked rhetorically:

Will your program handle empty lines of input correctly?

Strangely enough, it seems to do so, but why?

Because there aren't any. When you read lines from a file there will
always be at least the newline character. Otherwise it would indeed fail:

for line in "peter\npaul\n\nmary".splitlines():
... print line[0].upper() + line[1:]
...
Peter
Paul
Traceback (most recent call last):
File "<stdin>", line 2, in <module>
IndexError: string index out of range

Hmm ... the \r\n sequence at the end of a Win/DOS
line

seems to be treated as a single character.

Yes, but "\n"[1:] will return an empty string rather than fail.

Yes, I understood that, and it's logical, but what was worrying me
was how to understand the cross-platform behaviour of Python with
regard to the different representation of text files in Windows
and Unix-like OSs. (I remember getting all in a tizzy about this
the last time I tried to do any programming. That was in C++,
about eight years ago. Since then, I've only written a couple of
short BASIC programs for numerical analysis on a TI-84+ calculator,
and I feel as if I don't understand ANYTHING any more, but I expect
it'll come back to me. Sorry about my recent flurry of confused
posts! If I have any silly questions of my own, I'll post then to
the Tutor list, but in this instance, I imagined I knew what I was
talking about, and didn't expect to get into difficulties ...) 8-P

 

[Peter Otten]

Yes, I understood that, and it's logical, but what was worrying me
was how to understand the cross-platform behaviour of Python with
regard to the different representation of text files in Windows
and Unix-like OSs. (I remember getting all in a tizzy about this

If you are concerned about line endings open the file in universal newline
mode:

f = open(filename, "rU")

"""
In addition to the standard fopen values mode may be 'U' or 'rU'. Python is
usually built with universal newline support; supplying 'U' opens the file
as a text file, but lines may be terminated by any of the following: the
Unix end-of-line convention '\n', the Macintosh convention '\r', or the
Windows convention '\r\n'. All of these external representations are seen as
'\n' by the Python program. If Python is built without universal newline
support a mode with 'U' is the same as normal text mode. Note that file
objects so opened also have an attribute called newlines which has a value
of None (if no newlines have yet been seen), '\n', '\r', '\r\n', or a tuple
containing all the newline types seen.
"""

 

[D'Arcy J.M. Cain]

f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

Strangely enough, it seems to do so, but why?

The clue is the comma at the end of the print statement. It is there
because no lines are empty. They have at least a newline.

 

[Terry Reedy]

Because there aren't any. When you read lines from a file there will always
be at least the newline character. Otherwise it would indeed fail:

Except possibly for the last line.

 

[Piet van Oostrum]

TR> Except possibly for the last line.

But then that line wouldn't be empty either.

If there is an empty line not terminated by a newline after the last
newline, then that is called 'end-of-file' :=)

 

[Peter Otten]

Except possibly for the last line.

It may not end with a newline, but it will still contain at least one
character.

 

[Emile van Sebille]

On 6/27/2009 3:39 AM Angus Rodgers said...

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

It will when the final line is changed to:

print line[:1].upper()+line[1:]


Emile

 

[MRAB]

On 6/27/2009 3:39 AM Angus Rodgers said...

Thank you for your hint.
This is my solution:
f = open('test', 'r')
for line in f:
print line[0].upper()+line[1:],

Will your program handle empty lines of input correctly?

It will when the final line is changed to:

print line[:1].upper()+line[1:]

'line' will _never_ be ''. If a line ends with a newline then that will
be preserved returned as part of the string. This applies to the 'file'
methods 'readline', 'readlines', etc, and the iterator, which returns a
line. 'readline' will return '' only when it has reached the end of the
file.