[issue26126] Possible subtle bug when normalizing and str.translate()ing

Mark Summerfield added the comment: Thanks for looking at this. In my full translation dict I had some other mistakes of case, now all fixed:-) -- ___ Python tracker ___ ___

[issue26126] Possible subtle bug when normalizing and str.translate()ing

SilentGhost added the comment: Mark, your XFORMS dictionary contains this entry: 0x00C6: "ae" It should be 'AE'. The same applies to 0x0152: "oe" which should be 'OE'. -- nosy: +SilentGhost resolution: -> not a bug stage: -> resolved ___ Python trac

[issue26126] Possible subtle bug when normalizing and str.translate()ing

Changes by SilentGhost : -- status: open -> closed ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail

[issue26126] Possible subtle bug when normalizing and str.translate()ing

Peter Otten added the comment: Not a bug. In your XFORMS dict you have >>> ord("Æ") == 0xC6 True Whether the value of "Æ" or 0xC6 is used by str.maketrans() depends on the order of the dict entries which in turn is determined by the keys' hash. Remove one and you should see consistent results

[issue26126] Possible subtle bug when normalizing and str.translate()ing

Peter Otten added the comment: There seems to be a connection to hash randomization. I consistently get $ PYTHONHASHSEED=1 python3.6 ./normbug.py BUG ('The aenid oevre', '!=', 'The AEnid oevre') $ PYTHONHASHSEED=0 python3.6 ./normbug.py OK ('The AEnid oevre', '==', 'The AEnid oevre')

[issue26126] Possible subtle bug when normalizing and str.translate()ing

New submission from Mark Summerfield: I am using Python 3.4.3 on Xubuntu 14.04 LTS 64-bit. I have a program that when run repeatedly sometimes what I expect, and sometimes does not: $ ~/tmp/normbug.py OK ('The AEnid oevre', '==', 'The AEnid oevre') $ ~/tmp/normbug.py OK ('The AEnid oevre', '