[Python-Dev] UCS2/UCS4 default

[Terry Reedy]

Daniel Arbuckle wrote:

> Regardless, as I said before, nothing justifies silently changing the
> meaning of a program based on an option that most users don't set for
> themselves and are not aware of.

The premise of this thread seems to be that the majority should suffer 
for the benefit of a few.  That is not Python's philosophy.

Python hides many system differences.  It is gradually hiding more.  For 
instance, float('nan') works uniformly in 2.6 (with little performance 
hit), whereas it was system specific in 2.5  But Python does not promise 
to hide all system differences.

If the possible effects of (unicode) string build choice are not 
properly documented, then I agree that they should be, just as they are 
(or, in some cases, I presume are) the effects of underlying OS, 
processor integer and pointer size, float scheme, garbage collection 
scheme, and perhaps something I forgot.

Suggested documentation changes can be submitted to the tracker as 
specific ascii text targeted at a specific location.  If accepted, the 
doc maintainers will adapt submitted text to 'doc style' and add the 
needed markup.  Current response time is usually under a week, perhaps 
even a day.

Documented effects are not 'silent'.  But I am sure they could be made a 
bit louder.  Perhaps someday someone will volunteer to contribute a 
chapter to Using Python on Possible Semantic Variations that would run 
through the issues listed above so they are gathered together in one 
place as well as scattered throughout the Language and Library Reference 
manuals.

 > When such a change would take place,
> it should be reported explicitly as an error.

No, possible changes should be documented so that they are not silent. 
(But I am curious, by 'would' do you mean 'would with the current data' 
or 'theoretically could with chosen data'?)

Terry Jan Reedy