This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients JelleZijlstra, eric.smith, methane, ncoghlan, pitrou, rhettinger, serhiy.storchaka, xiang.zhang
Date 2017-07-17.12:14:45
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1500293685.4.0.73878591327.issue28638@psf.upfronthosting.co.za>
In-reply-to
Content
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).
History
Date User Action Args
2017-07-17 12:14:45ncoghlansetrecipients: + ncoghlan, rhettinger, pitrou, eric.smith, methane, serhiy.storchaka, xiang.zhang, JelleZijlstra
2017-07-17 12:14:45ncoghlansetmessageid: <1500293685.4.0.73878591327.issue28638@psf.upfronthosting.co.za>
2017-07-17 12:14:45ncoghlanlinkissue28638 messages
2017-07-17 12:14:45ncoghlancreate