Lucas Beyer warns the approach could trigger a Python 3-style split.
One of the reasons some footguns in PyTorch persist is because it would be BC-breaking to change the defaults. I'm kind of wondering if something like language editions (similar to C++20) could help us batch defaults updates and make them more accessible.
No Digg Deeper questions have been answered for this story yet.
PyTorch NFE
officially "next frontier edition" but unofficially "no footgun edition"
But i think it would mean maintaining two parallel libraries, a bit much? Though if you don't, then it's just major version number, right? Which would be a bit awkward if there's "PyTorch 4 - no big new feature, but all code would be subtly broken" though it cadence picks up and there's v5 half year later, then v6 etc , people wouldn't mind anymore But it also risks going the py3k way of reluctant switching forever.
Tricky.
One of the reasons some footguns in PyTorch persist is because it would be BC-breaking to change the defaults. I'm kind of wondering if something like language editions (similar to C++20) could help us batch defaults updates and make them more accessible.
@giffmana I don't want parallel libraries. The most conservative version of this proposal only lets NFE change global config toggles: expandable segments, various compiler configs, etc. I definitely don't want a py3k situation
PyTorch NFE
officially "next frontier edition" but unofficially "no footgun edition"
But i think it would mean maintaining two parallel libraries, a bit much? Though if you don't, then it's just major version number, right? Which would be a bit awkward if there's "PyTorch 4 - no big new feature, but all code would be subtly broken" though it cadence picks up and there's v5 half year later, then v6 etc , people wouldn't mind anymore But it also risks going the py3k way of reluctant switching forever.
Tricky.