Re: [Python-Dev] Deprecated xmllib module

[Nick Coghlan]

Martin v. Löwis wrote:
Anthony Baxter wrote:
The library docs for, e.g. xmllib already say deprecated at the top - 
maybe
it should be larger?

I think it would be better to *remove* the xmllib documentation.
Existing code which needs the module will continue to work even
without documentation, and new code is unlikely to be written for
a module that has no documentation, and where importing the module
gives a DeprecationWarning.
If we went down this path, I would suggest we include a list of deprecated 
modules in the docs to forestall "where is the documentation for these modules?" 
questions. Such a list would also make life easier for anyone stuck with 
maintaining legacy Python code.

E.g.
X.X Deprecated modules
  The following modules exist in the standard library solely for backwards 
compatibility with older versions of Python. They are no longer supported, and 
should not be used for new code. Anyone maintaining code using these modules 
should refer to the documentation for the Python version listed in the table below.

  Module Name  | Last documented in:
  -
   lib1|  Python 2.2
   lib2|  Python 2.3
etc. . .
I'd also suggest including a link to this list at the bottom of the global 
module index.

Alternately, we could lock the folks complaining about the stdlib's state
in a room with the folks who complain that every new thing has "wrecked
the language that they knew and loved" and let them fight it out.
That sounds like a fair and democratic way of solving the issue.
If we sold tickets, it could even be a nice little earner for the PSF ;)
Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Michael Hudson]

"Martin v. Löwis" <[EMAIL PROTECTED]> writes:

> Anthony Baxter wrote:
>> The library docs for, e.g. xmllib already say deprecated at the top - maybe
>> it should be larger?
>
> I think it would be better to *remove* the xmllib documentation.
> Existing code which needs the module will continue to work even
> without documentation, and new code is unlikely to be written for
> a module that has no documentation, and where importing the module
> gives a DeprecationWarning.

+1, at least for *hiding* the documentation of xmllib + similar
modules.  I'm not sure wholesale removal is really a good idea.

It's like the new "Non-essential Built-in Functions" section of the
lib ref.

Cheers,
mwh

-- 
   jemfinch: What's to parse?  A numeric code, perhaps a
  chicken, and some arguments
-- from Twisted.Quotes
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Carlos Ribeiro]

On Mon, 06 Dec 2004 12:12:48 +, Michael Hudson <[EMAIL PROTECTED]> wrote:
> "Martin v. Löwis" <[EMAIL PROTECTED]> writes:
> 
> > Anthony Baxter wrote:
> >> The library docs for, e.g. xmllib already say deprecated at the top - maybe
> >> it should be larger?
> >
> > I think it would be better to *remove* the xmllib documentation.
> > Existing code which needs the module will continue to work even
> > without documentation, and new code is unlikely to be written for
> > a module that has no documentation, and where importing the module
> > gives a DeprecationWarning.
> 
> +1, at least for *hiding* the documentation of xmllib + similar
> modules.  I'm not sure wholesale removal is really a good idea.

1) Move the deprecated documentation into a separate book. 

2) Don't include the "Deprecated Modules Reference" in the standard
distribution, but make it available as a separate download.


-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: [EMAIL PROTECTED]
mail: [EMAIL PROTECTED]
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Nick Coghlan]

Carlos Ribeiro wrote:
On Mon, 06 Dec 2004 12:12:48 +, Michael Hudson <[EMAIL PROTECTED]> wrote:
+1, at least for *hiding* the documentation of xmllib + similar
modules.  I'm not sure wholesale removal is really a good idea.

1) Move the deprecated documentation into a separate book. 

2) Don't include the "Deprecated Modules Reference" in the standard
distribution, but make it available as a separate download.
What about the idea of pointing to the last version of the docs that contained 
the relevant documentation?

Cheers,
Nick.
--
Nick Coghlan   |   [EMAIL PROTECTED]   |   Brisbane, Australia
---
http://boredomandlaziness.skystorm.net
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Deprecated xmllib module

[Raymond Hettinger]

> > > I think it would be better to *remove* the xmllib documentation.
> > > Existing code which needs the module will continue to work even
> > > without documentation, and new code is unlikely to be written for
> > > a module that has no documentation, and where importing the module
> > > gives a DeprecationWarning.
> >
> > +1, at least for *hiding* the documentation of xmllib + similar
> > modules.  I'm not sure wholesale removal is really a good idea.

> 1) Move the deprecated documentation into a separate book.
> 
> 2) Don't include the "Deprecated Modules Reference" in the standard
> distribution, but make it available as a separate download.

-1

We are trying to remove clutter, not keep it in perpetuity.  Leaving the
docs means continuing to have to test it, field bug reports, be aware of
its existence, etc.

Do not keep this on a respirator.  Let it die in peace.



Raymond

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Deprecated xmllib module

[Barry Warsaw]

On Mon, 2004-12-06 at 07:44, Raymond Hettinger wrote:

> We are trying to remove clutter, not keep it in perpetuity.  Leaving the
> docs means continuing to have to test it, field bug reports, be aware of
> its existence, etc.
> 
> Do not keep this on a respirator.  Let it die in peace.

Old documentation lives on in http://www.python.org/doc/versions.html
which seems sufficient for looking up deprecated modules.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment 
variable LDFLAGS but not CPPFLAGS.  Any reason for this? 

How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no mention of 
CPPFLAGS anywhere.  And yet if I modify the definition of CPPFLAGS in 
Makefile.pre.in to ``-I. -I./Include @[EMAIL PROTECTED] it ends up containing the 
value I have for the environment variable at the end of it.  I think the '@@' 
syntax uses a value from configure.in if it is defined else it defaults to the 
value the shell has.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Ptyon 2.3.5 probably coming in January; get your bugs/patches reported!

[Brett C.]

Anthony Baxter, our ever-diligent release manager, mentioned this past week 
that Python 2.3.5 will most likely come to fruition some time in January (this 
is not guaranteed date).  This means that in order to have enough time to 
proper evaluate new patches and bugs they must be reported **now**!  A one 
month lead time is necessary to properly look at, test, and commit patches, let 
alone coming up with solutions to any reported bugs.

Please realize, though, that reporting a bug or submitting a patch now does not 
guarantee that it will committed in time!  The free time of the development 
team is limited.  If you want to help a bug or patch along to make it easier to 
be evaluated and thus raise its chances of being dealt with please see the 
"Helping Out" section of the 'Intro to Development' essay at 
http://www.python.org/dev/dev_intro.html .

As always, both bugs and patches should be reported to Python's SourceForge 
tracker at http://sourceforge.net/bugs/?group_id=5470 and 
http://sourceforge.net/patch/?group_id=5470, respectively.

-Brett Cannon
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rewriting PEP4

["Martin v. Löwis"]

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 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 for users; the
module should be removed only if
- continued usage poses a security threat to the application
  using it, or
- there are no reported usages of the module anymore for quite
  some time
- the module is unmaintained (i.e. there are serious outstanding
  unfixed bugs for it), and there are alternatives which are
  maintained.
There must be a way for users to stop removal of the module,
e.g. by volunteering to maintain an unmaintained module.
Deprecation
===
If a module is candidate for removal, it must be deprecated first.
In order to deprecate the module
1. a warning must be added to the module, indicating the expected
   version when the module is removed, and a reference to the PEP
2. a comment must be added just above the warning, giving a
   the date and version of deprecation, and a
   rationale for removal (e.g.: no known users, is security risk)
3. the module documentation must be removed from the Python
   documentation (alternatively: moved into a "deprecated" section)
Undeprecation
=
A module can be undeprecated if the deprecation reasons turns out
to be invalid, e.g. if users of the module appear when the module
was believed to have no users, or if a maintainer shows up for a
previously unmaintained module. This fact must be recorded in the
module; the original state (documentation, no warning) be restored.
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 removal procedure for pure C modules
has not been defined yet.
If the module was deprecated because it was unmaintained, the module
should only be removed if there have been no recent reports about
usage of the module.
Bug reports against deprecated modules
==
If a bug is reported against a deprecated module, the bug report
can be closed without further consideration, pointing to the
deprecation status. If a patch is submitted against the module,
it should be considered whether the patch could undeprecate
the module; if not, it can be rejected with the same rationale.
If this policy can be agreed, I will replace PEP4 with it.
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 the option of bringing them back
in 2.5.1 if people complain.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

["Martin v. Löwis"]

Brett C. wrote:
I realize that much.  But if you look in configure.in it seems to use 
the previous value of LDFLAGS every time it is redefined as a base and 
thus gets its initial value from the environment variable the first time 
it is tweaked.
Yes, it would be possible to do the same thing for CPPFLAGS. However,
you really need to combine the values. If you assume you don't know
anything about the current value of CPPFLAGS, this might get tricky -
you might cause build failures if you honor CPPFLAGS too much.
Not a big deal, though.  I will just use the environment variables in 
setup.py .
You shouldn't do this - you do need to consider the values in the
Makefile as well. If you think you need both, you should modify
configure.in appropriately.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

["Martin v. Löwis"]

Brett C. wrote:
How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no 
mention of CPPFLAGS anywhere.
Right. That's what I meant when I said "has nothing to compute", so
it does not even mention CPPFLAGS.
And yet if I modify the definition of 
CPPFLAGS in Makefile.pre.in to ``-I. -I./Include @[EMAIL PROTECTED] it ends up 
containing the value I have for the environment variable at the end of 
it.  I think the '@@' syntax uses a value from configure.in if it is 
defined else it defaults to the value the shell has.
Indeed, that seems to be the case. However, absence of @CPPFLAGS@
means that Makefile.pre will just use the static value from
Makefile.pre.in.
Whether or not adding @CPPFLAGS@ to the end is the right thing,
I don't know.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rewriting PEP4

[Barry Warsaw]

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 removal procedure for pure C modules
> has not been defined yet.

I wonder if the one year/one version rule is too short.  Given that new
versions come about every 18 months, I'd probably give it a 2 year/one
version limit.

> 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 the option of bringing them back
> in 2.5.1 if people complain

+1 here too.

-Barry



signature.asc
Description: This is a digitally signed message part
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Eirik Mikkelsen]

On Sun, 2004-12-05 at 18:54 +0100, "Martin v. Löwis" wrote:

> I think it would be better to *remove* the xmllib documentation.
> Existing code which needs the module will continue to work even
> without documentation, and new code is unlikely to be written for
> a module that has no documentation, and where importing the module
> gives a DeprecationWarning.

Not sure I'm a registered voter, but I'll chip in with a
+1

If someone needs the documentation for xmllib it will still be available
in the older versions.

Eirik.

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Bill Janssen]

> * The average quality of the library improves as we take out junk (the
> tzparse module for example) and put in high quality modules like
> logging, csv, decimal, etc.

Yes and no.  The added modules have to be relevant to what users want
to do.  While (relatively) minor stuff like csv and decimal are good
ideas, of course, logging is kind of an "insider's" module.

What many more users want, however, are things like an XML parser, or
a CSS parser, or a usable HTTP server, or...  The fact that XML 1.1
can't be parsed with already-written Python is a *big* strike against.

So removing highly demanded functionality like XML parsing, and adding
specialist modules such as csv, do not overall help what users see as
the quality of the standard library.

Bill
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Deprecated xmllib module

[Tony Meyer]

>> * The average quality of the library improves as we take 
>> out junk (the tzparse module for example) and put in high
>> quality modules like logging, csv, decimal, etc.
> 
> Yes and no.  The added modules have to be relevant to what 
> users want to do.  While (relatively) minor stuff like csv 
> and decimal are good ideas, of course, logging is kind of an 
> "insider's" module.

What do you mean by "insiders"?  The logging module is great (ok, it could
be simpler to use in some cases) for any Python programmer.

> What many more users want, however, are things like an XML 
> parser, or a CSS parser, or a usable HTTP server, or...

Statements like this are pretty common, but there's no evidence (that I've
ever seen pointed to) that someone has *measured* how many people want
modules for X.  People who work with HTML at lot are probably keen on those
things you list, yes.  OTOH, other people (e.g. me) have no use for any of
those, but use CSV and logging daily.  Others want something completely
different.

There's quite a difference between quality and relevance.  It's certainly
worthwhile to ensure that all the standard library modules are as of high a
quality as possible (e.g. email > rfc822).  You'll never be able to get
everyone to agree on the same set of modules that are relevant.

If there are that many people that want (e.g.) a CSS parser, wouldn't there
be a 3rd party one that everyone is using that could be proposed for
addition into the standard library?

=Tony.Meyer

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Rewriting PEP4

[Raymond Hettinger]

> 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 for users; the
> module should be removed only if
> - continued usage poses a security threat to the application
>using it, or
> - there are no reported usages of the module anymore for quite
>some time
> - the module is unmaintained (i.e. there are serious outstanding
>unfixed bugs for it), and there are alternatives which are
>maintained.
> There must be a way for users to stop removal of the module,
> e.g. by volunteering to maintain an unmaintained module.

The effect of coding this into the PEP is to make deprecation
unnecessarily involved.  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.  



> 2. a comment must be added just above the warning, giving a
> the date and version of deprecation, and a
> rationale for removal (e.g.: no known users, is security risk)

We should only talk in terms of versions.  Dates are irrelevant and
confusing.  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.  


> 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 the option of bringing them back
> in 2.5.1 if people complain.

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.  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.  It
can and should be as simple as having us agree to deprecation, inserting
a warning, and then removing it two versions later.

Also, we need to shy away from the idea of having 2.5.1 with different
capabilities than 2.5.  This sort of thing is a portability disaster.
Anthony, please speak up.


General comments:

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.  

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?
Why the change in procedure?

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.

Also, as proposed, the PEP lists many forces against deprecation and
none of the forces for it.   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.

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.

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


Raymond

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Brett C.]

Martin v. Löwis wrote:
Brett C. wrote:
How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no 
mention of CPPFLAGS anywhere.

Right. That's what I meant when I said "has nothing to compute", so
it does not even mention CPPFLAGS.
And yet if I modify the definition of CPPFLAGS in Makefile.pre.in to 
``-I. -I./Include @[EMAIL PROTECTED] it ends up containing the value I have 
for the environment variable at the end of it.  I think the '@@' 
syntax uses a value from configure.in if it is defined else it 
defaults to the value the shell has.

Indeed, that seems to be the case. However, absence of @CPPFLAGS@
means that Makefile.pre will just use the static value from
Makefile.pre.in.
That's basically the functionality I need, so I am going with it.
Whether or not adding @CPPFLAGS@ to the end is the right thing,
I don't know.
Well, we will soon find out.  =)  My checkin made this change and everything 
seems fine.  If it doesn't work out I will have to create another environment 
variable to store the value.

Michael's desire of getting the Fink and DarwinPorts special casing in setup.py 
is now solved; setup.py now uses the directories specified in LDFLAGS and 
CPPFLAGS for compiling the extension modules.  I didn't bother with CFLAGS or 
CC since the former is mostly handled by BASECFLAGS it seems and the latter is 
specified by arguments to configure.

-Brett
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Rewriting PEP4

[Raymond Hettinger]

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 PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Rewriting PEP4

[Anthony Baxter]

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 the option of bringing them back
> > in 2.5.1 if people complain.
>
> [...]
>
> Also, we need to shy away from the idea of having 2.5.1 with different
> capabilities than 2.5.  This sort of thing is a portability disaster.
> Anthony, please speak up.

Sorry - been a bit busy the last few days. Raymond is right here - there's
no way we can or should do this. A bugfix release contains _bugfixes_.
Making new modules available in a bugfix is a sucky sucky approach.
Worse - once we remove a module, it should _stay_ removed. Otherwise,
we're going to end up with crap like:

 if sys.version < (2,5) or sys.version >= (2,6):
  import froggie
 else:
  # froggie was removed in 2.5 and reinstated in 2.6
  from compat import froggie

and people will be shipping their own versions of the code to get around
our misfeature.

-- 
Anthony Baxter <[EMAIL PROTECTED]>
It's never too late to have a happy childhood.
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Deprecated xmllib module

[Bill Janssen]

> Statements like this are pretty common, but there's no evidence (that I've
> ever seen pointed to) that someone has *measured* how many people want
> modules for X.

I almost didn't send this in, because I figured someone would have to
argue with it.

> If there are that many people that want (e.g.) a CSS parser, wouldn't there
> be a 3rd party one that everyone is using that could be proposed for
> addition into the standard library?

As far as I can tell, there are no CSS or XML 1.1 parsers for Python, period.

Bill
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Deprecated xmllib module

[Tony Meyer]

> As far as I can tell, there are no CSS or XML 1.1 parsers for 
> Python, period.

This belongs on c.l.p, I suppose, but the first page of google results
includes:




=Tony.Meyer

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Any reason why CPPFLAGS not used in compiling?

[Sjoerd Mullender]

Brett C. wrote:
Martin v. Löwis wrote:
Brett C. wrote:
I noticed that Makefile.pre.in uses the value from the environment 
variable LDFLAGS but not CPPFLAGS.  Any reason for this? 

How did you notice that? For LDFLAGS, Makefile.pre.in has
LDFLAGS=@LDFLAGS@
This does *not* mean that the value from the environment is used.
Instead, it means that configure computes the value of LDFLAGS
when it generates Makefile.in. For CPPFLAGS, configure has nothing
to compute, so Makefile.pre.in just has the static value for
CPPFLAGS.
I am not so sure that is true.  Checking configure.in, there is no 
mention of CPPFLAGS anywhere.  And yet if I modify the definition of 
CPPFLAGS in Makefile.pre.in to ``-I. -I./Include @[EMAIL PROTECTED] it ends up 
containing the value I have for the environment variable at the end of 
it.  I think the '@@' syntax uses a value from configure.in if it is 
defined else it defaults to the value the shell has.
It's autoconf that deals with these flags.  See the output of "configure 
--help".

--
Sjoerd Mullender <[EMAIL PROTECTED]>


signature.asc
Description: OpenPGP digital signature
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Weekly Python Patch/Bug Summary

[Kurt B. Kaiser]

Patch / Bug Summary
___

Patches :  259 open ( +1) /  2705 closed ( +4) /  2964 total ( +5)
Bugs:  800 open (-12) /  4662 closed (+20) /  5462 total ( +8)
RFE :  160 open ( +0) /   137 closed ( +1) /   297 total ( +1)

New / Reopened Patches
__

add key  (2004-12-01)
CLOSED http://python.org/sf/1077353  opened by  Steven Bethard

Simple webbrowser fix for netscape -remote  (2004-12-02)
   http://python.org/sf/1077979  opened by  Josh Cherry

readline does not need termcap  (2004-12-01)
   http://python.org/sf/1076826  reopened by  nijel

Make cgi.py use logging module  (2004-12-05)
   http://python.org/sf/1079729  opened by  Josh Hoyt

Make cgi.py use email instead of rfc822 or mimetools  (2004-12-05)
   http://python.org/sf/1079734  opened by  Josh Hoyt

list sort is not "in place"  (2004-12-06)
   http://python.org/sf/1080078  reopened by  rhettinger

list sort is not "in place"  (2004-12-06)
CLOSED http://python.org/sf/1080078  opened by  Heikki Orsila

Patches Closed
__

add key  (2004-12-02)
   http://python.org/sf/1077353  closed by  rhettinger

readline does not need termcap  (2004-12-01)
   http://python.org/sf/1076826  closed by  loewis

raise error for common mistake with subprocess  (2004-11-23)
   http://python.org/sf/1071755  closed by  astrand

list sort is not "in place"  (2004-12-06)
   http://python.org/sf/1080078  closed by  rhettinger

list sort is not "in place"  (2004-12-06)
   http://python.org/sf/1080078  closed by  tim_one

AUTH PLAIN in smtplib  (2004-11-30)
   http://python.org/sf/1075928  closed by  jlgijsbers

New / Reopened Bugs
___

problem with make test on OS/X  (2004-12-02)
CLOSED http://python.org/sf/1077302  opened by  Ian Holsman

threads: segfault or Py_FatalError at exit  (2004-11-08)
   http://python.org/sf/1061968  reopened by  mhammond

assert fail to threw exception when run python with '-O'  (2004-12-02)
CLOSED http://python.org/sf/1077862  opened by  tj128

Python2.4: building '_socket' extension fails with `INET_ADD  (2004-12-03)
   http://python.org/sf/1078245  opened by  Michael Ströder

Docs for run() methods are misleading  (2004-12-04)
CLOSED http://python.org/sf/1078905  opened by  Kent Johnson

Email.Header encodes non-ASCII content incorrectly  (2004-12-04)
   http://python.org/sf/1078919  opened by  Tessa Lau

Incorrect error message (somewhat)  (2004-12-04)
   http://python.org/sf/1079011  opened by  Gerrit Holl

datetime changes missing from "Porting from 2.3 to 2.4"  (2004-12-04)
   http://python.org/sf/1079134  opened by  Sadruddin Rejeb

python-2.4.msi install error  (2004-12-05)
   http://python.org/sf/1079545  opened by  maharal

IDLE and old color themes  (2004-12-06)
   http://python.org/sf/1080387  opened by  projecktzero

Bugs Closed
___

threads: segfault or Py_FatalError at exit  (2004-11-07)
   http://python.org/sf/1061968  closed by  arigo

Tutorial corrections  (2004-12-01)
   http://python.org/sf/1076955  closed by  rhettinger

test_shutil fails on x86-64 // Suse 9.1  (2004-12-01)
   http://python.org/sf/1076467  closed by  jlgijsbers

test test_unicodedata failed   (2004-12-01)
   http://python.org/sf/1076795  closed by  lemburg

Problem testing python 2.4  (2004-12-01)
   http://python.org/sf/1077103  closed by  lemburg

re module segfaulting in large regular expression  (2004-11-24)
   http://python.org/sf/1072259  closed by  niemeyer

Memory fault pyexpat.so on SGI  (2004-11-30)
   http://python.org/sf/1075990  closed by  akuchling

assert fail to threw exception when run python with '-O'  (2004-12-02)
   http://python.org/sf/1077862  closed by  tim_one

Errors and omissions in logging module documentation  (2004-11-28)
   http://python.org/sf/1074693  closed by  vsajip

xml.dom.minidom produces errors with certain unicode chars  (2004-11-27)
   http://python.org/sf/1074200  closed by  effbot

test test_re produced unexpected output  (2004-12-01)
   http://python.org/sf/1076791  closed by  nijel

^Z doesn't exit interpreter - 2.4c1 & Win2K  (2004-11-26)
   http://python.org/sf/1073736  closed by  facundobatista

test_macostools failure on OS X  (2004-12-01)
   http://python.org/sf/1077302  closed by  bcannon

PyGILState_Ensure() deadlocks (ver 2.4)  (2004-11-29)
   http://python.org/sf/1075703  closed by  andivajda

calendar.weekheader() undocumented  (2004-05-04)
   http://python.org/sf/947894  closed by  doerwalter

Docs for unittest run() methods are misleading  (2004-12-04)
   http://python.org/sf/1078905  closed by  rhettinger

Another message that croaks email.FeedParser  (2004-11-30)
   http://python.org/sf/1076485  closed by  bwarsaw

Windows msi doesn't install site-packages directory  (2004-11-23)
   http://python.org/sf/1071594  closed by  loewis

win32con missing codes VK_VOLUME_MUTE, VK_BROWSER_BACK,

Re: [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 fo

Re: [Python-Dev] Rewriting PEP4

["Martin v. Löwis"]

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 typically brought up by book authors, so I should have brought
it up myself :-)
Of course, developers would first see the deprecation warning,
which would tell them that their books are outdated. However, if
the code is removed, they get an import error, which leaves them
guessing what the problem might have been.
Regards,
Martin
___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

RE: [Python-Dev] Rewriting PEP4

[Raymond Hettinger]

> 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 more public participation is a wise step.

I would just like to see a clean, actionable PEP.  To me, the draft text
outlined a timid, faltering process that would be hard to follow, prone
to reversal, and accomplish little.

I especially find burdensome the obligation to undo a deprecation the
moment some random user sends a grumpy email.

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.

Once a couple versions pass, some useful action needs to take place.  If
the code is left in-place and the doc index is just re-arranged, then we
would have been better off not doing anything at all.  

Ideally, the PEP should also provide some informational value.  It
should list Barry's link as a reference for old docs.  It should
describe the appropriate use of lib-old (like whrandom) vs. renaming a
module (like stringold) vs. leaving it in-place (like xmllib) vs.
removing the module 

The questions of dates was somewhat minor.  I was unclear on the
implication of, for example, "remove on 15Jan2005".  Since Py2.5 won't
go out for at least a year, does that mean that the work can't be done
now while I have time instead of later when I don't.  The only time the
removal becomes visible is when a new version goes out the door.
Further, if a version is going to have something removed, we should do
it at the outset rather than just before a release goes out the door (to
allow for early surfacing of any issues).



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

If we really don't care whether it gets done, then we shouldn't bother
in the first place.



Raymond

___
Python-Dev mailing list
[EMAIL PROTECTED]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com