TypeError: an integer is required

[Dave Angel]

Lutfi Oduncuoglu wrote:
> Hello,
>
> I am a newbie on oython and I am taking the error at subject my code is
> below, I am trying to develop a qgis plugin and lines begin with # is the
> thing that I tried. Thus sys.stdout gives the type error. When I comment
> that line it turns an error like below. What may be the problem? thanks for
> help:)
>
> ...\ReadData.py", line 128, in run
>     print "%d %s" %(k, attr.toString())
> IOError: [Errno 9] Bad file descriptor
>
>   
(Comment #2 is critical, but I didn't notice it right away.  Remove that 
line   "from os import *"  and use "import os"  instead.  )

This error is caused by binding the wrong kind of open to stdout.  
os.open() returns a file descriptor (integer), while stdout is expected 
to be a "file" object.

As for your previous error "an integer is required" it'd certainly be 
nice if you showed us the error message.  You say it was on a line 
beginning with "#" but there are many of those, none of them near the 
present error.

Taking a wild guess, I see another open for sys.stdout:

sys.stdout = open('C://Users//lutfi//Documents//tezzzz//log.txt', 777 )

But that line causes a "file() argument 2 must be string, not int"  
error.  You want "w" or "a" or something like that, rather than a 
mysterious 777 for that.

Just randomly jumping around in your code, consider what happens if you 
have the following line:

print "%d %s" %(k, attr)

and k is a string.  Then you'd get:   "%d format: a number is required, 
not str"

Well, enough guessing.  You need to give a complete traceback, as you 
did for the "bad file descriptor"

And you'd also need to specify Python version, as the messages might be 
different between your version and the 2.6 that I'm trying it with.

Other comments:

1) Are you coming from a java background?  In Python you do not need to 
put everything in a class definition.

2) the   "from xxxx import *"   form is discouraged, and you use it 
several times.  I know some GUI packages specify it, and there you're 
best off by following their conventions.  But for modules like os, 
you're asking for trouble.  In this case, the built-in open() function 
that you need is being hidden by the os.open() call, which is not the 
one you wanted.  So you'll get syntax errors and funny runtime errors, 
just because you're calling different functions that what you think you are.

3) You have import within other defs.  This is unnecessary if the module 
has already been imported (such as sys), and is considered bad form in 
almost all cases.
There are only two common cases where an import might not appear right 
at the top of the module:
   A) when you want to conditionally import a module, based on some 
runtime choice.  Example would be to import a Unix version or a Windows 
version of some module.
    B) When a module will only be used in some unlikely case, such as in 
error handling.
    C) when a module is very slow to import, and you need to speed up 
startup time.

4) Simplified example code would do two things:   
    A) easier for us to follow, especially those of us that don't happen 
to use the same libraries that you do.
    B) by simplifying it, you can frequently find the problem yourself, 
which is a great way to learn

5) If you have two different error messages, but only have one version 
of the code, make both tracebacks complete, and make sure we know what's 
changed between the two versions.


HTH,
DaveA