On 17 Dec 2005 01:16:31 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>>>from functional import curry
>
>>I'm not familiar with that module, but I wrote a byte-code-munging curry
>>as a decorator that actually modified the decorated function to eliminate
>>parameter(s) from the signature a
>>from functional import curry
>I'm not familiar with that module, but I wrote a byte-code-munging curry
>as a decorator that actually modified the decorated function to eliminate
>parameter(s) from the signature and preset the parameter values inside the
>code.
>I mention this because pure-pytho
>Note that NotImplemented is not the same as NotImplementedError -- and I
>wasn't suggesting
>raising an exception, just returning a distinguishable "True" value, so that
>a test suite (which I think you said the above was from) can test that the
>"when"
>guard logic is working vs just passing ba
On 16 Dec 2005 16:55:52 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
[...]
>When I first wrote this thing it was 3 stage construction, not 2. I
>wanted to abstract out specific tests and then JUST apply fields to
>them in the actual rules for the business code. I then figured out if I
>st
>>def lt(*fields):
>>return collect(fields, lambda x, y: x < y)
>>def gt(*fields):
>>return collect(fields, lambda x, y: x > y)
>>def gte(*fields):
>>""" gte(field, ...) -> rule
>>"""
>>return collect(fields, lambda x, y: x >= y)
>>etc...
>DRY ? ;-)
Do you mean by the doc s
>Sorry about "obfuscation contest," I just balked at the reduce code, which
>seemed
>like premature overgeneralization ;-)
It's a personal preference, but the only thing I consider premature is
optimization, not generalization. I prefer to try and capture any
concept I can as its own abstracted p
On 15 Dec 2005 18:45:17 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>Well, the the comparison operations are just a special case really.I
>don't know about the obfuscation contest. I've attempted to make an
>extensible library.
Sorry about "obfuscation contest," I just balked at the redu
Well, the the comparison operations are just a special case really.I
don't know about the obfuscation contest. I've attempted to make an
extensible library.
def lt(*fields):
return collect(fields, lambda x, y: x < y)
def gt(*fields):
return collect(fields, lambda x, y: x > y)
def gte(*fi
On 12 Dec 2005 01:23:48 -0800, "[EMAIL PROTECTED]" <[EMAIL PROTECTED]> wrote:
>Thanks for the example code. Definately provided a few different ways
>of doing the construction.
>
>Actually, the status variable was the only thing that mattered for the
>inner function. The first code post had a bug
[EMAIL PROTECTED] wrote:
> reducer does have no side effects so I suppose short-circuting it would
> be the best thing. I think the only thing about the last example is
> that it starts things off with a zero. I think that would boink it.
In that case, and assuming that fields contains at least o
On Mon, 12 Dec 2005 08:26:59 +, Steve Holden <[EMAIL PROTECTED]> wrote:
[...]
>
>The scoping rules do work when you obey them:
>
> >>> def f1(a, b):
> ... s = a+b
> ... def _(x):
> ... return s+x
> ... return _
> ...
> >>> func = f1(12, 13)
> >>> func(10)
>35
> >>>
>
>Here th
[EMAIL PROTECTED] wrote:
> Thanks for the example code. Definately provided a few different ways
> of doing the construction.
>
> Actually, the status variable was the only thing that mattered for the
> inner function. The first code post had a bug b/c I was first just
> trying to use reduce. How
[EMAIL PROTECTED] wrote:
> That does make sense. So there is no way to modify a variable in an
> outer lexical scope? Is the use of a mutable data type the only way?
>
> I'm trying to think of a case that would create semantic ambiguity when
> being able to modify a variable reference in an outer
Thanks for the example code. Definately provided a few different ways
of doing the construction.
Actually, the status variable was the only thing that mattered for the
inner function. The first code post had a bug b/c I was first just
trying to use reduce. However, I realized that the boolean red
[EMAIL PROTECTED] wrote:
> I am using python2.4 and the following code throws a "status variable"
> not found in the inner-most function, even when I try to "global" it.
>
> def collect(fields, reducer):
> def rule(record):
> status = True
> def _(x, y):
> cstat =
That does make sense. So there is no way to modify a variable in an
outer lexical scope? Is the use of a mutable data type the only way?
I'm trying to think of a case that would create semantic ambiguity when
being able to modify a variable reference in an outer scope, but I
cannot (which is proba
[EMAIL PROTECTED] wrote:
> I am not completely knowledgable about the status of lexical scoping in
> Python, but it was my understanding that this was added in a long time
> ago around python2.1-python2.2
>
> I am using python2.4 and the following code throws a "status variable"
> not found in the
Well, I think I found a nasty little hack to get around it, but I still
don't see why it doesn't work in the regular way.
def collect(fields, reducer):
def rule(record):
# Nasty hack b/c can't get lexical scoping of status to work
status = [True]
def _(x, y, s=status):
I am not completely knowledgable about the status of lexical scoping in
Python, but it was my understanding that this was added in a long time
ago around python2.1-python2.2
I am using python2.4 and the following code throws a "status variable"
not found in the inner-most function, even when I try
19 matches
Mail list logo
