Barry Warsaw wrote:
On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote:
Martin, +1 on everything you wrote, with one minor quibble.
Removal
===
If the module has been deprecated for atleast a year and atleast
a version, it can be removed. Removal should move it to old-libs
for pure Python mo
On Tuesday 07 December 2004 04:46 am, Nick Coghlan wrote:
> One other question occurred to me for "deprecate X in favour of Y"
> situations - should the deprecation warning added to X point developers
> towards Y?
Not sure about the warning, but the documentation certainly should. When the
ma
On Tue, 2004-12-07 at 03:12, Raymond Hettinger wrote:
> I'm concerned about the old email modules. They haven't been deprecated
> and may stay around for a good while. However, some SF requests have
> been passed over on the basis that the modules are supplanted and will
> be phased out. I don'
One other question occurred to me for "deprecate X in favour of Y" situations -
should the deprecation warning added to X point developers towards Y?
Also, should the PEP include example wordings for deprecation warnings, rather
than being completely freeform? Martin listed some information that
> > Instead, there should be a clear decision to deprecate or not. If
that
> > entails a comp.lang.python.announce notice and comment period, so be
it.
> > Once a decision is made, document it, add a warning, and wait.
>
> Ok, that might be reasonable.
Please word the PEP accordingly.
> > Once
Raymond Hettinger wrote:
Instead, there should be a clear decision to deprecate or not. If that
entails a comp.lang.python.announce notice and comment period, so be it.
Once a decision is made, document it, add a warning, and wait.
Ok, that might be reasonable.
Once a couple versions pass, some us
There is one other issue that should get addressed, modules in limbo.
I'm concerned about the old email modules. They haven't been deprecated
and may stay around for a good while. However, some SF requests have
been passed over on the basis that the modules are supplanted and will
be phased out.
> I'm happy to adjust details of the procedures - but it seems we
disagree
> on the principles.
Not really. I have no objection to making module deprecation/removal
rare or even not doing it at all. Personally, I've never asked for a
module deprecation and don't expect to.
I also agree that m
Raymond Hettinger wrote:
One other thought: In deciding how long to leave module in, we should
consider that Python books are updated infrequently, if at all. It
would be a bummer if code in them stopped working as advertised.
Correct. Thanks for reminding me - that is indeed a reasoning that
is
Raymond Hettinger wrote:
The effect of coding this into the PEP is to make deprecation
unnecessarily involved.
Can you please explain why you consider this involvement
unnecessary? I think it is important that we do not prematurely
remove (or even deprecate) modules that are still being actively
On Tuesday 07 December 2004 11:43, Raymond Hettinger wrote:
> > Modules that have currently deprecation messages in them often
> > fail to identify the Python version in which removal will occur.
> > For modules that have been deprecated since 2.1, I would suggest
> > to remove them for 2.5, with t
One other thought: In deciding how long to leave module in, we should
consider that Python books are updated infrequently, if at all. It
would be a bummer if code in them stopped working as advertised.
Raymond
___
Python-Dev mailing list
[EMAIL PRO
> I would do what Barry suggests: rephrase the module to document the
> deprecation/removal procedure. This, of course, needs
> consensus/pronouncement, too, but I think I would put the following
> aspects into it:
>
> Requirements
>
> Removal of module needs proper advance warning fo
On Mon, 2004-12-06 at 16:28, "Martin v. Löwis" wrote:
Martin, +1 on everything you wrote, with one minor quibble.
> Removal
> ===
> If the module has been deprecated for atleast a year and atleast
> a version, it can be removed. Removal should move it to old-libs
> for pure Python modules; a
Brett C. wrote:
And as for the mention of dropping PEP 4, I agree with the running
consensus that it isn't needed thanks to the warning module. Do we need
to have a more formal vote to drop PEP 4, or should one the PEP
maintainers just delete it?
I would do what Barry suggests: rephrase the mod
15 matches
Mail list logo
