Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> Alex Martelli wrote:
> > Tomasz Zielonka <[EMAIL PROTECTED]> wrote:
> >
> >> Alex Martelli wrote:
> >> > Having to give functions a name places no "ceiling on expressiveness",
> >> > any more than, say, having to give _macros_ a name.
> >>
> >> And what about having to give numbers a name?
> >
> > Excellent style, in most cases; I believe most sensible coding guides
> > recommend it for most numbers -- cfr
> ><http://en.wikipedia.org/wiki/Magic_number_(programming)> , section
> > "magic numbers in code".
>
> I was a bit unclear. I didn't mean constants (I agree with you on
> magic numbers), but results of computations, for example
Ah, good that we agree on _some_thing;-)
>
> (x * 2) + (y * 3)
>
> Here (x * 2), (y * 3) and (x * 2) + 3 are anonymous numbers ;-)
>
> Would you like if you were forced to write it this way:
>
> a = x * 2
> b = y * 3
> c = a * b
>
> ?
>
> Thanks for your answers to my questions.
I do not think there would be added value in having to name every
intermediate result (as opposed to the starting "constants", about which
we agree); it just "spreads things out". Fortunately, Python imposes no
such constraints on any type -- once you've written out the starting
"constants" (be they functions, numbers, classes, whatever), which may
require naming (either language-enforced, or just by good style),
instances of each type can be treated in perfectly analogous ways (e.g.,
calling callables that operate on them and return other instances) with
no need to name the intermediate results.
The Function type, by design choice, does not support any overloaded
operators, so the analogy of your example above (if x and y were
functions) would be using named higher-order-functions (or other
callables, of course), e.g.:
add_funcs( times_num(x, 2), times_num(y, 3) )
whatever HOF's add and times were doing, e.g.
def add_funcs(*fs):
def result(*a):
return sum(f(*a) for f in fs)
return result
def times_num(f, k):
def result(*a):
return k * f(*a)
return result
or, add polymorphism to taste, if you want to be able to use (e.g.) the
same named HOF to add a mix of functions and constants -- a side issue
that's quite separate from having or not having a name, but rather
connected with how wise it is to overload a single name for many
purposes (PEAK implements generic-functions and multimethods, and it or
something like it is scheduled for addition to Python 3.0; Python 2.*
has no built-in way to add such arbitrary overloads, and multi-dispatch
in particular, so you need to add a framework such as PEAK for that).
Alex
--
http://mail.python.org/mailman/listinfo/python-list
