At least with Python there's only one obvious way to do something :-)
I'll see your simplification and raise (or lower) you a line.
Why not simply:
for item in file('hosts.txt'):
tn = telnetlib.Telnet(item.strip())
Jeff
Message
From: tutor-bounces (AT) python (DOT) org [mailto:tutor-bounces (AT) python (DOT) org]
Behalf Kent Johnson
Sent: Wednesday, May 10, 2006 5:52 AM
Cc: tutor (AT) python (DOT) org
Subject: Re: [Tutor] For loop question
w chun wrote:
another thing is that if the host file is large, you may wish to
iterate through the file one line at a time with a list comprehension
to do the stripping for you:
HostFile = open("hosts.txt", 'r')
for item in [x.strip() for x in HostFile]:
:
Why is this better when the file is large? It still creates a list with
all lines in it.
if you are using Python 2.4+, you can come up with an even better
solution by using a generator expression that does lazier, ad hoc
evaluation:
HostFile = open("hosts.txt", 'r')
for item in (x.strip() for x in HostFile):
:
this one will read and strip one line from the file as you process it
while the previous solution still needs to come up with the entire
list of stripped hosts before the for-loop can begin.
I would use this, it avoids reading the entire file at once and IM is
clear and straightforward:
HostFile = open('hosts.txt')
for item in HostFile:
item = item.strip()
or even
HostFile = open('hosts.txt')
for item in HostFile:
tn = telnetlib.Telnet(item.strip())
Kent
Tutor maillist - Tutor (AT) python (DOT) org
Tutor maillist - Tutor (AT) python (DOT) org

>HostFile = open("hosts.txt", 'r')
>for item in [x.strip() for x in HostFile]:
>:
>>
>>Why is this better when the file is large? It still creates a list with
all lines in it.

yup, that's why i mention this fact below while giving the genex solution.

Why not simply:

for item in file('hosts.txt'):
tn = telnetlib.Telnet(item.strip())

If you are willing to depend on the runtime to close the file that is
fine. If you want to close it yourself you have to keep a reference to
the open file.

For short Python scripts I usually allow the runtime to close the file.
For longer programs and anything written in Jython (which has different
garbage collection behaviour) I usually use an explicit close().

i'm still not comfortable without doing my own explicit close(), esp.
for writing to files maybe i'm just used to malloc/new-free pairs
like i am with open-close, although on the other hand, getting rid of
another line of code is tempting -- so i will actually do this with a
short piece of code that is read-only.

note for the uninitiated, open() == file(), or rather, open == file, or rather:

open is file
True
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

Tutor maillist - Tutor (AT) python (DOT) org

>For short Python scripts I usually allow the runtime to close the file.
>For longer programs and anything written in Jython (which has different
>garbage collection behaviour) I usually use an explicit close().
>
i'm still not comfortable without doing my own explicit close(), esp.
for writing to files maybe i'm just used to malloc/new-free pairs
like i am with open-close, although on the other hand, getting rid of
another line of code is tempting -- so i will actually do this with a
short piece of code that is read-only.

Yes, for writing files I always use an explicit close(), thanks for the
correction!

those of you who are going to be using 2.5 have this feature automated
for you when using the new 'with' statement: when the 'with' clause
(or suite) finishes, Python will automagically close() your file for
you, read or write, so this is one case you can leave it out.

for example:

with open('log.txt', 'w') as f:
:
f.write()
:
# f is closed when we get here

without going into the details of context managers here for objects to
be used with the 'with' statement, let's just say that an __enter__()
method is called before the block is executed, and an __exit__()
method is called after the suite has completed.

for file objects, fileexit__ *is* file.close. (for the curious,
this is implemented in /fileobject.c if you've got the 2.5
source.)

looking fwd,
-- wesley
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
"Core Python Programming", Prentice Hall, (c)2007,2001
http://corepython.com

wesley.j.chun :: wescpy-at-gmail.com
python training and technical consulting
cyberweb.consulting : silicon valley, ca
http://cyberwebconsulting.com

Tutor maillist - Tutor (AT) python (DOT) org

w chun wrote:
Kent Johnson wrote:
>For short Python scripts I usually allow the runtime to close the file.
>For longer programs and anything written in Jython (which has different
>garbage collection behaviour) I usually use an explicit close().

i'm still not comfortable without doing my own explicit close(), esp.
for writing to files maybe i'm just used to malloc/new-free pairs
like i am with open-close, although on the other hand, getting rid of
another line of code is tempting -- so i will actually do this with a
short piece of code that is read-only.

Yes, for writing files I always use an explicit close(), thanks for the
correction!

Kent

Tutor maillist - Tutor (AT) python (DOT) org