RE: [Python-Dev] Rewriting PEP4

> 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

Re: [Python-Dev] Rewriting PEP4

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

Re: [Python-Dev] Rewriting PEP4

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

[Python-Dev] Weekly Python Patch/Bug Summary

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

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

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 val

RE: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Rewriting PEP4

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

RE: [Python-Dev] Rewriting PEP4

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

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

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, co

RE: [Python-Dev] Rewriting PEP4

> 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

RE: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Deprecated xmllib module

> * 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 decima

Re: [Python-Dev] Deprecated xmllib module

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,

Re: [Python-Dev] Rewriting PEP4

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

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

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

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

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

Re: [Python-Dev] Rewriting PEP4

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

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

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**!

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

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 envi

RE: [Python-Dev] Deprecated xmllib module

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 docume

RE: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Deprecated xmllib module

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

Re: [Python-Dev] Deprecated xmllib module

"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

Re: [Python-Dev] Deprecated xmllib module

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