Hello there.
Consider this code:
def factorial(n):
def helper(n):
if n:
return n*helper(n-1)
else:
return 1
r
Kristján Valur Jónsson wrote:
The problem with this is that once you have called factorial() once, you
end up with a recursive cycle. „factorial“ has become a cell object,
referencing the „helper“ function, which again refers to the outer cell
object. This requires „gc“ to clean up. Also, it
> -Original Message-
> From: Hrvoje Niksic [mailto:hrvoje.nik...@avl.com]
> Sent: 8. desember 2009 13:52
> To: Kristján Valur Jónsson
> Cc: python-dev@python.org
> Subject: Re: [Python-Dev] recursive closures - reference leak
> What problem are you referring to? Python has a gc exactly t
Kristján Valur Jónsson ccpgames.com> writes:
>
> The problem with this is that once you have called
> factorial() once, you end up with a recursive cycle.
You don't need a closure to exhibit a reference cycle. A global function is
enough:
>>> def helper(n):
... if n:
... return n*helper(n-1
>
> Ah, yes. In my particular case, I'm running a cluster of hundreds of nodes,
> supporting 50.000 players in a real-time space simulation. We disable GC
> because of its unpredictable performance impact and are careful to avoid
> reference cycles. We use gc from time to time to _find_ those
2009/12/8 Maciej Fijalkowski
> Note that disabling gc
> does not mean that you will not have unpredictable pauses. Consider
> for example that if you loose a reference to a very long chain of
> objects, you can have arbitrarily many frees being called before
> anything else can happen.
>
That st
Yes. Just –in-time releaseing of objects is much preferable to delayed release.
They tend to be in the cache, the individual runs of releases are smaller and
have less of an individual impact.
a gc.collect() cycle visits a large amount of objects that it won‘t release
causing cache thrashing.
Th
> -Original Message-
> From: python-dev-bounces+kristjan=ccpgames@python.org
> [mailto:python-dev-bounces+kristjan=ccpgames@python.org] On Behalf
> Of Antoine Pitrou
> Sent: 8. desember 2009 14:55
> To: python-dev@python.org
> Subject: Re: [Python-Dev] recursive closures - referen
Hello,
On behalf of the Distutils-SIG, I would like to propose PEP 386 for
inclusion in the sdtlib, and have a final discussion here on
Python-dev.
http://www.python.org/dev/peps/pep-0386
This PEP has been discussed for some time in Distutils-SIG, and we
agreed there that it's important to have
Tarek Ziadé wrote:
Hello,
On behalf of the Distutils-SIG, I would like to propose PEP 386 for
inclusion in the sdtlib, and have a final discussion here on
Python-dev.
http://www.python.org/dev/peps/pep-0386
Some English copy editor comments:
"and it will optionally allow to use that field"
I
Terry Reedy wrote:
Tarek Ziadé wrote:
Hello,
On behalf of the Distutils-SIG, I would like to propose PEP 386 for
inclusion in the sdtlib, and have a final discussion here on
Python-dev.
http://www.python.org/dev/peps/pep-0386
Some English copy editor comments:
"and it will optionally allow
In article
<94bdd2610912080916s2dbb79d0ub8a77295bba92...@mail.gmail.com>,
Tarek Ziad? wrote:
> http://www.python.org/dev/peps/pep-0386
It looks great to me. Very complete and easy to understand.
-- Russell
___
Python-Dev mailing list
Python-Dev@pyt
You could use a class:
class factorial():
def fac(self, n):
if n == 0:
return 1
else:
return n * self.fac(n - 1)
def __call__(self, n):
return self.fac(n)
factorial = factorial()
print factorial(5)
--
Greg
_
On Tue, Dec 8, 2009 at 8:45 PM, Terry Reedy wrote:
> Tarek Ziadé wrote:
>>
>> Hello,
>>
>> On behalf of the Distutils-SIG, I would like to propose PEP 386 for
>> inclusion in the sdtlib, and have a final discussion here on
>> Python-dev.
>>
>> http://www.python.org/dev/peps/pep-0386
>
> Some Engli
14 matches
Mail list logo
