Aleksandr Koshkin added the comment:
Originally I emphasized that this bug occurs at every py3k version since 3.2.
For some reason version list somehow shrinked to only tow of them - 3.5 and
3.6. I am very sorry, this is probably my fault.
--
resolution: fixed ->
status: clo
Aleksandr Koshkin added the comment:
Conclusion made: not a bug (not a python bug at least).
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issu
Aleksandr Koshkin added the comment:
So, yes, unicode table seems to be a bit inconsistent. In str documentation it
worth to emphasize that something.upper().lower() in general not equals to
something.
--
___
Python tracker
<http://bugs.python.
Aleksandr Koshkin added the comment:
Note, that
>>> ord('µ')
181
there is another Mu like symbol chr(956), on which this code passes
--
___
Python tracker
<http://bugs
New submission from Aleksandr Koshkin:
For some reason
>>> 'µ'.upper().lower() == 'µ'
False
--
components: Unicode
messages: 271174
nosy: ezio.melotti, haypo, magniff
priority: normal
severity: normal
status: open
title: Something wrong with str.upper().
Changes by Aleksandr Koshkin :
--
status: open -> closed
___
Python tracker
<http://bugs.python.org/issue27601>
___
___
Python-bugs-list mailing list
Unsubscrib
Aleksandr Koshkin added the comment:
Thanks)
--
resolution: -> fixed
versions: +Python 3.2, Python 3.3, Python 3.4, Python 3.5
___
Python tracker
<http://bugs.python.org/issu
Aleksandr Koshkin added the comment:
Moreover this example contains following code
if hash_ == -1:
hash_ == -2
return hash_
that doesn`t make too much sense.
--
___
Python tracker
<http://bugs.python.org/issue27
New submission from Aleksandr Koshkin:
https://docs.python.org/3.6/library/stdtypes.html#hashing-of-numeric-types
Look at semantics example for hash_complex function. The variable 'hash' is
clearly misused - it is not defined or refers to builtin function 'hash'.
Eithe
