On 03/07/2013 04:23 PM, John Nagle wrote:
raise RuntimeError, 'open() requires mode "r", "U", or "rU"'
RuntimeError: open() requires mode "r", "U", or "rU"
"b" for files is about end of line handling (CR LF -> LF), anyway.
Only for Python 2. Since originally you didn't specif
On Thu, Mar 7, 2013 at 3:13 PM, John Nagle wrote:
> On 3/7/2013 10:42 AM, John Nagle wrote:
>> On 3/7/2013 5:10 AM, Dave Angel wrote:
>>> On 03/07/2013 01:33 AM, John Nagle wrote:
Here's a traceback that's not helping:
>>>
>>> A bit more context would be helpful. Starting with Python ve
On 3/7/2013 10:42 AM, John Nagle wrote:
> On 3/7/2013 5:10 AM, Dave Angel wrote:
>> On 03/07/2013 01:33 AM, John Nagle wrote:
>>> Here's a traceback that's not helping:
>>>
>>
>> A bit more context would be helpful. Starting with Python version.
>
> Sorry, Python 2.7.
The trouble comes from
On 3/7/2013 5:10 AM, Dave Angel wrote:
> On 03/07/2013 01:33 AM, John Nagle wrote:
>>
>> "infdraw" is a stream from the zip module, create like this:
>>
>> with inzip.open(zipelt.filename,"r") as infd :
>
> You probably need a 'rb' rather than 'r', since the file is not ASCII.
>
>>
On 3/7/2013 5:10 AM, Dave Angel wrote:
> On 03/07/2013 01:33 AM, John Nagle wrote:
>> Here's a traceback that's not helping:
>>
>
> A bit more context would be helpful. Starting with Python version.
Sorry, Python 2.7.
>
> If that isn't enough, then please give the whole context, such as wh
On 03/07/2013 01:33 AM, John Nagle wrote:
Here's a traceback that's not helping:
A bit more context would be helpful. Starting with Python version.
Traceback (most recent call last):
File "InfoCompaniesHouse.py", line 255, in
main()
File "InfoCompaniesHouse.py", line 251, in mai
On Wed, Mar 6, 2013 at 10:33 PM, John Nagle wrote:
> Here's a traceback that's not helping:
> UnicodeEncodeError: 'ascii' codec can't encode character u'\xa3' in
> position 14: ordinal not in range(128)
> The program is converting some .CSV files that come packaged in .ZIP
> files. The files ar
On 2013.03.07 00:33, John Nagle wrote:
> This is wierd, becuase "for fields in reader" isn't directly
> doing a decode. That's further down somewhere, and the backtrace
> didn't tell me where.
Looking at the csv module docs,the reader object iterates over the
csvfile argument (which can be any iter
Here's a traceback that's not helping:
Traceback (most recent call last):
File "InfoCompaniesHouse.py", line 255, in
main()
File "InfoCompaniesHouse.py", line 251, in main
loader.dofile(infile) # load this file
File "InfoCompaniesHouse.py", line 213, in dofile