[Python-Dev] Rewriting PEP4

["Martin v. Löwis"]

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
used.

 > Also, the list of reasons is insufficiently
> comprehensive.  In the past we've gotten along fine with discussing a
> situation on python-dev and either reaching a consensus or having Guido
> give an okay.  

I don't think we "got along", but rather "got away". Discussion on
python-dev does not cause sufficient user involvement, IMO. And indeed,
some people (even on python-dev) think that we *never* should deprecate
any modules, as it breaks existing code. They might not be as vocal as
supporters of early removal of "ugly" code, but I think their opinion
is just as valuable.

> We should only talk in terms of versions.  Dates are irrelevant and
> confusing.

Why is a date confusing? I think everybody on Earth understands the
notion of a date, there is nothing confusing in this notion.

Why are they irrelevant? If we release Python 2.5 next month (and
stop developing 2.4), are we entitled to remove all features that
were scheduled for removal? I think not: users would have not gotten
sufficient advance warning. Users need *time* to react on proposed
feature changes.

 > In the last version of the PEP, it was far from clear the
> significane of deprecating or removing on date xx-xx-xx.  All that
> matters is the version the warning first appears and the version where
> the module is removed.  

No. It also matters how much time users have had to react.

> I do not think the version number messages are useful.  When someone
> imports a file and gets a warning, they know a deprecation is pending
> and to stop writing code with that module.

Yes, but what about code that currently uses the module? People will
not start rewriting (perhaps they aren't the authors in the first
place) just because they see a deprecation warning. Instead, they will
silence the warning, and go on. If we plan to remove the feature at
some point, we need to give these users an indication that they need
to act beyond silencing the warning. Such actions could be
- have the author of the software update it appropriately
- look for a replacement software
- ask for an extension of the grace period on python-dev

Currently, users do not really have these options, since they do not
have an indication that action on their side is really needed if they
want their software continue to work with future Python versions.

> Further, I want to avoid the
> previous PEP 4 situation where one nit or another wasn't followed to the
> letter so we had to keep the module around for another two versions.

Why do you want to avoid that situation? What is the problem with
waiting for two more versions? No harm is done in doing so.

 > It
> can and should be as simple as having us agree to deprecation, inserting
> a warning, and then removing it two versions later.

I strongly disagree with that position.

> I had thought the purpose of rewording the PEP was just to take out
> language naming specific modules and to add language on using the
> warning module.  Instead, it looks like an attempt to make it much more
> difficult and slow to deprecate a module.  

I want the PEP to be followed. For that, it needs to be precise, and
the procedures need to be agreed upon (or, if we cannot agree, it
needs to be Pronounced).

> If so, I would like to understand what situation is motivating it.  Is
> there some module that had been deprecated but should not have been?

Deprecation is fine for all the modules so far. Generating the warning
is a bit of a problem, removal would be a serious problem, for the
following modules:
- regex
- xmllib
- whrandom
since I expect that these modules are still widely used, in existing
code, by users who are not the authors of that code. This is a problem,
since these users cannot do anything about the usage of the deprecated
code. They just find that the software that ran happily with the
previous Python version first shouts at them in the next Python version,
then totally breaks with the subsequent version. They will hate Python
for that.

> Why the change in procedure?

I think we agree that the previously-documented procedure needs to
be changed - it was not followed.

> It doesn't affect me personally (I haven't proposed any modules for
> deprecation and do not have any in mind); however, I think the
> discussion should take place in the broader context of what we intend to
> do with the standard library -- do we want regex still there in 2010.

As to the latter question: Definitely. We don't want regex to be used
for new code, and we want developers to fully understand that, but we
also do want code that currently works correctly with regex continue
to do so in 2010. The only exception would be that 2010 no code is left
in active use that uses regex, which I doubt.

> Also, as proposed, the PEP lists many forces against deprecation and
> none of the forces for it.

That is not true. Security flaws are giving priority. They can only
be undeprecated if the reason for deprecation goes away, which means
that somebody fixes the security flaw.

> If that is the reality, then we could just
> never deprecate anything because someone, somewhere is bound to be
> irritated by it.  That would certainly simplify the discussion.

Well, we do want to move developers to the new direction. However,
many people use Python code who are *not* developers. We need to
take their concerns into account as well.

> Going back to specifics, it may be worthwhile to think through the
> reason we kept the xmllib code but not whrandom.  Both were documented,
> non-buggy, tested, marked as deprecated for a long time, and it was
> within the realm of possibility that some code still used them.

Indeed. If it is in the realm of possibility that code still uses a
module, and that this would not raise security concerns, the module
should not be removed.

> Also, the PEP should discuss the use of the lib-old directory and it
> should include Barry's link to old documentation.

I'm happy to adjust details of the procedures - but it seems we disagree
on the principles.

Regards,
Martin