> To further elaborate, the main obstacle is with extension modules.
> Most of them create roots and there is no defined API for the Python
> interpreter to find them.
That is a problem, but furthermore, I feel that local variables stored
in stack frames of threads are even more difficult to integ
Hrvoje Nikšić wrote:
> That sounds like a case for the Pixbuf object to have a "close" method
> (not necessarily called that) that releases the resources. The point of
> GC is that you normally don't care if memory is released sooner or
> later;
I think the problem here is that the GC's lack of k
2007/10/2, Mark Dickinson <[EMAIL PROTECTED]>:
> difficulties. In particular, some cases of three-argument pow that
> previously worked (giving arguably nonsensical results) will now raise an
> exception. To be honest, I'd be quite surprised to find that *anyone* was
If previously it gave a arg
Martin v. Löwis <[EMAIL PROTECTED]> wrote:
>> Why isn't the mark-and-sweep mechanism used for all memory
>> management?
>
> See above - it's not implementable, because the root objects get not
> tracked.
To further elaborate, the main obstacle is with extension modules.
Most of them create roots a
On 10/2/07, Facundo Batista <[EMAIL PROTECTED]> wrote:
>
> 2007/10/2, Raymond Hettinger <[EMAIL PROTECTED]>:
>
> > Yes! We have guaranteed that spec updates are to be treated as bug
> fixes and backported. This is especially important in this case
> > because other errors have been fixed and the
> If there are any plans for another 2.4 release, then yes; otherwise, why
> bother.
Please don't make any functional changes to 2.4. There may be additional
releases, but (IMO) they should be security releases only, i.e. contain
no functional changes whatsoever (unless they fix a security issue)
Jeremy covered already most of it, so I'll only address specific points:
> and I think that the current gc
> module is of the mark-and-sweep variety.
That is incorrect. It's two phases, but in the first phase, it isn't
"mark", but "count", and in the second phase, it's not "sweep" but
"break". To
>> Yes! We have guaranteed that spec updates are to be treated as bug fixes
>> and backported. This is especially important in this
>> case
>> because other errors have been fixed and the test cases have grown.
>
> Perfect! I'll backport it to 2.5... what about 2.4?
If there are any plans for
2007/10/2, Raymond Hettinger <[EMAIL PROTECTED]>:
> Yes! We have guaranteed that spec updates are to be treated as bug fixes and
> backported. This is especially important in this case
> because other errors have been fixed and the test cases have grown.
Perfect! I'll backport it to 2.5... wha
> Decimal is a pretty stand alone module, and I'm absolutely sure that
> just backporting the whole module and its testcases will fix a lot of
> problems, and Py2.5 users will have new functionality, but is this ok?
Yes! We have guaranteed that spec updates are to be treated as bug fixes and
bac
People:
I don't decide myself what to do in this case.
The Decimal module appeared in 2.4, and received just slight
modifications for 2.5. Since it appeared, a "just download and use it"
version was available for Python 2.3 users.
But for 2.6, it was fully renewed. Not only was updated to the la
2007/9/19, Ron Adam <[EMAIL PROTECTED]>:
> I noticed that there is a background of light blue between marks. That is
> hard to see on my computer because it is so close to the grey tone.
Made it a little darker, now it's easier to look.
> Also shouldn't the light blue background bar extend all
On 10/2/07, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct. And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
> > retained by a Python Object. Like i
On Tue, 2007-10-02 at 11:30 +0100, Gustavo Carneiro wrote:
> even large memory objects, there is always explicit
> management.
> cStringIO's "close" method provides a precedent.
>
> I think close in real files is needed not so much because you want to
> free memory, but th
On 02/10/2007, Hrvoje Nikšić <[EMAIL PROTECTED]> wrote:
>
> On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> > Correct. And that reminds me of the limitation of the the Python GC:
> > it doesn't take into account how much memory is being indirectly
> > retained by a Python Object. Lik
On Tue, 2007-10-02 at 10:50 +0100, Gustavo Carneiro wrote:
> Correct. And that reminds me of the limitation of the the Python GC:
> it doesn't take into account how much memory is being indirectly
> retained by a Python Object. Like in the example I already gave,
> gtk.gdk.Pixbuf can easily hold
On 02/10/2007, Adam Olsen <[EMAIL PROTECTED]> wrote:
>
> On 10/1/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > Justin Tulloss wrote:
> > > Would
> > > somebody care to give me a brief overview on how the current gc module
> > > interacts with the interpreter
> >
> > The cyclic GC kicks in when memo
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> Does anyone else have the feeling that discussions with Mr. MacLaren
> don't usually bear any fruit?
Yes. I do. My ability to predict the (technical) future is good;
my ability to persuade people of it is almost non-existent.
However, when an al
18 matches
Mail list logo
