They were breaking many things, maybe they should have rewritten the C API? From what I remember that's the blocker.
That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
That would have broken all C extensions, but it's not like Python 3 at launch was a raving success regarding library porting.
Fine grained locking works, but is expensive for non-multithreaded applications and slows down Python. It would speed up multithreaded applications though.
And they continued to break them within the py3k lifetime, mostly unicode related stuff from what I can remember. Probably still break stuff but I haven't had time for my toy python projects in a while so haven't been messing with the C-API lately.
I wished they had broken everything harder and once and for all, in order to fix the issue.
If there's going to be breakage anyway, people adjust their expectations. The scale is basically:
a lot of breakage > a bit of breakage >>>>>> no breakage.
Once you do break backwards compatibility, you might as well do it in a big way, provided you:
* don't offer vaporware for a decade (hello Perl 6!)
* try to offer some mitigations for the migration pain (auto-conversions, support libraries, top-notch docs, etc.)
* offer a great carrot at the end of the tunnel (good performance would be such a carrot)