On Mar 11, 2:28 pm, jmfauth <wxjmfa...@gmail.com> wrote: > On 11 mar, 03:06, Terry Reedy <tjre...@udel.edu> wrote: > > > > > ... > > By teaching 'speed before correctness", this site promotes bad > > programming habits and thinking (and the use of low-level but faster > > languages). > > ... > > This is exactly what "your" flexible string representation > does!
This is an old complaint of your with no new data for supporting it > > And away from technical aspects, you even succeeded to > somehow lose unicode compliance. This is a new complaint. Just to make it clear: 1. All your recent complaints about unicode were in the realm of performance So your complaint that python has lost unicode compliance can mean one of: 2a. The unicode standard mandates performance criteria or 2b. There are problems with python's implementation (of strings?) that have functional problems apart from your old performance complaints or 2c. You need to look up what 'compliance' means My own choice is to have a mid-point between Very early binding: Narrow vs wide builds Very late binding: String reps can change with the characters as they are seen This mid point would be perhaps a commandline switch to choose string- engine attributes. However to make this choice even worth a second look we need to have hard data about performance that you have been unable to provide. [See the recent thread of RoR vs Django to see the problems of excessive spurious choice] -- http://mail.python.org/mailman/listinfo/python-list