From my POV, this would be required in some form or another before such a scheme could actually work. Without it we end up with an improved win32text (good!)
I still think this would be actually bad.
Instead, a new extension should be written, with a name that does not have "win32" as a substring, and that has no provision for guessing line breaks by inspecting files.
To be clear, you are suggesting:
- Having hg enforce an extension as required is good.
I have no opinion on that.
- Python adopting win32text as that extension would be bad - instead
another extension with different semantics (ie, no guessing based on file content) should be used, and enforced, instead.
Yes. The functionality being discussed should not be added to win32text.
Assuming I am correct, I am inclined to agree - win32text may be "good enough" in the short term, but it is far from ideal.
I also feel that an extension that is inherently platform independent and has a clear specification has much higher chances of becoming a standard feature of Mercurial one day.