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

Reply via email to