I must be missing something obvious in installing Python 3.4.2...

[Tim Golden]

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