Re: [Python-Dev] Deprecated xmllib module
Raymond Hettinger wrote: Hmph. The xmllib module has been deprecated since Py2.0 but is not listed in PEP 4. Question: Do we have to keep it for another two years because of that omission? It seems somewhat silly to keep an obsolete, supplanted module that doesn’t full support XML 1.0. I mostly agree with Fredrik. What good does removal of xmllib do? It's not that it is causing any maintenance burden, so we could just leave it in. Whether this means that we keep xmllib until P3k, I don't know. As for PEP 4: I don't know whether it needs to be listed there. It appears that the PEP is largely unmaintained (I, personally, do not really maintain it). So one option would be to just stop using PEP 4 for recording deprecations, since we now have the warnings module. If we want to keep PEP 4, we need to follow the procedures it requires (or modify them if we don't like them). 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?
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. 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] Deprecated xmllib module
> As for PEP 4: I don't know whether it needs to be listed there. It > appears that the PEP is largely unmaintained (I, personally, do not > really maintain it). So one option would be to just stop using PEP 4 > for recording deprecations, since we now have the warnings module. +1 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." <[EMAIL PROTECTED]> writes: > I noticed that Makefile.pre.in uses the value from the environment > variable LDFLAGS but not CPPFLAGS. Any reason for this? > ./configure -h`` lists both (and some other environment variables > which are not really used either) so it seems a little misleading to > have those listed but to not utilize them. The whole story of how the compiling/linker flags get set up is a bit of a mess, AFAIK. I don't have the energy or the desire to try to make what we want to happen precise (the hard bit) and then make that happen (probably rather easier). > This should allow for the removal of the direct support for Fink and > DarwinPorts. +lots. I don't trust fink, but need it for latex... Cheers, mwh -- After a heavy night I travelled on, my face toward home - the comma being by no means guaranteed. -- paraphrased from cam.misc ___ 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
> > It seems somewhat silly to keep an obsolete, supplanted module that > > doesnt full support XML 1.0. > > I mostly agree with Fredrik. What good does removal of xmllib do? A few thoughts: * Deprecated modules just get moved to the lib-old directory. If someone has ancient code relying on the module, it is a somewhat trivial maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see the harm. * For this particular module, xmllib, about six years will have elapsed between its original deprecation in Py2.0 and us taking it out in a Py2.5 release. * The number one current python complaint is the state of the standard library: http://www.internetnews.com/dev-news/article.php/3441931 . Some of this may just be the fruits of AMK's highly publicized journal entry; however, I think the concerns about library quality will persist. * 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. * After working through the tutorial, another huge task for aspiring intermediate Python programmer is to learn about the standard library. That task is made much difficult by the presence of obsolete, incomplete, and/or supplanted modules. For example, the high quality, actively maintained email package supplants several older, incomplete, or non-actively maintained modules. The library would be cleaner, more presentable, and easier to use if the old ones were to fall by the wayside. * Ideally, the library will develop in a way that doesn't have a cluttered concept space. This will help get it back to the point where you can hold it in your head all at once and still be able to think about the problem domain. Keeping cruft impedes that goal. my two cents, 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
Raymond Hettinger wrote: * Deprecated modules just get moved to the lib-old directory. If someone has ancient code relying on the module, it is a somewhat trivial maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see the harm. I have never considered this as an official policy. For example, when deprecated C modules are removed, they are never moved to lib-old. * For this particular module, xmllib, about six years will have elapsed between its original deprecation in Py2.0 and us taking it out in a Py2.5 release. Correct. For regex, much more time has passed (it is deprecated since 1.5 or something). * The number one current python complaint is the state of the standard library: http://www.internetnews.com/dev-news/article.php/3441931 . Some of this may just be the fruits of AMK's highly publicized journal entry; however, I think the concerns about library quality will persist. I agree. Removing old modules might change this, indeed: the complaint about unstability and incompatibility might then become the number one complaint :-) * 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. I am not convinced that all these more recent modules are really higher quality than the modules that have been added ten years ago. Some are (especially those which has seen extensive testing before being integrated), some are not (especially those added in an ad-hoc manner). 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] Deprecated xmllib module
On Sunday 05 December 2004 21:40, Raymond Hettinger wrote: > * The number one current python complaint is the state of the standard > library: http://www.internetnews.com/dev-news/article.php/3441931 . > Some of this may just be the fruits of AMK's highly publicized journal > entry; however, I think the concerns about library quality will persist. > > * 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. We can't win - if we remove it, we'll get massive numbers of complaints bitching about us breaking backwards compatibility. I think the solution is to make sure the library docs say, very clearly, in big words at the top of the relevant page "DON'T DO NEW CODE WITH THIS MODULE". Perhaps Fred can make latex2html output a tag around it . The library docs for, e.g. xmllib already say deprecated at the top - maybe it should be larger? Should the global module index should grow a "(deprecated)" line next door to the module name of the modules that are known to be old and kinda awful (such as xmllib)? Or make a seperate category - normal modules, and modules-that-are-only-kept-for-backwards compat? I suspect that rfc822 will end up in that latter category, rather than ever being removed (at least, until 3.0). I went through just my own code, and found an amazing amount of use of that module. Python has a reputation for stability and not forcing people to rewrite their code - I think that this is a good thing. IOW, I think breaking code is far worse than some folks whining that some of the stdlib is old and crufty. 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. > * After working through the tutorial, another huge task for aspiring > intermediate Python programmer is to learn about the standard library. > That task is made much difficult by the presence of obsolete, > incomplete, and/or supplanted modules. Surely this one is something that can be fixed in the documentation by marking obsolete modules as such, or making the marking much clearer? Anthony ___ 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
On Sun, 2004-12-05 at 03:36, "Martin v. Löwis" wrote: > I mostly agree with Fredrik. What good does removal of xmllib do? > It's not that it is causing any maintenance burden, so we could just > leave it in. Whether this means that we keep xmllib until P3k, I > don't know. > > As for PEP 4: I don't know whether it needs to be listed there. It > appears that the PEP is largely unmaintained (I, personally, do not > really maintain it). So one option would be to just stop using PEP 4 > for recording deprecations, since we now have the warnings module. > If we want to keep PEP 4, we need to follow the procedures it > requires (or modify them if we don't like them). I agree. We don't need to use PEP 4 for listing module deprecation schedules. It would be better if we included that information in the DeprecationWarning. Probably nobody reads PEP 4 when they get a DeprecationWarning, but everyone reads the message that's printed, so if it said something like "This module is deprecated and slated for removal in Python 2.6", I think we'd be providing better information to our users. -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
On Sun, 2004-12-05 at 05:40, Raymond Hettinger wrote: > * The number one current python complaint is the state of the standard > library: http://www.internetnews.com/dev-news/article.php/3441931 . > Some of this may just be the fruits of AMK's highly publicized journal > entry; however, I think the concerns about library quality will persist. I don't know if I'd use one quote from this article to infer that standard library issues are the #1 complaint. But besides that, there's no question IMO that the standard library should be the place where future Python development efforts are focused (not exclusively, but predominately). > * 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. > > * After working through the tutorial, another huge task for aspiring > intermediate Python programmer is to learn about the standard library. > That task is made much difficult by the presence of obsolete, > incomplete, and/or supplanted modules. You don't have to remove modules to make this happen. Few developers find modules by doing an 'ls' on Lib -- they look to the library reference docs, books, and existing code. So for example, the re-org I did on the string module docs for 2.4 should help, because now you can't look up a string function such as atoi() without seeing that it's deprecated. A developer writing new code hopefully wouldn't even waste time learning about those functions, and instead hop right to the preferred string methods. Yet, there's no push in the community to actually remove those deprecated functions from string.py. > For example, the high quality, actively maintained email package > supplants several older, incomplete, or non-actively maintained modules. > The library would be cleaner, more presentable, and easier to use if the > old ones were to fall by the wayside. Yes, but there's still /a lot/ of work to do to update the existing standard library to use the email package. We debated this during 2.4 and decided we can't even add deprecation warnings to things like rfc822.py until we do. > * Ideally, the library will develop in a way that doesn't have a > cluttered concept space. This will help get it back to the point where > you can hold it in your head all at once and still be able to think > about the problem domain. Keeping cruft impedes that goal. Agreed, but I think it's mostly going to be an organic process over time. -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
On Sun, 5 Dec 2004 05:40:16 -0500, Raymond Hettinger <[EMAIL PROTECTED]> wrote: > * Deprecated modules just get moved to the lib-old directory. If > someone has ancient code relying on the module, it is a somewhat trivial > maintenance step to add lib-old to their PYTHONPATH. IOW, I fail to see > the harm. In principle, that's a good idea, but I don't know if it's really practical. I fear that the distribution would end up simply adding lib-old to the PYTHONPATH anyway :-) But some variations may be worth considering: 1) Deprecated modules would first generate a warning (as it is today). On future versions, instead of being removed, the level of the warning would be raised, causing a fatal exception (an ImportError?), unless explicitly configured otherwise (using a config file or some similar mechanism). I believe that the current warnings module already provides a good basis for this implementation. (IOW - the module would still be there, and could be activated, but it's "off" by default. Turning it on again has to be easy, though. And the message on "ImportError" have to meaningful for non-technical users, allowing for easier support in these situations) 2) Split the documentation: the "old-and-deprecated" modules would be listed separated from the active & recommended ones, as a different section, or even as a separate book. That would be a clear sign to new users to keep in mind while they read the documentation, perhaps more effective than writing the deprecation warning on the top of the page. My half-a-cent. -- 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
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. 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. 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
[Python-Dev] Python 2.4 and Zope 2.7.X
A report on the [EMAIL PROTECTED] list suggests that Python 2.4 is not fully compatible with Zope 2.7.3. Has any tested against Zope? ___ 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] Python 2.4 and Zope 2.7.X
--On Sonntag, 5. Dezember 2004 10:30 Uhr -0800 Dennis Allison <[EMAIL PROTECTED]> wrote: A report on the [EMAIL PROTECTED] list suggests that Python 2.4 is not fully compatible with Zope 2.7.3. Has any tested against Zope? To which report do you refer? The only thing I mentioned is that there has not been any audit for Python 2.4 + Zope 2.7 as with Python 2.3 + Zope 2.6/2.7. -aj ___ 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] proposal+patch: sys.gettickeraccumulation()
Brett C. wrote: > Ralf W. Grosse-Kunstleve wrote: > > Brett C. wrote: > > > > >I have been mulling over this proposal and I think I am finally > > >settling on +0 as long as it can be shown that it does not hurt > > >performance at all (yes, it shouldn't but this is the eval loop we are > > >talking about and that thing is a touchy beast). > > > > > > Is there a standard benchmark I could use to demonstrate the > > impact of the two new additions on the runtime? > > Thanks! > > =) Parrotbench and PyBench would be enough for me to sign off on any > performance hit. There is also pystone. I have done my homework now, based on parrotbench. Timings are below. The most important conclusion from my viewpoint is that my original goal can be achieved with a small patch and with a runtime penalty that is in the noise. However, mysterious runtime behavior of Objects/longobject.c lead me to change my original patch, and to the unanswered question "could small rearrangements in longobject.c potentially boost performance by 45% on some platforms?" Please don't be put off by the size of this message. My patch is essentially just one line in ceval.c (_Py_TickerAccumulation++)! To restate my original goal: I am looking for a simple way to answer the question: How much of a speedup can I expect if I reimplement a piece of Python code in C or C++? Note that I am not asking how much time is spent in Python including all the extensions that come with it, but how much time is spent in the Python bytecode interpreter loop. To clarify, look at the timings for two tests in parrotbench: b1 5.8287 time30049474 ticks0.1940 us/tick b2 1.5944 time 482584 ticks3.3039 us/tick Each of the tests was run with range(10) in b.py to increase accuracy. The first column shows time.time() differences, the second the number of bytecodes processed in ceval.c, and the last column shows micro-seconds per tick. Why is the us/tick value for b2 17 times larger than that for b1? The answer is that b2 makes heavy use of long integers, and that a lot of time is spent in Objects/longobject.c doing long-integer arithmetic. Compared to b1, relatively little time is spent interpreting bytecodes. Back to the original question: how much sense does it make to reimplement b1 or b2 in C? Simply looking at the us/tick values is telling me that I can expect much more of a performance boost by reimplementing b1 rather than b2. This is because b2 spends a lot of time in C already. A similar situation arises if extensions like Numeric are used. Computationally intensive operations like matrix multiplication and matrix inversion are already done at C speed. The us/tick let us quickly estimate how disappointed we would be after moving Python code to C or C++. We get this estimate without having to do detailed source code analysis, and before we have wasted our time doing the recoding (we have been through this a couple of times ...). The timings below show that the patched Python which counts the number of interpreted bytecodes is in the worst case 0.6% slower than the original Python, but some tests even run faster at face value: $gcc296_compiled/original/python -O b_timings.py | grep reporter b0 16.8831 time b1 5.9553 time b2 1.5914 time b3 10.8149 time b4 5.2528 time b5 11.6437 time b6 11.0248 time b7 27.6960 time all 90.9276 time $gcc296_compiled/work/python -O b_timings.py | grep reporter b0 16.9193 time50979585 ticks0.3319 us/tick b1 5.8287 time30049474 ticks0.1940 us/tick b2 1.5944 time 482584 ticks3.3039 us/tick b3 10.7931 time43577404 ticks0.2477 us/tick b4 5.2865 time18463044 ticks0.2863 us/tick b5 11.6086 time17065750 ticks0.6802 us/tick b6 10.0992 time6464 ticks0.1683 us/tick b7 27.6830 time 1928644 ticks 14.3536 us/tick all 89.8760 time 222548399 ticks0.4038 us/tick The b7 test is the same as b2 but with xrange(1) instead of xrange(1000), and with all print statements removed. Ratios (rounded to 3 decimals): 16.9193/16.8831=1.002 5.8287/5.9553 =0.979 1.5944/1.5914 =1.002 10.7931/10.8149=0.998 5.2865/5.2528 =1.006 11.6086/11.6437=0.997 10.0992/11.0248=0.916 27.6830/27.6960=1.000 Therefore I'd argue that the runtime penalty for the one additional long long increment in ceval.c (_Py_TickerAccumulation++) is in the noise. The timings were collected on a 2.8GHz Dual Xeon, Redhat WS 3. Python was compiled under Red Hat 7.3 with gcc 2.96. See below why. My latest patch can be found at the end of this posting. It can be applied to the Python-2.4 distribution like this: tar zxf Python-2.4.tgz patch --strip=1 -d Python-2.4 < patch_file --
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 new code is unlikely to be written for a module that has no documentation, and where importing the module gives a DeprecationWarning. I like this solution. And if anyone cares about having good docs still for a deprecated module they can just read the docstrings. We don't get new people using it but others don't have to change their code. 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? -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] 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 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 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. Not a big deal, though. I will just use the environment variables in setup.py . -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] proposal+patch: sys.gettickeraccumulation()
> To restate my original goal: > > I am looking for a simple way to answer the question: How much of a > speedup can I expect if I reimplement a piece of Python code in C or > C++? . . . > Ratios (rounded to 3 decimals): > 16.9193/16.8831=1.002 > 5.8287/5.9553 =0.979 > 1.5944/1.5914 =1.002 > 10.7931/10.8149=0.998 > 5.2865/5.2528 =1.006 > 11.6086/11.6437=0.997 > 10.0992/11.0248=0.916 > 27.6830/27.6960=1.000 > > Therefore I'd argue that the runtime penalty for the one additional > long long increment in ceval.c (_Py_TickerAccumulation++) is in the > noise. The measurements are too imprecise to draw any worthwhile conclusions. Try running: python timeit.py -r9 "pass" That ought to give more stable measurements. The proposed "analysis tool" has no benefit to a majority of Python users. Even a 1% hit is not worth it. > I am only interested in counting the > iterations of the interpreter loop. However, the _Py_Ticker decrements > in longobject.c are not inside the interpreter loop, but in C loops! > This means _Py_Ticker is useless for my purposes. Therefore I decoupled > _Py_Ticker and _Py_TickerAccumulation. Why add this to everyone's build? Just put it in when doing your own analysis. The eval loop already pays a penalty for Py2.4's extra function tracing code. And ceval.c has been cluttered with #ifdefs for hardware timestamps. And there have been other additions for signal handling and whatnot. This is enough. >. A lot of fallout caused by the simple idea to add one innocent > line to ceval.c. I do not find it to be innocent. A great of work was expended over the years just trying to eliminate a small step or two from the eval-loop. Those efforts should not be discarded lightly. -1 on adding it directly. -0 on adding it as a #ifdeffed compile option (with the default being to exclude it). Raymond Hettinger ___ 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] pystone rant [was] proposal+patch: sys.gettickeraccumulation()
(Old message) > > =) Parrotbench and PyBench would be enough for me to sign off on any > > performance hit. There is also pystone. pystone is good a predicting the relative performance of python apps on difference hardware/software environments. As a tool for evaluating proposed language changes, it completely sucks and should *never* be used for anything other than an extra informational datapoint. The foremost issue is that it exercises only a tiny portion of the language. Its design makes it worse than totally useless for evaluating eval-loop overhead. It runs a loop twice, once with benchmarking code and once without. Only the difference is reported. In theory, that means that all eval-loop speedups and slowdowns are netted out of the result. In practice, the reported result may indicate exactly the opposite of reality because the empty loop has vastly different cache effects than the benchmarked loop. For useful timings, run timeit on the specific feature in question. Then check for overall impact using pybench, parrotbench, and test_decimal. 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] pystone rant [was] proposal+patch: sys.gettickeraccumulation()
On Monday 06 December 2004 11:33, Raymond Hettinger wrote: > pystone is good a predicting the relative performance of python apps on > difference hardware/software environments. This comes up so often that I'm almost tempted to add a disclaimer to the pystone output. I can't count the number of times people have tried to claim that pystone showed that a change was good/neutral. ___ 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
On Sun, 2004-12-05 at 18:49, 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? There's really no such thing as "dropping" a PEP, but in any event, we should still keep PEP 4 to document the procedure for deprecating modules. It just doesn't need to list any modules (i.e. remove the sections labeled Obsolete modules, Deprecated modules, and Undeprecated 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
