Re: [Eug-lug]solution to python puzzle

2002-10-10 Thread Horst Lueck
Adding a feature (static data) to a language that doesn't really support it may alway be a bit of hack (unfortunately, python doesn't have neither static nor private qualifiers )-: Wasn't one problem to keep the global namespace clean, and to prevent the garbage collector from cleaning up the

Re: [Eug-lug]solution to python puzzle

2002-10-06 Thread Sean Reifschneider
On Fri, Oct 04, 2002 at 08:41:42AM -0700, Bob Miller wrote: Those of you who were at the clinic last night know that I was asking for help on a weird limitation of Python. The problem: Consider the function, foo(), in this C program. I don't fully understand your objection to making a callable

Re: [Eug-lug]solution to python puzzle

2002-10-06 Thread Bob Miller
Sean Reifschneider wrote: I don't fully understand your objection to making a callable class, as that's probably how I'd do it. I guess I'm just surprised to find something that's simple and idiomatic in C but doesn't translate to anything equally simple in Python. Have you looked at Paul

Re: [Eug-lug]solution to python puzzle

2002-10-05 Thread joseph toman
Bob Miller wrote: As for the indentation is block structure part of Python, I disagree with toman. That's one of the best things about Python, and I'm amazed that it took so long for someone to try it. Otherwise, you're constantly checking that your indentation matches your curlies. I've

[Eug-lug]solution to python puzzle

2002-10-04 Thread Bob Miller
Those of you who were at the clinic last night know that I was asking for help on a weird limitation of Python. The problem: Consider the function, foo(), in this C program. #include stdio.h int foo() { static int n = 0; return ++n; }

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread Ralph Zeller
There's an analysis of the topic at developerworks: http://www-106.ibm.com/developerworks/linux/library/l-pycon?t=grl,l=252,p=iterators On (10/04/02 08:41), Bob Miller wrote: Those of you who were at the clinic last night know that I was asking for help on a weird limitation of Python. The

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread toman
Bob Miller wrote: Those of you who were at the clinic last night know that I was asking for help on a weird limitation of Python. The problem: Consider the function, foo(), in this C program. #include stdio.h int foo() { static int n = 0;

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread Bob Miller
toman wrote: I don't know offhand, but I would look at generators in python 2.x . Ralph suggested generators too. A generator would work, but the generator function doesn't do what I want itself, it returns an object that does what I want. I.e., instead of saying, print foo(), foo()

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread toman
Bob Miller wrote: toman wrote: I don't know offhand, but I would look at generators in python 2.x . Ralph suggested generators too. A generator would work, but the generator function doesn't do what I want itself, it returns an object that does what I want. I.e., instead of

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread Bob Miller
Larry Price wrote: : return statements that aren't on either the top or the innermost level of a function are a sign of trouble. Now that's a weird one. So this code, e.g., is a sign of trouble? class StatSample: # ... def variance(self): if len(self) == 0:

Re: [Eug-lug]solution to python puzzle

2002-10-04 Thread Larry Price
On Fri, 4 Oct 2002, Bob Miller wrote: Larry Price wrote: : return statements that aren't on either the top or the innermost level of a function are a sign of trouble. Now that's a weird one. So this code, e.g., is a sign of trouble? class StatSample: # ... def