Re: TypeError: an integer is required
Lutfi Oduncuoglu wrote:
> 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
> ...\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
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,
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.
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
C) when a module is very slow to import, and you need to speed up
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.
|All times are GMT. The time now is 12:24 AM.|
Powered by vBulletin®. Copyright ©2000 - 2013, vBulletin Solutions, Inc.
SEO by vBSEO ©2010, Crawlability, Inc.