Prepare for encoding changes in Python 3

Prepare for encoding changes in Python 3

This is most of the remaining diff for porting to Python 3,
but this also works in Python 2.4 already (even though not
strictly needed).

Individual changes:
1. Encode strings before hashing

Python 3 requires "bytes-like objects". Apparently we can already
do so in Python 2, even though not needed for correctness.

2. Submit bytes-like objects to processes

Encode strings before writing to input and decode result after reading
from output or error stream.

3. Open midi and musicxml files in binary mode

Only decode once we are sure that the content is not compressed.

[lemzwerg, 2019-11-23 15:52:47]

LGTM, thanks!

[Dan Eble, 2019-11-23 16:45:17]

> 3. Open midi and musicxml files in binary mode
> Only decode once we are sure that the content is not compressed.

If an XML file is opened as a binary file, will the treatment of
platform-specific line endings become inconvenient for some people?

[hahnjo, 2019-11-24 11:47:01]

On 2019/11/23 16:45:17, Dan Eble wrote:
> > 3. Open midi and musicxml files in binary mode
> > Only decode once we are sure that the content is not compressed.
> 
> If an XML file is opened as a binary file, will the treatment of
> platform-specific line endings become inconvenient for some people?

I hope it does not: Once we know it's really text, the code will call
decode('utf-8') as before.

Do you have a specific case in mind that I should have a look at? I tested with
Python 2.4 and 2.7 on Linux, and it passes a full check + doc.

[Dan Eble, 2019-11-25 02:44:20]

On 2019/11/24 11:47:01, hahnjo wrote:
> On 2019/11/23 16:45:17, Dan Eble wrote:
> > If an XML file is opened as a binary file, will the treatment of
> > platform-specific line endings become inconvenient for some people?
> 
> I hope it does not: Once we know it's really text, the code will call
> decode('utf-8') as before.
> 
> Do you have a specific case in mind that I should have a look at? I tested
with
> Python 2.4 and 2.7 on Linux, and it passes a full check + doc.

Well, I don't have significant experience doing this kind of thing in Python,
but
what I'm wondering is whether an "\n" written in to a text XML file in binary
mode might make the XML look wrong when opened in a Windows app that
expects "\r\n".

[hahnjo, 2019-11-25 19:59:27]

On 2019/11/25 02:44:20, Dan Eble wrote:
> On 2019/11/24 11:47:01, hahnjo wrote:
> > On 2019/11/23 16:45:17, Dan Eble wrote:
> > > If an XML file is opened as a binary file, will the treatment of
> > > platform-specific line endings become inconvenient for some people?
> > 
> > I hope it does not: Once we know it's really text, the code will call
> > decode('utf-8') as before.
> > 
> > Do you have a specific case in mind that I should have a look at? I tested
> with
> > Python 2.4 and 2.7 on Linux, and it passes a full check + doc.
> 
> Well, I don't have significant experience doing this kind of thing in Python,
> but
> what I'm wondering is whether an "\n" written in to a text XML file in binary
> mode might make the XML look wrong when opened in a Windows app that
> expects "\r\n".

Ah, the patch is mostly about reading XML files - I'll improve the description.
But reading of different line endings still works, 01a-Pitches-Pitches.xml
transformed by unix2dos and unix2mac leads to identical results after processing
with musicxml2ly.