Uhhhh... sort of? I mean, I could go through all of the needless "why the hell did they make this partner incompatible also" stuff like, like removing u'' support (thai was added later), or all of the ludicrous breakage in the underlying APIs (like filesystem calls that made assumptions about character encoding that make no sense for the underlying Unix model and literally caused files to just disappear from iteration)... a lot of this stuff was fixed in later versions of Python 3, but that was
years later, making it nearly impossible to deal with the existing land mines of people who had installed Python 3.0-3 (or even 3.4).
But what makes me shocked that you think that that is the case is basic basic stuff... I mean, as one obvious example, they changed the exception syntax. So, "uhhhh.... sure?" it was possible to make a program that ran on both 2 and 3, but it required using "try" with no variable assignment and then digging into Python's exception reflection support to recover the variable. And you had to do this every single time. (And of course a lot of the time the underlying core library would now throw different exceptions, making the situation all the more ludicrous.)
I had code that straddles the 1.8/1.9 boundary of Ruby, and even though I wasn't an expert at Ruby it was trivial to have code that worked for both (and I mean 100% correct: Unicode and everything; remember that neither Ruby 1.9 nor Python 3 added Unicode support, they only made Unicode support easier to obtain. for Python 2 there was already comprehensive, if non-default, support, and for Ruby 1.8 you just needed to be careful about where you did conversions).