On Mar 16, 2015, at 1:04 PM, Daniel Holth
wrote: The problem with a no-stopgaps policy is that the non-stopgap solution has to be incredible to ever be greater than the accrued debt of ((current pain - reduced pain from stopgap) * all python users * years until non-stopgap) - (maintenance/documentation hassle * years since stopgap implemented * everyone who has to deal with it), and we do not know how great the non-stopgap will be.
There is not a "no stopgaps" policy. There is a "stopgaps must be carefully considered" policy. Stopgaps which don't rely on end users needing to do anything in particular to use them and which pay attention to backwards and forward compatability are better than stopgaps that introduce new APIs/user facing features. --- Donald Stufft PGP: 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA