type error on porting outfile.write

[pmiller@gnf.org]

I ported my code from the development to
application platform, I found a "type error"
on a fileout statement:

outfile.write(o bject.id +",")

Object.id is provided by a library routine
that is installed on both machines.

How do I fix this ?

Thanks,
Phil Miller

[Eric McCoy]

Re: type error on porting outfile.write

pmiller@gnf.org wrote:[color=blue]
> I ported my code from the development to
> application platform, I found a "type error"
> on a fileout statement:[/color]
[color=blue]
> outfile.write(o bject.id +",")[/color]

What is the type of object.id? I'm guessing an integer. The exception
should tell you, e.g.:

TypeError: unsupported operand type(s) for +: 'int' and 'str'

If I'm right, you can do this:

outfile.write(" %d," % (object.id))

Though probably the better solution is to find out what code is
assigning an unexpected value to object.id.

[Dave Hansen]

Re: type error on porting outfile.write

On Tue, 20 Dec 2005 22:11:01 -0500 in comp.lang.pytho n, Eric McCoy
<ctr2sprt@comca st.net> wrote:
[color=blue]
>pmiller@gnf.or g wrote:[color=green]
>> I ported my code from the development to
>> application platform, I found a "type error"
>> on a fileout statement:[/color]
>[color=green]
>> outfile.write(o bject.id +",")[/color]
>
>What is the type of object.id? I'm guessing an integer. The exception
>should tell you, e.g.:
>
> TypeError: unsupported operand type(s) for +: 'int' and 'str'
>
>If I'm right, you can do this:
>
> outfile.write(" %d," % (object.id))[/color]

Or, more generally,

outfile.write(" %s, " % object.id)

or even (closer to the original code)

outfile.write(s tr(object.id)+" , ")

Regards,
-=Dave

--
Change is inevitable, progress is not.

[Eric McCoy]

Re: type error on porting outfile.write

Dave Hansen wrote:[color=blue]
> or even (closer to the original code)
>
> outfile.write(s tr(object.id)+" , ")[/color]

That was going to be my suggestion too, but that can mask the underlying
bug since a lot of types have __str__ methods. Not only could those
types theoretically return a valid stringified integer by coincidence,
if they don't you know nothing except "something went wrong." Getting a
TypeError would be much more useful for tracking down the bug.

Basically it would be shorthand for:

assert(isinstan ce(object.id, int))
outfile.write(s tr(object.id) + ", ")

Although I guess in his case, where the bug may be in a library over
which he has no control, it would be better to do:

assert(isinstan ce(object.id, int) or isinstance(obje ct.id, str))
outfile.write(" %s, " % (object.id))

since that code will run unmodified on both platforms he's using and
still give him error checking.