[Quoting restored for reducedOn Usenet? You'll be wanting single unequivocal answers next!Seriously though, you had been asked several times for the traceback,
so that we could stop guessing and tell you for sure what was going
on, and you hadn't provided it. Diez's mild sarcasm was not uncalled-
for. The fact that you didn't have a traceback partially excuses you,
but it would have helped if you'd said so.You're catching the IOError, presumably so that you can fail
gracefully elsewhere. This may not be a particularly good
idea, and in any case it stops the exception reaching the
console where it would cause the traceback to be displayed.As other people have pointed out, you've got a typo here.[Huge amounts of text trimmed]Fair enough, you're catching the IOError so that you can
ensure that DataFH is closed. Unfortunately this concealed
the traceback information, which would have made it more
obvious to you what people were talking about. Given that
this has rather stuffed your C8DataType instance, you
might want to think about re-raising the exception after
you've closed DataFH and letting the outer layers deal
with it in a more appropriate fashion.Incidentally, this code isn't going to do anything useful
for you anyway even after you've fixed the typo. DataFH
and ResourceFH are both local variables to __init__ and
will be tossed away when it finishes executing. If you
want to use them later, make them self.data_fh and
self.resource_fh respectively.(PEP 8 recommends that you use lower_case_with_underscores
for variable or attribute names, and leave MixedCase for
class names.)- Show quoted text -
Very good comments. I'll be implementing some of your suggestions, to
be sure. Thanks Rhodri.
[Quoting restored for reduced
This is written very slowly, so you can read it better:
Please post without sarcasm.
On Usenet? You'll be wanting single unequivocal answers next!
Seriously though, you had been asked several times for the traceback,
so that we could stop guessing and tell you for sure what was going
on, and you hadn't provided it. Diez's mild sarcasm was not uncalled-
for. The fact that you didn't have a traceback partially excuses you,
but it would have helped if you'd said so.
This is the output from my Python shell:
DatafilePath = "C:\\C8Example1.slc"
ResourcefilePath = DatafilePath + ".rsc"
DatafileFH = open(DatafilePath)
ResourceFh = open(ResourcefilePath)
DatafilePath
'C:\\C8Example1.slc'>>> ResourcefilePath
'C:\\C8Example1.slc.rsc'
It seems to run without trouble. However, here is the offending code
in my class (followed by console output):
class C8DataType:
def __init__(self, DataFilepath):
try:
DataFH = open(DataFilepath, "rb")
except IOError, message:
# Error opening file.
print(message)
return None
You're catching the IOError, presumably so that you can fail
gracefully elsewhere. This may not be a particularly good
idea, and in any case it stops the exception reaching the
console where it would cause the traceback to be displayed.
ResourceFilepath = DataFilepath + ".src"
As other people have pointed out, you've got a typo here.
print(DataFilepath)
print(ResourceFilepath)
# Try to open resource file, catch exception:
try:
ResourceFH = open(ResourceFilepath)
except IOError, message:
# Error opening file.
print(message)
print("Error opening " + ResourceFilepath)
DataFH.close()
return None
[Huge amounts of text trimmed]
Fair enough, you're catching the IOError so that you can
ensure that DataFH is closed. Unfortunately this concealed
the traceback information, which would have made it more
obvious to you what people were talking about. Given that
this has rather stuffed your C8DataType instance, you
might want to think about re-raising the exception after
you've closed DataFH and letting the outer layers deal
with it in a more appropriate fashion.
Incidentally, this code isn't going to do anything useful
for you anyway even after you've fixed the typo. DataFH
and ResourceFH are both local variables to __init__ and
will be tossed away when it finishes executing. If you
want to use them later, make them self.data_fh and
self.resource_fh respectively.
(PEP 8 recommends that you use lower_case_with_underscores
for variable or attribute names, and leave MixedCase for
class names.)Very good comments. I'll be implementing some of your suggestions, to
be sure. Thanks Rhodri.
You could check to see if the file actually exists using os.path.exists
(). I've found that if I use that in combination with printing the
path variable, I sometimes discover that either my file doesn't exist
or that my path is slightly wrong and thus Python doesn't think my
file exists...
Mike
John said:*AND* please post the text of the IOError message
*AND* please do yourself a favour and move your files out of the root
directory into a directory with a meaningful name
Want to reply to this thread or ask your own question?
You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.