Just getting this on Larry's radar and summarising the current position.

The original problem: using "char *" to pass filenames around doesn't work properly on Windows, we need to use Unicode objects.

The solution: parallel APIs that accept PyObject * rather than char * for the filename parameters.

The new problem: both Serhiy and I find the *Object() suffix currently used for those "filename as Unicode object instead of C string" parallel APIs to be ambiguous and confusing. However, the problem the parallel APIs solve is real, and reverting or excessively modifying any of the work Victor has already done would be silly.

That means we're now in a situation where we have to either:

* accept *Object as the suffix for all of these APIs indefinitely, even though it's ambiguous and confusing
* choose a new suffix and use that for the APIs already added in 3.4 and add compatibility aliases for the older APIs to make them consistent
* change the public API additions already made for 3.4 to new private APIs by adding an underscore prefix, and then reconsider the public API naming question for 3.5
* accept *Object as the suffix for the moment, but aim to replace it with something more descriptive in Python 3.5

Neither Serhiy nor I are comfortable with the first option, and making a decision in haste for the second option doesn't seem like a good idea. Option 3 seems like far too much work to make things less useful (a capability that works, but has an ambiguous and confusing name, is better than a capability that isn't provided at all)

That leaves option number 4: don't change anything further now, but revisit it for 3.5, including changing the preferred name of the existing APIs.

I like that approach, so I'm assigning to myself to take a closer look at how some of the suggestions above read in the docs once 3.4 is out the door.