Maybe I am missing something really simple here, but....
I had for a while a server running MySQLdb version 1.2.0. My application is dealing exclusively with Unicode strings; however, when passing strings to 'execute' method I was always converting strings to 8-bit by invoking '.encode' method, as I don't think there was any was to do otherwise in this version. I have a lot of code that does just that.
Now I had to re-use this code under another server running MySQLdb 1.2.1. As it is evident from looking at method execute(), this method is now unconditionally calling .encode() method itself:
Maybe I am missing something really simple here, but....
I had for a while a server running MySQLdb version 1.2.0. My application is dealing exclusively with Unicode strings; however, when passing strings to 'execute' method I was always converting strings to 8-bit by invoking '.encode' method, as I don't think there was any was to do otherwise in this version. I have a lot of code that does just that.
Now I had to re-use this code under another server running MySQLdb 1.2.1. As it is evident from looking at method execute(), this method is now unconditionally calling .encode() method itself:
thus expecting either ascii strings or true unicode strings on input, and not 8-bit strings as before. Obviously, this breaks all of my existing code.
While I understand the reasons behind this change and welcome it, why do so unconditionally and break backward compatibility for existing code?