Message329438
Thanks for the long post! Clearly there is more here than the eye can easily see.
Nevertheless, I feel that, *in this case*, it's not likely that such a re-implementation will ever happen, so I think it is okay to constrain the future so we can guarantee (the ordering aspect of) the current behavior. The current behavior also *feels* natural, regardless of the validity of the OP's use case.
The edge case of assignment to __bases__ is a good one to call out (in the docs and in the test) but I don't think the current behavior there is sufficiently dicey to change it or to exclude it from the guarantee. |
|
Date |
User |
Action |
Args |
2018-11-07 21:25:23 | gvanrossum | set | recipients:
+ gvanrossum, pekka.klarck, josh.r, pablogsal, xtreak, BNMetrics |
2018-11-07 21:25:23 | gvanrossum | set | messageid: <1541625923.92.0.788709270274.issue34805@psf.upfronthosting.co.za> |
2018-11-07 21:25:23 | gvanrossum | link | issue34805 messages |
2018-11-07 21:25:23 | gvanrossum | create | |
|