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 real
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 ti
(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 change
> 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/
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
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
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
> > >tal
--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 h
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:/
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
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
>
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 t
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
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 thi
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.
> > 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 t
"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 mislea
> 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
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
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 a
20 matches
Mail list logo
