[Python-Dev] UCS2/UCS4 default (original) (raw)

Terry Reedy tjreedy at udel.edu
Thu Jul 3 19:44:19 CEST 2008

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

More information about the Python-Dev mailing list