Evan Jones wrote:
The next page has a
micro-benchmark that shows reference counting performing very poorly.
Not to mention that Python has a garbage collector *anyway,* so wouldn't
it make sense to get rid of the reference counting?
It's not clear what these numbers exactly mean, but I don't
Anthony Baxter wrote:
I'm currently thinking about a 2.4.1 around the 23td of Feb - Martin and
Fred, does this work for you?
Yes. I will need to test whether my replacement of VB scripts in the
installer with native DLLs works even on W95; I'm confident to complete
this next week (already have the
Brett C. wrote:
But if people don't have that in mind, should we not be encouraging
this? I mean it seems to be defeating the purpose of SF and having the
various mailing lists that send out updates on SF posts.
Clearly, the comment should *also* go to SF - posting it to python-dev
may mean it
Travis Oliphant wrote:
I am a co-author of the current PEP regarding inclusion of the
multidimensional array object into the core. However, that PEP is
sorely outdated.
[...]
1) What specifically about Numeric prevented it from being acceptable as
an addition to the Python core.
2) Are there
Travis Oliphant wrote:
Exactly, the PEP does not reflect the reality of what anybody wants in
the core. It needs modification, or replacment. Can I just do that?
My understanding is this: you can, and you should.
You are the author of the PEP (together with Paul Barrett), and the
PEP is
Travis Oliphant wrote:
In other words, what I'm saying is that in terms of how the array object
should be structure, a lot is known. What is more controversial is
should the design be built upon Numarray's object structure (a mixture
of Python and C), or on Numeric's --- all in C
To me, this
Brett C. wrote:
All valid points, but I also don't want people to suddenly start posting
one-liners or bug posts.
I agree that keeping the noise level low is desirable; I hope this will
come out naturally when we start commenting on high-noise remarks.
For example, I would have no problems
Phillip J. Eby wrote:
Isn't the PSF somewhere in between? I mean, in theory we are supposed
to be tracking stuff, but in practice there's no contributor agreement
for CVS committers ala Zope Corp.'s approach.
That is not true, see
http://www.python.org/psf/contrib.html
We certainly don't have
Phillip J. Eby wrote:
I personally can't see how taking the reasonable interpretation of a
public domain declaration can lead to any difficulties, but then,
IANAL.
The ultimate question is whether we could legally relicense such
code under the Python license, ie. remove the PD declaration, and
Terry Reedy wrote:
As I remember, my impression was based on the suggested procedure of first
copywrite one's work and then license it under one of two acceptible
original licenses. This makes sense for a whole module, but hardly for
most patches, to the point of being nonsense for a patch of
Tim Peters wrote:
I'm not certain it is acceptable to make this assumption. Why is it
not possible to use the same approach that was previously used (i.e.
leak the arenas array)?
Do you have something else in mind? I'll talk with Martin about it if
he still wants to. Martin, this
Gfeller Martin wrote:
Nevertheless, I tried to convert the heap used by Python
to a Windows Low Fragmentation Heap (available on XP
and 2003 Server). This improved the overall run time
of a typical CPU-intensive report by about 15%
(overall run time is in the 5 minutes range), with the
same
12 matches
Mail list logo
