On Friday, 25 April 2014 10:05:03 UTC-4, Chris Angelico wrote:
> First culprit I'd look at is the mixing of subprocess and threading.
> It's entirely possible that something goes messy when you fork from a
> thread.
I liked the theory, but I've run some tests and can't reproduce the error that
way. I'm using all the elements in my test code that the real code runs, and I
can't get the same error. Even when I deliberately break things I'm getting a
proper exception with stack trace.
class MyThread(threading.Thread):
def __init__(self):
threading.Thread.__init__(self)
def run(self):
logger = logging.getLogger("thread")
p1 = subprocess.Popen( shlex.split( 'echo "MyThread calls echo."'),
stdout=subprocess.PIPE, universal_newlines=True)
logger.debug( p1.communicate()[0].decode('utf-8', 'ignore' ))
logger.debug( "MyThread runs and exits." )
def main():
console = logging.StreamHandler()
console.setFormatter(
logging.Formatter('%(asctime)s [%(name)-12s] %(message)s', '%T'))
logger = logging.getLogger()
logger.addHandler(console)
logger.setLevel(logging.NOTSET)
try:
t = MyThread()
#t = RTF2TXT("../data/SRD/rtf/", Queue.Queue())
t.start()
except Exception as e:
logger.error( "Failed with {!r}".format(e))
if __name__ == '__main__':
main()
> Separately: You're attempting a very messy charset decode there. You
> attempt to decode as UTF-8, errors ignored, and if that fails, you log
> an error... and continue on with the original bytes. You're risking
> shooting yourself in the foot there; I would recommend you have an
> explicit fall-back (maybe re-decode as Latin-1??), so the next code is
> guaranteed to be working with Unicode. Currently, it might get a
> unicode or a str.
Yeah, that was a logic error on my part that I hadn't got around to noticing,
since I'd been concentrating on the stuff that was actively breaking. That
should have been in an else: block on the end of the try.
--
https://mail.python.org/mailman/listinfo/python-list
