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
--
http://mail.python.org/mailman/listinfo/python-list
