Making pretty-yaml work on python 2.6 about pretty-yaml HOT 1 CLOSED

Unfortunately, one-liner reason is "I don't want to maintain or change 2.6-compatible code (esp. alongside 3.x), it's not super-hard but hard and pointless".
Longer explaination follows.

Biggest problem would be the fact that I don't have 2.6 anywhere (for years by now) and don't ever try to run this code on it, so stuff is likely to break on every other change.
I've tried this "exercise self-discipline" approach in the past, it didn't work even few years ago, when memories of 2.6-2.7 diffs were still there.
Maybe having more tests and some travis setup would help a lot here.

Then there's an issue of new stuff - iirc OrderedDict wasn't in 2.6 stdlib (needs +1 dependency, one more set of compatibility hacks in code), and same for many fairly minor features that are nice to use (and that I got used to) from 2.7 (especially 3.x compat stuff) - I just don't want to code in 2.6.

In my experience, it's trivial to build 2.7 either as a package for super-old systems (probably some LTS release of debian or RH-like), or in a separate dir, even from unprivileged user. Given stability promise of such stale systems, it's also simple to do it in any of container away from production.
So I also have serious doubts whether supporting 2.6 is even sane at this point, and larger python projects like Django already dropped that, for instance.

Best way to maintain such compatibility that I can think of is for someone interested in 2.6 to keep a stack of 2.7->2.6 patches and rebase them on top of any changes here (in a fork or something), testing thoroughly (or checking diffs) at such sync-points.
It will be pretty much the same workflow (conceptually) that I'd have to use too (if I had to) on every single change, due to first two reasons above.

from pretty-yaml.