Howdy!,
 
first off lets move beyond my comprehension of dynamic-languages.  Ive been writing python code for years and am a developer of an open source jython application.  I had better get 'it' or Im in deep trouble. :D
 
My focus is on a critique of the python closure.  I am arguing that closures in python contain a non-obvious behavior that can lead to memory bugs in specific situations.  The situations arise when the class generating method gets called alot.  This damages the utility of closures, saving it only for methods that get called a small amount of times.  I can not use closures from methods that get called 6,000 times because the memory footprint expands too much from all the reflective machinery that gets created.  From my observations, the classes generated never go away.  In situations where the class is identical to all the other classes the closure generator has produced, it should reuse the previous class.  This would expand the utility of the class beyond fringe use cases.
 
Thats my 2 cents on it, or 3. :)
leouser
 


Kent Johnson <kent37@tds.net> wrote:
Maybe I was a little harsh last night...the point is, your example is just a function that computes an intermediate result and returns a value depending on that result. Python doesn't treat the function or any of the results as special. Doing what you ask for would be technically difficult - how do you know the classes are the same? They can be modified in very creative ways before or after use - and would lead to subtle surprises as well.

I suspect you are coming from a background in a static language like Java. Dynamic languages are different, you need to grok the difference, not fight it.

Kent

Kent Johnson wrote:
> Leo User wrote:
>
>> interestingly enough in python comparing a 2 classes/closures returned
>> from a method returns False but in Jython its True. ???
>>
>> I find the use case of having a method returning a unique class when
>> it really is the same class in essence, dubious at best.
>
>
> That's because you still don't understand. 'class' is an executable
> statement, not a declaration. It's not the same class, it's another
> class with the same behaviour.
>
> What about this function:
> def makeList():
> return [1, 2, 3]
>
> Should it always return the same list? Should the list be cached to
> ensure this? Isn't it always the same list 'in essence'?
>
> If I say
> a = makeList()
> b = makeList()
> should a and b be the same list? If I then
> a.append(4)
> what should the value of b be?
>
> Do you still think a and b should be the same list? If not, what makes
> the class different? Classes are every bit as mutable as lists.
>
> It took me a long
>
>> time and looking at the code to see what was happening. I dont know
>> of other languages that would do this, its an unusual spin on an
>> unusual structure. I suspect there may be other 'victims' out there
>> just waiting to stumble upon this. :D
>
>
> I suspect you will find similar behaviour in other dynamic languages
> such as Ruby and Lisp.
>
> I do wonder implementation wise, is it
>
>> possible to cache the first generated class and just reuse that each
>> time a closure is used? If so, why not do that?
>
>
> Because it will lead to unexpected behaviour just like in the list case.
>
> You still haven't given your use case or said why you can't use one of
> my suggestions below.
>
> Kent
>
>>
>> leouser :)
>>
>>
>> */Kent Johnson /* wrote:
>>
>> Leo User wrote:
>> > Howdy,
>> >
>> > ok to the point, in jython-a0 I ran into the strangest behavior
>> when I
>> > was developing jyleo. I had a method that wrapped a position
>> iterator
>> > with a java.util.Iterator. This was all fine. But when I wrote
>> out a
>> > leo file the memory increased by 6%, each time!. I could not
>> fathom
>> > what was going on and had to instrument the jython implementation
>> to get
>> > visibility. What I found was somewhat startling, a new class was
>> > generated each time the method was called.
>> >
>> > so a seemingly harmless method/closure like this:
>> > def example():
>> > ...class example_closure:
>> > ......pass
>> > ...return example_closure()
>> >
>> > ended up eating up alot of memory. For methods that get called
>> alot
>> > this cant be used. For those that called a little its ok. But I
>> must
>> > ask, does anyone think this is normal behavior? We debated this
>> on the
>> > Leo forums and Edward Ream pointed out that class is an executable
>> > statement, hence generating a new class each time was correct. I
>> still
>> > find myself debating the utility of such a mechanism, I find
>> myself
>> > saying "Jython Closures Considered Harmful".
>>
>> I would have to agree with Edward - class is an executable
>> statement. CPython has the same behavior:
>> >>> def example():
>> ... class example_closure:
>> ... pass
>> ... return example_closure()
>> ...
>> >>> a=example()
>> >>> a.__class__
>>
>> >>> b=example()
>> >>> b.__class__
>>
>>
>>
>> If the nested class doesn't actually need the closure then just pull
>> it out of the def:
>> class example_closure:
>> pass
>> def example():
>> return example_closure()
>>
>> Alternately you could pass the relevant part of the closure to the
>> example_closure() constructor:
>> class example_closure:
>> def __init__(self, state):
>> self.state = state
>> def example(state):
>> return example_closure(state)
>>
>> Kent
>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is sponsored by: Discover Easy Linux Migration
>> Strategies
>> from IBM. Find simple to follow Roadmaps, straightforward articles,
>> informative Webcasts and more! Get everything you need to get up to
>> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
>> _______________________________________________
>> Jython-dev mailing list
>> Jython-dev@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/jython-dev
>>
>> ------------------------------------------------------------------------
>> Start your day with Yahoo! - make it your home page
>>
>
>
>
>
> -------------------------------------------------------
> SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
> from IBM. Find simple to follow Roadmaps, straightforward articles,
> informative Webcasts and more! Get everything you need to get up to
> speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
> _______________________________________________
> Jython-dev mailing list
> Jython-dev@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jython-dev
>



-------------------------------------------------------
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click
_______________________________________________
Jython-dev mailing list
Jython-dev@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jython-dev


Start your day with Yahoo! - make it your home page