You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Type issue leading to NotOTRMessage exception when it should have been UnencryptedError on python 3 #47
In context.py, the basestring type is an alias to str; however, everything in and out of the library is bytes (otherwise it does not work), so when receiving a plaintext message during an encrypted session it never enters the test for unencryptedmessage and raises a nototrmessage (which does not provoke a warning because it is supposed to be raised only outside an OTR session).
Specifically, at the end of receiveMessage, message is a bytes object and basestring is “str”.
when we are not testing for basestring intance, but really bytes?
Maybe it would be better to have a better named variable in there instead? Something along the lines of:
try:
type(basestring)
rawMessageFormat = basestring
except NameError:
# all strings are unicode in python3k
rawMessageFormat = bytes
unicode = str
and then using:
if isinstance(message, rawMessageFormat):
?
My concern is how having it changed to bytes accross the lib could affect other parts of the logic, and whether unicode should be left alone or could raise similar issues elsewhere? (I don't think so but we should doublecheck)
2.7 should probably still be supported for a while, but I don't think older versions are used by reasonable people any more (except in old centos releases maybe).
With the release of gajim 1.0.0 last month, they finally moved to python3.
As the official wiki says, python2.x is legacy. And only 2.7 is maintained, older 2.x releases are not, as I wrote before.
Activity
Workaround for an otr lib bug (plaintext messages without warning)
koolfy commentedon Oct 25, 2015
Wouldn't it be confusing to leave
when we are not testing for basestring intance, but really bytes?
Maybe it would be better to have a better named variable in there instead? Something along the lines of:
and then using:
?
My concern is how having it changed to bytes accross the lib could affect other parts of the logic, and whether unicode should be left alone or could raise similar issues elsewhere? (I don't think so but we should doublecheck)
mathieui commentedon Dec 27, 2015
If we’re testing for bytes, wouldn’t it be better to only do
(or does that break python versions older than 2.7 that you want to support?)
koolfy commentedon Jul 20, 2016
I don't think supporting python 2.7 and older is reasonable at this point.
Thoughts?
tribut commentedon Jul 20, 2016
2.7 should probably still be supported for a while, but I don't think older versions are used by reasonable people any more (except in old centos releases maybe).
azrdev commentedon Jul 20, 2016
@koolfy older is EOL afaik, but since gajim itself is on python2.7 you cannot move to python3 atm
koolfy commentedon Jul 20, 2016
good point.
mathieui commentedon Jul 20, 2016
@azrdev the gajim hg default branch is python3, but it’s not yet usable iirc
koolfy commentedon Apr 2, 2018
I reinstalled a rasperry pi as an IRC client and discovered raspbian-stretch still ships python2.7 by default :)
So I guess this settles the debate, python2.7 is still very much alive, this should be fixed for 1.0.3
azrdev commentedon Apr 2, 2018
With the release of gajim 1.0.0 last month, they finally moved to python3.
As the official wiki says, python2.x is legacy. And only 2.7 is maintained, older 2.x releases are not, as I wrote before.