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
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
_
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
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
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
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
> -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
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
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
>
> 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
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
> -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 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
Hello there.
Consider this code:
def factorial(n):
def helper(n):
if n:
return n*helper(n-1)
else:
return 1
r
14 matches
Mail list logo
