On Fri, Jan 13, 2012 at 8:45 AM, Devin Jeanpierre <jeanpierr...@gmail.com> wrote: > On Thu, Jan 12, 2012 at 3:45 PM, Nathan Rice > <nathan.alexander.r...@gmail.com> wrote: >> I'm interested in fixing both issues. I believe both issues I've had >> could be solved by having a robust "symbolic object". These objects >> would basically usable like ordinary objects, however upon any >> attribute access or other form of interaction, the object would >> basically short circuit the calling function, and return a symbolic >> object directly to the outer scope. The symbolic object would behave >> like a generator function frozen at the point of attribute access, and >> upon send()-ing (or whatever method), it would behave exactly as if >> the values sent had been the ones passed in originally (ideally >> without consuming the generator). > > I find the way you've formalized this a bit "weird". It looks like > you're suggesting adding laziness to Python. > > If that's what you want, maybe you should try PyPy and the thunk object space:
While thunk is neat, it doesn't accomplish precisely what I'm describing in this instance. When a function starts to run under thunk, the computations take place as soon as the function gets to the object inside its scope. What I'm after is the ability to basically create functions using only expressions, in a generative manner. Lambda does accomplish this, but in an extremely clunky manner... for example: X = lambda x: x + 1 Y = lambda y: y * 2 Z = lambda z: z % 3 (or XYZ = lambda x: (((x + 1) * 2) % 3) If I want to perform a second step after this, I need create another lambda, because they don't chain/aren't generative. The thing that Elementwise does that is very appealing is that most operations are generative, so if you have an ElementwiseProxy object x, x2 = (((x + 1) * 2) % 3) basically does the same thing as the above, but you can then do x3 = x2 ** 3, and so on until you are ready to get your results. Once you have your results, you can use the same ElementwiseProxy again with different inputs. It is just a function generation technique which has some elegant properties. Having a native object type designed to facilitate this would let people do a lot of interesting things, and make things like Elementwise be a lot more "consistent". I bet you could do some really neat things by subclassing such an object as well. This is certainly not a common programming paradigm, but I think most people could reap a lot of benefits from it while being oblivious to its presence. Nathan -- http://mail.python.org/mailman/listinfo/python-list
