[Python-Dev] Deprecating the formatter module (original) (raw)
MRAB python at mrabarnett.plus.com
Wed Aug 14 18:23:32 CEST 2013
- Previous message: [Python-Dev] Deprecating the formatter module
- Next message: [Python-Dev] Deprecating the formatter module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On 14/08/2013 17:17, Eli Bendersky wrote:
On Wed, Aug 14, 2013 at 9:09 AM, Nick Coghlan <ncoghlan at gmail.com_ _<mailto:ncoghlan at gmail.com>> wrote: On 14 August 2013 11:55, Brett Cannon <brett at python.org_ _<mailto:brett at python.org>> wrote: > On Wed, Aug 14, 2013 at 11:47 AM, Nick Coghlan <ncoghlan at gmail.com <mailto:ncoghlan at gmail.com>> wrote: >> >> On 14 August 2013 11:08, Brett Cannon <brett at python.org_ _<mailto:brett at python.org>> wrote: >> > We take adding a module to the stdlib very seriously for all of these >> > reasons and yet people seem to forget that the exact same reasons apply >> > to >> > modules already in the stdlib, whether they would be added today or not >> > (and >> > in this instance I would argue not). There is a balance to keeping the >> > load >> > of work for core devs at a level that is tenable to the level of quality >> > we >> > expect from ourselves which means making sure we don't let cruft build >> > up in >> > the stdlib and overwhelm us. >> >> I've already suggested a solution to that at the language summit [1]: >> we create a "Legacy Modules" section in the docs index and dump all >> the modules that are in the "These are only in the standard library >> because they were added before PyPI existed, aren't really actively >> maintained, but we can't remove them due to backwards compatibility >> concerns" category there. >> >> Clear indication of their status for authors, educators, future users >> and us, with no risk of breaking currently working code. > > > I view a deprecation as the same thing. If we leave the module in until > Python 4 then I can live with that, but simply moving documentation around > is not enough to communicate to those who didn't read the release notes to > know modules they rely on are now essentially orphaned. No, a deprecation isn't enough, because it doesn't help authors and educators to know "this is legacy, you can skip it". We need both. +1 for both and for leaving the module in until "Python 4". Nick, perhaps we can have this "legacy-zation" process for modules documented somewhere? Devguide? mini-PEP? What about also for certain features of modules, such as re's LOCALE flag?
- Previous message: [Python-Dev] Deprecating the formatter module
- Next message: [Python-Dev] Deprecating the formatter module
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]