Fredrik Lundh wrote:
> that's probably because finalizers *are* called when Python exits.
D'oh! Old semantics? I'm sure I remember this used to not work at some
point, and not just in Jython.
My apologies to anyone who I led astray. Still ... better to be too
careful ;) I've been trying to find
Delaney, Timothy C (Timothy) wrote:
> Remember, finalisers are not called when Python exits. So if you don't
> explicitly close the file you are *writing* to, it may not be flushed
> before being closed (by the OS because the process no longer exists).
Wrong.
% python
Python 2.3 (#1, Sep 13 2003,
Peter Hansen wrote:
> > Remember, finalisers are not called when Python exits. So if you don't
> > explicitly close the file you are *writing* to, it may not be flushed
> > before being closed (by the OS because the process no longer exists).
>
> Ouch... I'd forgotten/never heard that I guess. If
My understanding is that Python code should keep as many possible
implementations in mind. For example, I have been told that it would be
unwise to do something like this in Jython because the Java GC will not
reclaim the file resources:
for afile in more_than_just_a_few_files:
for aline in o
Mike mentions an important point, and I've been bitten by the
phenomenon Mike mentions---but only when *writing* to files. They
should always be closed explicitly, as in
f = file(filename, 'w')
f.write(somestring)
f.close()
On the other hand, I've never encountered a problem with the "for line
Delaney, Timothy C (Timothy) wrote:
> Peter Hansen wrote:
>>In my opinion, if the code fits on one screen and just reads stuff
>>from one file and, maybe, writes to another, you can safely and with
> ^^
>>clean conscience ignore Mike's advice (but remember it for lat
Peter Hansen wrote:
> In my opinion, if the code fits on one screen and just reads stuff
> from one file and, maybe, writes to another, you can safely and with
^^
> clean conscience ignore Mike's advice (but remember it for later!).
Remember, finalisers are not cal
Mike Meyer wrote:
> I'd like to note that failing to close the file explicitly is a bad
> habit. You really should invoke the close method, rather than relying
> on the garbage collector to close them for you. This means you do need
> a variable to hold the file object. 99% of the time nothing bad
"Michael Hartl" <[EMAIL PROTECTED]> writes:
> I'd also like to note that both the inputfiles variable and the
> readlines() method are superfluous; to iterate through the file line by
> line, use either
>
> for line in open(inputfilename):
> # do something with line
>
> or (my personal prefere
Alex Nordhus wrote:
...
> for ln in inputfile.readlines():
> words = string.split(ln)
> if len(words) >= 2:
> # print (words[1])
Try:
print >>outputfile, words[1]
--Scott David Daniels
[EMAIL PROTECTED]
--
http://mail.python.org/mailman/listinfo/python-lis
I'd also like to note that both the inputfiles variable and the
readlines() method are superfluous; to iterate through the file line by
line, use either
for line in open(inputfilename):
# do something with line
or (my personal preference, since I like to think of the file as a
thing rather th
Alex Nordhus wrote:
> Im trying to grab a colum of data from a text file and write it to a
new
> file.
> I am having trouble getting It to write the data to newlines. Python
is
> making it one
> Long string without any spaces when it writes the file. The first
> character is capitalized in colum 2.
Try
outputfile.write(words[1]+"\n")
On Tuesday 10 May 2005 10:57 am, Alex Nordhus wrote:
> outputfile.write(words[1])
--
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
http://www.jamesstroud.com/
--
http://mail.python.org/mailman/listinfo/python-l
That worked! Thank you so much!
--
http://mail.python.org/mailman/listinfo/python-list
write() doesn't automatically add a newline like print does.
You can either do:
outputfile.write(words[1] + '\n')
or
print >> outputfile, words[1]
--
http://mail.python.org/mailman/listinfo/python-list
15 matches
Mail list logo
