Nick Coghlan added the comment: Folks, you're talking about removing a *public*, *documented* API from the standard library. The onus would thus be on you to prove *lack* of use, *and* provide adequate justification for the compatibility break, not on anyone else to prove that it's "sufficiently popular" to qualify for the standard backwards compatibility guarantees. Those guarantees apply by default and are only broken for compelling reasons - that's why we call them guarantees
Don't be fooled by the leading underscore - that's an artifact of how namedtuple avoids colliding with arbitrary field names, not an indicator that this is a private API: https://docs.python.org/3/library/collections.html#collections.somenamedtuple._source "It would be faster" isn't adequate justification, since speed increases only matter in code that has been identified as a bottleneck, and startup time in general (let alone namedtuple definitions in particular) is rarely the bottleneck. So please, just stop, and find a more productive way of expending your energy (such as by making PyStructSequence available via the "types" module, since that also allows for C level micro-optimizations when *used*, not just at definition time). ---------- resolution: -> rejected stage: -> resolved status: open -> closed _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
