Nick Coghlan added the comment:

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.

assignee:  -> ncoghlan
nosy: +larry
priority: normal -> 
versions: +Python 3.5 -Python 3.4

Python tracker <>
Python-bugs-list mailing list

Reply via email to