In article ,
Steven D'Aprano wrote:
>
>Additionally, while I'm a fan of the simplicity of CPython's ref counter,
>one serious side effect of it is that it requires the GIL, which
>essentially means CPython is crippled on multi-core CPUs compared to non-
>ref counting implementations.
Your bare
> Charles Yeomans (CY) wrote:
>CY> Memory management may be an "implementation detail", but it is
>CY> unfortunately one that illustrates the so-called law of leaky
>CY> abstractions. So I think that one has to write code that follows the
>CY> memory management scheme of whatever language on
On Wed, 17 Jun 2009 22:58:27 -0400, Charles Yeomans wrote:
> On Jun 17, 2009, at 9:43 PM, Steven D'Aprano wrote:
>
>> On Wed, 17 Jun 2009 07:49:52 -0400, Charles Yeomans wrote:
>>
Even CPython doesn't rely completely on reference counting (it has a
fallback gc for cyclic garbage). Pyth
On Jun 17, 2009, at 9:43 PM, Steven D'Aprano wrote:
On Wed, 17 Jun 2009 07:49:52 -0400, Charles Yeomans wrote:
Even CPython doesn't rely completely on reference counting (it has a
fallback gc for cyclic garbage). Python introduced the "with"
statement to get away from the kludgy CPython prog
On Wed, 17 Jun 2009 23:29:48 +1200, Lawrence D'Oliveiro wrote:
> In message <7x7hzbv14a@ruckus.brouhaha.com>, wrote:
>
>> Lawrence D'Oliveiro writes:
>>
>>> > Reference counting is an implementation detail used by CPython but
>>> > not [implementations built on runtimes designed for
>>> > c
On Wed, 17 Jun 2009 07:49:52 -0400, Charles Yeomans wrote:
>> Even CPython doesn't rely completely on reference counting (it has a
>> fallback gc for cyclic garbage). Python introduced the "with"
>> statement to get away from the kludgy CPython programmer practice of
>> opening files and relying
On Jun 17, 2009, at 2:13 AM, Paul Rubin wrote:
Lawrence D'Oliveiro writes:
Reference counting is an implementation detail used by CPython but
not
[implementations built on runtimes designed for corporate-herd-
oriented
languages, like] IronPython or Jython.
I rest my case.
You're reall
In message <7x7hzbv14a@ruckus.brouhaha.com>, wrote:
> Lawrence D'Oliveiro writes:
>
>> > Reference counting is an implementation detail used by CPython but not
>> > [implementations built on runtimes designed for corporate-herd-oriented
>> > languages, like] IronPython or Jython.
>>
>> I re
On Wed, 17 Jun 2009 17:52:30 +1200, Lawrence D'Oliveiro wrote:
> In message ,
> Steven D'Aprano wrote:
>
>> On Tue, 16 Jun 2009 16:45:43 +1200, Lawrence D'Oliveiro wrote:
>>
>>> In message , Piet van Oostrum wrote:
>>>
The exact time of the destruction of objects is an implementation
Lawrence D'Oliveiro writes:
> > Reference counting is an implementation detail used by CPython but not
> > [implementations built on runtimes designed for corporate-herd-oriented
> > languages, like] IronPython or Jython.
>
> I rest my case.
You're really being pretty ignorant. I don't know of
In message , Steven
D'Aprano wrote:
> On Tue, 16 Jun 2009 16:45:43 +1200, Lawrence D'Oliveiro wrote:
>
>> In message , Piet van Oostrum wrote:
>>
>>> The exact time of the destruction of objects is an implementation
>>> detail and should not be relied upon.
>>
>> That may be true in Java and o
On Tue, 16 Jun 2009 16:45:43 +1200, Lawrence D'Oliveiro wrote:
> In message , Piet van Oostrum wrote:
>
>> The exact time of the destruction of objects is an implementation
>> detail and should not be relied upon.
>
> That may be true in Java and other corporate-herd-oriented languages,
> but we
In message , Piet van Oostrum wrote:
> The exact time of the destruction of objects is an implementation detail
> and should not be relied upon.
That may be true in Java and other corporate-herd-oriented languages, but we
know that dynamic languages like Perl and Python make heavy use of
refere
On Fri, 12 Jun 2009 18:33:13 -0400
Nikolaus Rath wrote:
> Nikolaus Rath writes:
> > Hi,
> >
> > Please consider this example:
> []
>
> I think I managed to narrow down the problem a bit. It seems that when
> a function returns normally, its local variables are immediately
> destroyed. Howev
In article <873aa5m6ae@vostro.rath.org>,
Nikolaus Rath wrote:
>
>I think I managed to narrow down the problem a bit. It seems that when
>a function returns normally, its local variables are immediately
>destroyed. However, if the function is left due to an exception, the
>local variables rema
> Nikolaus Rath (NR) wrote:
>NR> Is there a way to have the obj variable (that is created in dostuff())
>NR> destroyed earlier than at the end of the program? As you can see, I
>NR> already tried to explicitly call the garbage collector, but this does
>NR> not help.
The exact time of the des
Nikolaus Rath writes:
> Hi,
>
> Please consider this example:
[]
I think I managed to narrow down the problem a bit. It seems that when
a function returns normally, its local variables are immediately
destroyed. However, if the function is left due to an exception, the
local variables remain
17 matches
Mail list logo
