On 12/01/2015 21:45, Andrew Koenig wrote:
It runs and creates a classes.txt file with 803 lines. The first few:
<class 'str'> -> '$cpfile12'
<class 'str'> -> '$crfile12'
<class 'str'> -> '$cxfile12'
<class 'str'> -> '*'
<class 'str'> -> '.$cp'
<class 'str'> -> '.$cr'
<class 'str'> -> '.$cx'
<class 'str'> -> '.386'
<class 'str'> -> '.3ds'
A few lines in the middle that might be relevant:
<class 'str'> -> '.py'
<class 'str'> -> '.pyc'
<class 'str'> -> '.pyo'
<class 'str'> -> '.pys'
<class 'str'> -> '.pyw'
And the last few:
<class 'str'> -> '{C7A40493-BF23-4B53-AB2A-4A923B3EE34B}\x00'
<class 'str'> -> '{E14E55A7-29C8-4389-8E5A-3EF964510FCA}\x00'
<class 'str'> -> '{F5E30566-7C8F-4037-A8FF-A7382E251C56}\x00'
Anything in particular I should be looking for?
I was actually expecting to see something like a byestring, but in fact
those last few items look suspicious with their trailing NULs. The
mimetypes code tries to open each key to find its associated mimetype(s)
and would probably fail on those.
The PyArg_ParseTupleAndKeywords in OpenKey is using the "Z" pattern for
its first parameter which disallows embedded NULs. Obviously we can
trap-and-skip within the mimetypes code but that won't help you
immediately (short of your patching your own lib/mimetypes).
Is it possible to temporarily rename those keys out of the way, or to
strip their trailing NULs to see if the problem goes away?
TJG
--
https://mail.python.org/mailman/listinfo/python-list
