Thanks for the comments. Quick notes:
1. Yes, ultimate goal is to output various fields into Excel, but I need to
enter the data into a DB as well to avoid having any strange problems. That may
be handled by a completely different process. I should have been more exact in
saying that my
On Tue, 03 May 2005 19:12:07 GMT, Peter A. Schott
[EMAIL PROTECTED] wrote:
Thanks for the comments. Quick notes:
1. Yes, ultimate goal is to output various fields into Excel,
Peter, (again) I'd like to suggest that putting some or all of the
data into storage of type X (whether X is a database
John Machin wrote:
[Michael Hoffman]:
What if the input is UTF-16? Your solution won't work for that. And there
are certainly UTF-16 CSV files out in the wild.
The csv module docs do say that Unicode is not supported.
This does appear to work, however, at least for data that could in
fact be
On Sat, 30 Apr 2005 23:11:48 -0400, Steve Holden [EMAIL PROTECTED]
wrote:
John Machin wrote:
If the job at hand is simulating awk's file reading habits, yes then
fileinput is convenient. However if the job at hand involves anything
like real-world commercial data processing requirements then
John Machin wrote:
I beg your pardon. How does: Your point addresses the letter rather
than the spirit of the 'law' sound?
Sure, thanks.
Real-world data is not text.
A lot of real-world data is. For example, almost all of the data I deal with
is text.
That's nice. Well I agree with you, if the OP
On Sat, 30 Apr 2005 11:35:05 +0100, Michael Hoffman
[EMAIL PROTECTED] wrote:
John Machin wrote:
Real-world data is not text.
A lot of real-world data is. For example, almost all of the data I deal with
is text.
OK, depends on one's definitions of data and text. In the domain
of commercial
John Machin wrote:
[...]
I wouldn't use fileinput for a commercial data processing exercise,
because it's slow, and (if it involved using the Python csv module) it
opens the files in text mode, and because in such exercises I don't
often need to process multiple files as though they were one file.
John Machin wrote:
That's nice. Well I agree with you, if the OP is concerned about embedded
CRs, LFs and ^Zs in his data (and he is using Windows in the latter case),
then he *definitely* shouldn't use fileinput.
And if the OP is naive enough not to be concerned, then it's OK, is
it?
It simply
On Sat, 30 Apr 2005 09:23:16 -0400, Steve Holden [EMAIL PROTECTED]
wrote:
John Machin wrote:
[...]
I wouldn't use fileinput for a commercial data processing exercise,
because it's slow, and (if it involved using the Python csv module) it
opens the files in text mode, and because in such
On Sat, 30 Apr 2005 14:31:08 +0100, Michael Hoffman
[EMAIL PROTECTED] wrote:
John Machin wrote:
That's nice. Well I agree with you, if the OP is concerned about embedded
CRs, LFs and ^Zs in his data (and he is using Windows in the latter case),
then he *definitely* shouldn't use fileinput.
And
John Machin wrote:
On Sat, 30 Apr 2005 09:23:16 -0400, Steve Holden [EMAIL PROTECTED]
wrote:
John Machin wrote:
[...]
I wouldn't use fileinput for a commercial data processing exercise,
because it's slow, and (if it involved using the Python csv module) it
opens the files in text mode, and
That looks promising. The field numbers are pre-defined at the mainframe level.
This may help me get to my ultimate goal which is to pump these into a DB on a
row-by-row basis ( :-P ) I'll have to do some playing around with this. I
knew that it looked like a dictionary, but wasn't sure how
On Fri, 29 Apr 2005 18:54:54 GMT, Peter A. Schott
[EMAIL PROTECTED] wrote:
That looks promising.
The field numbers are pre-defined at the mainframe level.
Of course. Have you managed to acquire a copy of the documentation, or
do you have to reverse-engineer it?
This may help me get to my
John Machin wrote:
[Michael Hoffman]:
for row in csv.reader(fileinput.input()):
csv.reader requires that if the first arg is a file that it be opened
in binary mode.
fileinput.input() is not a file.
I have tested this code and it works fine for the provided example.
--
Michael Hoffman
--
On Fri, 29 Apr 2005 23:21:43 +0100, Michael Hoffman
[EMAIL PROTECTED] wrote:
John Machin wrote:
[Michael Hoffman]:
for row in csv.reader(fileinput.input()):
csv.reader requires that if the first arg is a file that it be opened
in binary mode.
fileinput.input() is not a file.
John Machin wrote:
[Michael Hoffman]:
John Machin wrote:
[Michael Hoffman]:
for row in csv.reader(fileinput.input()):
csv.reader requires that if the first arg is a file that it be opened
in binary mode.
fileinput.input() is not a file.
Hair-splitter.
Is name-calling really necessary?
It's an awk
On Sat, 30 Apr 2005 00:40:50 +0100, Michael Hoffman
[EMAIL PROTECTED] wrote:
John Machin wrote:
[Michael Hoffman]:
John Machin wrote:
[Michael Hoffman]:
for row in csv.reader(fileinput.input()):
csv.reader requires that if the first arg is a file that it be opened
in binary mode.
I've got a file that seems to come across more like a dictionary from what I can
tell. Something like the following format:
###,1,val_1,2,val_2,3,val_3,5,val_5,10,val_10
###,1,val_1,2,val_2,3,val_3,5,val_5,11,val_11,25,val_25,967,val_967
In other words, different layouts (defined mostly by what
On Thu, 28 Apr 2005 23:34:31 GMT, Peter A. Schott
[EMAIL PROTECTED] wrote:
I've got a file that seems to come across more like a dictionary from what I
can
tell. Something like the following format:
###,1,val_1,2,val_2,3,val_3,5,val_5,10,val_10
Peter A. Schott wrote:
I've got a file that seems to come across more like a dictionary from what I can
tell. Something like the following format:
###,1,val_1,2,val_2,3,val_3,5,val_5,10,val_10
###,1,val_1,2,val_2,3,val_3,5,val_5,11,val_11,25,val_25,967,val_967
Peter, I'm not sure exactly what you
20 matches
Mail list logo
