Re: [Python-Dev] PEP 3003 - Python Language Moratorium
On 01:50 pm, dripton@ripton.net wrote:
On 2009.11.06 08:25:29 +0100, Hagen F�rstenau wrote:
A switch to enable deprecation warnings would give developers a chance to see them when migrating to a new version of python. And it would prevent users from having to deal with them.
PendingDeprecationWarning is silent by default and requires a switch to be enabled.
So what we need is perhaps not a stdlib moratorium, but rather strict adherence to a sequence of PendingDeprecationWarning -> DeprecationWarning -> Removal? (The first one seems to have been underused so far.)
+1
I really don't like the loud warnings for sha and md5 in 2.6, considering that hashlib wasn't even added until 2.5. It should be possible to write code that works across all the versions of Python 2 that are currently shipping with mainstream Linux distrobutions without deprecation warnings or conditional version-dependent code.
To go a step further, maybe follow javac's example and emit just one summary deprecation warning per program by default. Something like "this program uses deprecated API calls. Run it with python -deprecation to see the details."
End users don't even need to be told this much, though (and if it's javac that does this for Java, then indeed Java end users probably aren't seeing this either). I think it would be great for deprecation warnings to be completely silent for a while *and* for the policy to be prominently documented so that developers, the people who really need this information, know how to get it. Jean-Paul
On Nov 6, 2009, at 9:04 AM, exarkun@twistedmatrix.com wrote:
End users don't even need to be told this much, though (and if it's javac that does this for Java, then indeed Java end users probably aren't seeing this either). I think it would be great for deprecation warnings to be completely silent for a while *and* for the policy to be prominently documented so that developers, the people who really need this information, know how to get it.
Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better would be for every project on PyPI to have a score which listed warnings emitted with each version of Python. People love optimizing for stuff like that and comparing it. I suspect that even if all warnings were completely silent by default, developers would suddenly become keenly interested in fixing them if there were a metric like that publicly posted somewhere :).
On Fri, 6 Nov 2009 at 15:48, Glyph Lefkowitz wrote:
On Nov 6, 2009, at 9:04 AM, exarkun@twistedmatrix.com wrote:
End users don't even need to be told this much, though (and if it's javac that does this for Java, then indeed Java end users probably aren't seeing this either). I think it would be great for deprecation warnings to be completely silent for a while *and* for the policy to be prominently documented so that developers, the people who really need this information, know how to get it.
Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better would be for every project on PyPI to have a score which listed warnings emitted with each version of Python. People love optimizing for stuff like that and comparing it.
I suspect that even if all warnings were completely silent by default, developers would suddenly become keenly interested in fixing them if there were a metric like that publicly posted somewhere :).
+1, but somebody needs to write the code... --David (RDM)
On 09:48 pm, rdmurray@bitdance.com wrote:
On Fri, 6 Nov 2009 at 15:48, Glyph Lefkowitz wrote:
On Nov 6, 2009, at 9:04 AM, exarkun@twistedmatrix.com wrote:
End users don't even need to be told this much, though (and if it's javac that does this for Java, then indeed Java end users probably aren't seeing this either). I think it would be great for deprecation warnings to be completely silent for a while *and* for the policy to be prominently documented so that developers, the people who really need this information, know how to get it.
Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better would be for every project on PyPI to have a score which listed warnings emitted with each version of Python. People love optimizing for stuff like that and comparing it.
I suspect that even if all warnings were completely silent by default, developers would suddenly become keenly interested in fixing them if there were a metric like that publicly posted somewhere :).
+1, but somebody needs to write the code...
How would you collect this information? Would you run the test suite for each project? This would reward projects with small or absent test suites. ;) Jean-Paul
~b <ea2499da0911051453n3569387aj581ad4acf5b799c8@mail.gmail.com> <4222a8490911051521r1b9c8165id6e0f12d62da0613@mail.gmail.com> <ca471dc20911051526u7f3642ecg19e4eb73bcca1d3a@mail.gmail.com> <bbaeab100911051535g68cefa18kdadea33f78de9495@mail.gmail.com> <48c184130911051555r9a5b78cs3a13cb1345d3cbf7@mail.gmail.com> <20091106001430.3229.796306500.divmod.xquotient.180@localhost.localdomain> <4AF3CF69.6090709@gmx.net> <20091106135058.GA13578@vidar.dreamhost.com> <20091106140412.3229.80002680.divmod.xquotient.193@localhost.localdomain> <68272E43-D993-4833-8DC9-DB45CB40F368@twistedmatrix.com> <Pine.LNX.4.64.0911061647160.12274@kimball.webabinitio.net> <20091106215210.3229.1142452245.divmod.xquotient.212@localhost.localdomain> X-Mailer: VM 8.0.12-devo-585 under 21.5 (beta29) "garbanzo" d20e0a45a4b2 XEmacs Lucid (x86_64-unknown-linux) Date: Sat, 07 Nov 2009 17:35:21 +0900 Message-ID: <87aayyspfa.fsf@uwakimon.sk.tsukuba.ac.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii exarkun@twistedmatrix.com writes:
How would you collect this information? Would you run the test suite for each project? This would reward projects with small or absent test suites. ;)
Multiply by the number of lines of code and divide by the number of tests run.
On Nov 6, 2009, at 4:52 PM, exarkun@twistedmatrix.com wrote:
On 09:48 pm, rdmurray@bitdance.com wrote:
On Fri, 6 Nov 2009 at 15:48, Glyph Lefkowitz wrote:
Documentation would be great, but then you have to get people to read the documentation and that's kind of tricky. Better would be for every project on PyPI to have a score which listed warnings emitted with each version of Python. People love optimizing for stuff like that and comparing it.
I suspect that even if all warnings were completely silent by default, developers would suddenly become keenly interested in fixing them if there were a metric like that publicly posted somewhere :).
+1, but somebody needs to write the code...
How would you collect this information? Would you run the test suite for each project? This would reward projects with small or absent test suites. ;)
*I* would not collect this information, as I am far enough behind on other projects ;-) but I if I were to advise someone *else* as to how to do it, I'd probably add a feature to the 'warnings' module where users could opt-in (sort of like popcon.debian.org) to report warnings encountered during normal invocations of any of their Python programs. I would also advise such a hypothetical data-gathering project to start with a buildbot doing coverage runs; any warning during the test suite would be 1 demerit, any warning during an actual end-user run of the application *not* caught by the test suite would be 1000 demerits :). And actually it would make more sense if this were part of an overall quality metric, like http://pycheesecake.org/ proposes (although I think that cheesecake's current metric is not really that great, the idea is wonderful).
participants (4)
-
exarkun＠twistedmatrix.com -
Glyph Lefkowitz -
R. David Murray -
Stephen J. Turnbull