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 mise
Patch / Bug Summary
___
Patches : 298 open (+14) / 2754 closed ( +6) / 3052 total (+20)
Bugs: 823 open (+19) / 4829 closed (+17) / 5652 total (+36)
RFE : 168 open ( +1) / 144 closed ( +2) / 312 total ( +3)
New / Reopened Patches
__
date.strp
[Tim Peters]
>> As I said before, I don't think we need to support this any more.
>> More, I think we should not -- the support code is excruciatingly
>> subtle, it wasted plenty of your time trying to keep it working, and
>> if we keep it in it's going to continue to waste time over the coming
>>
On Feb 15, 2005, at 17:52, Tim Peters wrote:
As I said before, I don't think we need to support this any more.
More, I think we should not -- the support code is excruciatingly
subtle, it wasted plenty of your time trying to keep it working, and
if we keep it in it's going to continue to waste time
[Evan Jones]
> After I finally understood what thread-safety guarantees the Python
> memory allocator needs to provide, I went and did some hard thinking
> about the code this afternoon. I believe that my modifications provide
> the same guarantees that the original version did. I do need to declar
After I finally understood what thread-safety guarantees the Python
memory allocator needs to provide, I went and did some hard thinking
about the code this afternoon. I believe that my modifications provide
the same guarantees that the original version did. I do need to declare
the arenas
Guido van Rossum <[EMAIL PROTECTED]> writes:
>> My design decision was to make Exception new-style. Things can be
>> raised if they are instances of old-style classes or instances of
>> Exception. If this meets with general agreement, I'd like to check
>> the above patch in.
>
> I like it, but d
> My design decision was to make Exception new-style. Things can be
> raised if they are instances of old-style classes or instances of
> Exception. If this meets with general agreement, I'd like to check
> the above patch in.
I like it, but didn't you forget to mention that strings can still be
Michael Hudson <[EMAIL PROTECTED]> writes:
> Michael Hudson <[EMAIL PROTECTED]> writes:
>
>> I hope to have a new patch (which makes PyExc_Exception new-style, but
>> allows arbitrary old-style classes as exceptions) "soon". It may even
>> pass bits of "make test" :)
>
> Done: http://www.python.o
[Fredrik Lundh]
> does anyone remember if there were any big changes in pymalloc between
> the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
> default).
Yes, huge -- few original lines survived exactly, although many
survived in intent.
> or in other words, is the 2.1.3 py
[Fredrik Lundh]
> can anyone explain the struct.pack and ZODB use cases? the first one
> doesn't make sense to me,
Not deep and surely not common, just possible. If you're on a 32-bit
box and doing struct.pack("...i...", ... id(obj) ...), it in fact
cannot fail now (no, that isn't guaranteed by
"Fredrik Lundh" <[EMAIL PROTECTED]> writes:
> does anyone remember if there were any big changes in pymalloc between
> the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
> default).
Yes. (Was it really 2.1? Time flies!)
> or in other words, is the 2.1.3 pymalloc stable e
does anyone remember if there were any big changes in pymalloc between
the 2.1 series (where it was introduced) and 2.3 (where it was enabled by
default).
or in other words, is the 2.1.3 pymalloc stable enough for production use?
(we're having serious memory fragmentation problems on a 2.1.3 syst
James Y Knight wrote:
> However, last time this topic came up, this Tim Peters guy argued against it.
> ;)
>
> Quoting http://mail.python.org/pipermail/python-dev/2004-November/050049.html:
>
>> Python doesn't promise to return a postive integer for id(), although
>> it may have been nicer if it
Josiah Carlson wrote:
Quoting
http://mail.python.org/pipermail/python-dev/2004-November/050049.html:
Python doesn't promise to return a postive integer for id(), although
it may have been nicer if it did. It's dangerous to change that now,
because some code does depend on the "32 bit-ness as a
15 matches
Mail list logo
