Sjoerd Mullender wrote:

On 2010-02-19 14:10, Guido van Rossum wrote:

...

Isn't mhlib itself deprecated? (It's gone in Py3k.)

I wouldn't like that, but it is beside my point. If a module is deprecated, then it should not be used in released code. If mhlib is deprecated, it doesn't tell you about it. mhlib uses multifile and multifile does tell you it is deprecated, and that is pretty annoying.

This is because no one has gotten around to it. Create a bug report for it, and preferably attach a patch with tests. Eric.

On 2010-02-19 14:45, Eric Smith wrote:

Sjoerd Mullender wrote:

...

On 2010-02-19 14:10, Guido van Rossum wrote:

...

Isn't mhlib itself deprecated? (It's gone in Py3k.)

I wouldn't like that, but it is beside my point. If a module is deprecated, then it should not be used in released code. If mhlib is deprecated, it doesn't tell you about it. mhlib uses multifile and multifile does tell you it is deprecated, and that is pretty annoying.

This is because no one has gotten around to it. Create a bug report for it, and preferably attach a patch with tests.

My point is, as a matter of *policy*, nothing should be released that uses deprecated stuff. I can't create a bug report about wrong (or incomplete) policies.

Eric.

_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/sjoerd.mullender%40cwi.nl

-- Sjoerd Mullender

On 2010-02-19 16:23, Nick Coghlan wrote:

Sjoerd Mullender wrote:

...

My point is, as a matter of *policy*, nothing should be released that uses deprecated stuff. I can't create a bug report about wrong (or incomplete) policies.

The policy is more that the test suite shouldn't raise Deprecation Warnings unless it is explicitly checking for them (or otherwise testing known-deprecated code).

The policy should also be, if someone decides (or rather, implements) a deprecation of a module, they should do a grep to see where that module is used and fix the code. It's not rocket science.

If there is a hole in the test suite coverage such that paths that trigger deprecated code are not exercised by the regression tests, then that is a bug.

Cheers, Nick.

-- Sjoerd Mullender

On Fri, Feb 19, 2010 at 5:41 PM, Mike Klaas wrote:

On Fri, Feb 19, 2010 at 9:03 AM, Sjoerd Mullender wrote:

...

The policy should also be, if someone decides (or rather, implements) a deprecation of a module, they should do a grep to see where that module is used and fix the code.  It's not rocket science.

I'm not sure if you're aware of it, but you're starting to sound a little rude.

He's just being Dutch. :-)

ISTM that it doesn't make sense to waste effort ensuring that deprecated code is updated to not call other deprecated modules.  Of course, all released non-deprecated code should steer clear of deprecated apis.

Read again. Sjoerd meant it exactly the other way around. When a module is deprecated it is *not* a wasted effort to ensure that no other (undeprecated) modules depend on it! -- --Guido van Rossum (python.org/~guido)

On Fri, Feb 19, 2010 at 08:40, Sjoerd Mullender wrote:

On 2010-02-19 14:10, Guido van Rossum wrote:

...

Isn't mhlib itself deprecated? (It's gone in Py3k.)

I wouldn't like that, but it is beside my point. If a module is deprecated, then it should not be used in released code. If mhlib is deprecated, it doesn't tell you about it. mhlib uses multifile and multifile does tell you it is deprecated, and that is pretty annoying.

I see the deprecation warning upon importing mhlib in 2.6 and trunk (with -Wd).