[Python-Dev] UCS2/UCS4 default
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