3 ms·

I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it w

by js2 9y ago

I have no idea. The patch is less than a dozen lines. It sat from June 2011 to March 2014 with no action. There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible), but that doesn't explain why it didn't go into 3.3. Some minor feedback (that didn't seem to be a blocker in the first place) was addressed in March 2014 and there it's sat. A new patch then came in in April 2016 which has been completely ignored. I guess my answer is: "there seems to be a lot of friction getting a patch into Python and without a strong advocate, patches sometimes die." I will note that the issue has been classified as an enhancement, not a bug, so maybe that has something to do with it. It still seems like a huge waste of time though.

dozzie 9y ago
> There was a claim it couldn't go into 2.7 because it was an API change (even though it was backwards compatible) But it was not backwards compatible. "It works in 2.7" does not mean it works in 2.7.8, but if you try using 2.7.7 it falls apart.
- js2 9y ago
  Backwards compatible means the patch adds new functionality without breaking the API for existing programs. Of course the new functionality would only work in whichever release it was first shipped. Maybe you’re objecting to it being introduced in a 2.7.x patch release, but that's not without precedent for Python. For example, https://bugs.python.org/issue22960 https://bugs.python.org/issue22960 added a new optional argument to xmlrpclib.ServerProxy and was introduced in 2.7.9.