reduce() anomaly?

[Alex Martelli]

Re: Python's simplicity philosophy

eichin@metacart a.com wrote:
...[color=blue]
> that kind of array handling. But the point here is that "reduce" is
> fundamental: x/i5 (where x is multiplication-sign and i is iota) is
> a lot like reduce(int.__mu l__, range(1,6)), it's just "readable" if[/color]

I disagree about "is a lot like" -- I think Numeric Python's

mul.reduce(arra yrange(1, 6))

is much closer to APL (sure, spelling "iota 5" as "arrayrange (1, 6)"
may be alien, but the point is that .reduce in Numeric, like / in APL,
is a property of OPERATORS [ufuncs, in Numeric], NOT a generic FP
tool like Python's built-in reduce).
[color=blue]
> of poking around.) On the other hand, that readability does assume
> you're thinking in terms of throwing arrays around, which can be
> an... *odd* way of looking at things, though of course when it fits,
> it's very nice.[/color]

That's the reason I'm happier to have it in a separate package, be
it Numeric or its successor numarray, than built into the language --
just like, e.g., regular expressions are a separate module in Python
but built into languages such as Perl or Ruby. Keeping the core
language simpler and other modules/packages rich is a strategy which
I think Python uses to excellent effect.


Alex

[Alex Martelli]

Re: Python's simplicity philosophy

Robin Becker wrote:
...[color=blue]
> on oop in this thread nobody has pointed out that we could have
>
> sequence.sum()
> sequence.reduce (operator.add[,init])
>
> or even
>
> sequence.filter (func) etc etc
>
> and similar. That would make these frighteningly incomprehensibl e ;)
> concepts seem less like functional programming. Personally I wouldn't
> like that to happen.[/color]

Maybe nobody "pointed it out" because it's utterly absurd to even
conceive of somehow magically adding all of those methods to *EVERY*
iterator under heavens?! E.g., today, this works just fine:
[color=blue][color=green][color=darkred]
>>> class BAH(object):[/color][/color][/color]
.... def __init__(self): self.seq = [1, 5, 3, 7, 19]
.... def __iter__(self): return self
.... def next(self):
.... try: return self.seq.pop()
.... except IndexError: raise StopIteration
....[color=blue][color=green][color=darkred]
>>> sum(BAH())[/color][/color][/color]
35

having instances of class BAH automagically spout such methods as
..sum(), etc, would be an absurdity.

Numeric's design -- considering that *functions* able to do .reduce
and the like are very special and should expose those as methods
(they're known as "ufuncs" in Numeric), taking the array as argument,
is a design which looks quite sound to me. So, for example,
Numeric.sum(x, axis) boils down (after some error checks &c) to
Numeric.add.red uce(x, axis) [summing, of course, IS by far important
enough that having to spell it out as add.reduce would be silly].


Alex

[Alex Martelli]

Re: Python's simplicity philosophy

Douglas Alan wrote:
...[color=blue]
> How's that? I've never used a programming language that has sum() in
> it. (Or at least not that I was aware of.) In fact, the *Python* I
> use doesn't even have sum() in it! I've used a number of languages[/color]

Never used a modern Fortran? Or never bothered to _learn_ it properly
"because it's a language for peasants"?-)
[color=blue]
> that have reduce(). If I didn't already know that it exists, I
> wouldn't even think to look in the manual for a function that adds up
> a sequence of numbers, since such a function is so uncommon and
> special-purpose.[/color]

Right -- that's why the Fortran standard committee bothered to include
it, the Numeric Python designers bothered to define sum specifically
as an alias for add.reduce, and so on -- because it's so uncommon.

Indeed, that's why 'sum' is a commonly used word in English -- exactly
because nobody's every DOING anything like that -- while, of course,
'reduce' is totally obvious -- why, _anybody_ who's ever taken
Chemistry 101 knows it means "to remove oxygen"!


Alex

[David Eppstein]

Re: Python's simplicity philosophy

In article <9s8tb.22141$9_ .810000@news1.t in.it>,
Alex Martelli <aleax@aleax.it > wrote:
[color=blue][color=green]
> > How's that? I've never used a programming language that has sum() in
> > it. (Or at least not that I was aware of.) In fact, the *Python* I
> > use doesn't even have sum() in it! I've used a number of languages[/color]
>
> Never used a modern Fortran? Or never bothered to _learn_ it properly
> "because it's a language for peasants"?-)[/color]

For that matter, Haskell, the third thing I get from googling
"functional programming language", has had sum since it was first
created (version 1.0 report 1990), despite its being easily replaceable
with reduce (or I guess in Haskell terms foldl).

--
David Eppstein http://www.ics.uci.edu/~eppstein/
Univ. of California, Irvine, School of Information & Computer Science

[Alex Martelli]

Re: Python's simplicity philosophy

Douglas Alan wrote:
...[color=blue]
> Well, that's the argument you seem to be making -- that reduce() is
> superfluous because a sum() and max() that work on sequences were
> added to the language.[/color]

"added"? 'max' worked that way since well before I met Python. But
to be consistent with your other arguments, no doubt you'd argue for
a .sort() followed by [-1] as "more general" than max...

[color=blue][color=green][color=darkred]
>>> I can already see what's going to happen with sum(): Ultimately,
>>> people will realize that they may want to perform more general types
>>> of sums, using alternate addition operations.[/color][/color]
>[color=green]
>> Not gonna happen - this _might_ happen if Python was a
>> design-by-committee language, but it's not.[/color]
>
> According to Alex Martelli, max() and min() are likely to be extended
> in this fashion. Why not sum() next?[/color]

I was just presenting my personal opinion regarding the fact that
the max and min functions should have an optional key= argument,
simply because the .sort method now (2.4) has one too. If I implied
that anything I feel should be done is automatically "likely" to be
accepted by Guido, I apologize for mis-communicating; he throws stones
at far more of my ideas than he embraces.

[color=blue][color=green]
>> To you, perhaps. Not me, and not a lot of other people.[/color]
>
> Well, perhaps you can explain your confusion to me? What could
> possibly be unintuitive about a function that is just like sum(), yet
> it allows you to specify the addition operation that you want to use?[/color]

Addition, as you have remarked elsewhere, is intrinsically suitable
for being applied to multiple operands; one is therefore naturally
disposed to think in terms of "add them all up", "sum them all", and
the like, NOT in terms of "iterativel y perform
total = operator.add(to tal, item)
for all items in the sequence of numbers". But, reduce as it exists
in Python today cannot be clearly defined EXCEPT by such an iteration
with some generic "callable which accepts two arguments" specified
in lieu of the operator.add. Given this total generality, even though
hardly ever does it make sense to USE it, reduce becomes quite complex.

You've even argued in this thread, incorrectly, that reduce could be
eliminated if only all binary operators were able to accept arbitrary
numbers of arguments. This, plus your insistence that 'reduce' is
"just like" APL's / (which does NOT accept arbitrary functions on its
left -- just specific operators such as +), indicate a _misconception_
of reduce on your part. I'm sure you don't hold it consciously, but
these miscommunicatio ns indicate that even you, reduce's paladin, do
NOT properly grasp reduce "intuitivel y".

Having (e.g.) add accept a sequence argument (like max does), or, for
explicitness and potentially performance, grow an add.reduce attribute
just like in Numeric, would give no particular problems. I'd still
want (just like Numeric does) to have sum as a name for add.reduce,
because it's by far the most common case and avoids getting into the
issue of what the (expletive delete) does "reducing" have to do with
anything that "add.reduce " does (it's really a curve ball compared
with the many meanings of "reduce" in English, after all). But, most
importantly, such a design would avoid the veritable traps to which
the current, too-general 'reduce' subjects the poor learner who's
quite reasonably going to believe that all that generality MUST be
good for something if it's been designed into a built-in. We've seen
quite a few such inappropriate uses on this thread, after all.

As I said, I'm not particularly good at guessing what Guido will or
won't bless, but I suspect that a patch to the operator module to
grow appropriate attributes on its functions, or even just make them
accept multiple arguments, might be well-received (to avoid wasting
work one might want a PEP or prePEP about that first, of course).

[color=blue]
> Of course, you can get the same effect by defining a class with your
> own special __add__ operator, and then encapsulating all the objects
> you want to add in this new class, and then using sum(), but that's a
> rather high overhead way to accomplish the same thing that reduce()
> lets you do very easily.[/color]

In practice, I judge it quite unlikely that people will go out of their
way to abuse sum as I've seen them abuse reduce -- reduce lets you
abuse it very easily, as you mention, while sum needs you to really
jump through hoops to do so.


Alex

[Dang Griffith]

Re: Python's simplicity philosophy

On Wed, 12 Nov 2003 13:19:15 -0500, Douglas Alan <nessus@mit.edu >
wrote:
[color=blue]
>I would say that if you didn't get introduced to at least the concept
>of functional programming and a hint of how it works, then something
>was seriously wrong with your CS education.
>|>oug[/color]

I've been lurking this thread for a while, but missed the beginning.
Can I ask where you got your CS education (school and year)?
From the conversation, it seems that right or wrong, your education
exceeds those in this group. Where should I send my children
such that they receive a better CS education that I?
--dang

[Terry Reedy]

Re: Python's simplicity philosophy


"Douglas Alan" <nessus@mit.edu > wrote in message
news:lcvfpn46f6 .fsf@gaffa.mit. edu...[color=blue][color=green]
> > Even without any algebra, any kid can tell you that 1 + 2 is the[/color][/color]
same[color=blue][color=green]
> > as 2 + 1. Replace 1 and 2 by a and b and you get the same result.[/color]
>
> Yes, but they are still two *different* ways to to get to that[/color]
result.[color=blue]
> Starting with a and adding b to it, is not the same thing as[/color]
starting[color=blue]
> with b and adding a to it.[/color]

I disagree. Number addition (like several other functions) is a bag
(multiset) reduction operator that reduces a (possibly empty)
collection of similar items to one of the same type. Abstractly, the
reduction is simultaneous. One appropriate notation for such
operators is a simple labelled loop (in 2D) containing the items to be
collected together. In linear text, such loops can be represented by
matched symbols, such as ( ), [ ], { }, which then represent the
intersection of a closed loop with a 'too-narrow' text band (which
thereby chops off the top and bottom of the loop). When operands
scattered in the loop interior are projected down to a 1+D band for
text representation, they gain an ordering that is an artifact of that
limited representation.

(+ item item ...) and sum(item, item, ...) are both labelled loops
with items arbitrarily but necessarily ordered for linear text
representation.
[color=blue]
> It is only the commutative law of arithmetic,
> as any good second grade student can tell you,
> that guarantees that the result will be the same.[/color]

Well, second graders are mislead by the representation of an n-ary bag
operation with infix notation that implies binarity and order
relevance. Learning about reduce should help one unlearn these
implications ;-).

Even with infix notation, there is a choice between making the default
interpretation be order relevance or order irrelavance. If
mathematicians had made the second choice, therr would be no need for
a 'commutative law' One would say that a+b == b+a because that is the
way it normally is, while a-b != b-a because of the OrderRelevance Law
of subtraction.

< On the other hand, not all mathematical groups are albelian,
< and consequently, a + b != b + a for all mathematical groups.

Yes, there are order-relevant binary-only operations. Number addition
is not one of them.

[Having written the above, I am less enthralled with the overloading
of '+' and operator.add to also mean ordered concatenation of
sequences. The fact that operator.add becomes O(n**2) (usually
unnecessarily) instead of O(n) for such overloadings, to the point
that sum() specially excludes such overloadings for strings,
reinforces this doubt. Perhaps there should be at least be an
operator.cat that would generalize ''.join(strseq)]

Terry J. Reedy

[Alex Martelli]

Re: Python's simplicity philosophy

Douglas Alan wrote:
[color=blue]
> Alex Martelli <aleax@aleax.it > writes:
>[color=green][color=darkred]
>>> no disagreement, reduce is in line with that philosophy sum is a
>>> shortcut and as others have said is less general.[/color][/color]
>[color=green]
>> 'sum' is _way simpler_: _everybody_ understands what it means to sum a
>> bunch of numbers, _without_ necessarily having studied computer science.[/color]
>
> Your claim is silly. sum() is not *way* simpler than reduce(), and
> anyone can be explained reduce() in 10 seconds: "reduce() is just like[/color]

As you hedged elsewhere, anyone can be EXPLAINED it, but not anyone
will UNDERSTAND the explanation instantly. Now THAT hedging is way
silly, and of course Shakespeare did it best:

"""
Glendower: I can call spirits from the vasty deep.

Hotspur: Why, so can I, or so can any man; But will they come when you do
call for them?
"""
[color=blue]
> sum(), only with reduce() you can specify whatever addition function
> you would like."[/color]

This explanation is misleading by overqualificati on (that "addition" is
the overqualificati on). A non-overqualified explanation would have to
mention that ANY callable that can accept two arguments, and return a
result suitable to be its first argument next, can be passed; and it would
have to touch on what happens when the sequence is empty, and the optional
third argument. Yes, you COULD cram it into 10 seconds -- people won't
UNDERSTAND what you're saying, of course, but clearly you don't care
about such trifles, as you have abundantly shown.

[color=blue][color=green]
>> The claim, made by somebody else, that _every_ CS 101 course teaches the
>> functionality of 'reduce' is not just false, but utterly absurd:
>> 'reduce', 'foldl', and similar higher-order functions, were not taught to
>> me back when _I_ took my first university exam in CS [it used Fortran as
>> te main language],[/color]
>
> Then you weren't taught Computer Science -- you were taught Fortran
> programming. Computer Science teaches general concepts, not specific
> languages.[/color]

CS teaches general concepts and in all decent CS 101 course it starts
doing so with concrete examples (because THAT is how most people learn
best), ideally with an executable computer language so you can TRY things.
It is quite likely that higher-order functions won't be taught yet in
CS 101, or that only a very few specific cases will be shown and reduce
(or foldr or however you want to call it) will not be one of them.

Your false and utterly absurd claim about the content of _every_ CS 101
course has been totally demolished by now -- by many people, including
CS majors. I'm sure you'd be happy to "undo" it, but you've invested
so much emotional energy on it and made it a lynchpin of your argument
in favour of 'reduce' that I understand that's just too hard. Still,
by standing on such rotten foundations, your argument is reduced (heh)
to near-absurdity...

[color=blue][color=green]
>> they were not taught to my son in _his_ equivalent course [it used
>> Pascal], and are not going to be taught to my daughter in _her_
>> equivalent course [it uses C].[/color]
>
> Then your children were done a great diservice by receiving a poor
> education. (Assuming that is that they wanted to learn Computer
> Science, and not Programming in Pascal or Programming in C.)[/color]

They wanted to learn enough computer science to get on with their
real interests in life -- telecom engineering and financial economics
respectively. They may well take second or third courses on CS issues
in the future. But within the confines of a Bachelor (3-years degree)
in such disciplines, heavily different from computer science but able to
use several CS conceptual and practical tools effectively for other
purposes, I think they were served perfectly well by "Foundation s
of Informatics" (aka CS 101 -- we don't number things like that here,
and "Informatic s" is strongly preferred over "CS", and in particular
it's the preference of local computer scientists) covering a lot of
important concepts AND practical exercises, but not ALL higher-order
functions. Personally I think that they wasted effort in teaching
about pointers, but I guess that's debatable.

[color=blue][color=green]
>> Python's purpose is not, and has never been, to maximize the generality
>> of the constructs it offers.[/color]
>
> Whoever said anything about "maximizing generality"? If one's mantra[/color]

Your only argument FOR reduce is its maximal generality (and the falsehood
that it's taught in every CS 101 course).
[color=blue]
> elegant features understood by anyone who has studied Computer Science[/color]

If a CS 101 course (passed with top marks) counts as having "studied
Computer Science", then 'reduce' is not such a feature. It's not very
elegant either, btw, but that's a subjective opinion -- the fact that
CS 101 courses mostly do NOT teach reduce/foldl is a FACT. So, by
this reasoning of yours, but based on realities rather than falsehoods,
reduce should go away.
[color=blue]
> *utterly* wrong manner. You should be assuming that your audience are
> the smart people that they are, rather than the idiots you are
> assuming them to be.[/color]

They're smart _and pragmatical_, NOT interested in (very arguable...)
elegance _for its own sake_, for the most part. So, they ask for GOOD
use cases for reduce, if they're taught it -- and... none can be found
throughout the Standard Python library and everywhere else I've checked
into real programs (written by me or my clients, or downloaded from
the net). Every single use of reduce I've found would be faster,
cleaner, simpler with sum, an explicit loop, or other ways yet.

[color=blue][color=green]
>> Keep the language small and simple.[/color]
>[color=green]
>> Provide only one way to do an operation.[/color]
>
> It is not true these principles are rare among computer languages --
> they are quite common. Most such language (like most computer
> languages in general) just never obtained any wide usage.[/color]

URLs please (or non-URL references if you must). I had never seen
these two principles written down for a general-purpose language
before I met C -- and haven't, since, except for Python. I'll be
quite interested in being able to quote other languages explicitly
adopting them as design criteria.

[color=blue]
> place at the right time, it had a lightweight implementation, was[/color]

The lightweight implementation clearly follows from the two
principles above -- C had very-lightweight, fast, portable
compilers early on for just the same reason.


Alex

[Emile van Sebille]

Re: Python's simplicity philosophy

Alex Martelli:[color=blue]
> ... no doubt you'd argue for
> a .sort() followed by [-1] as "more general" than max...
>
>[/color]

Well, you must admit that writing pentultimate(a) has it all over
a.sorted()[-2] ;-)

--

Emile van Sebille
emile@fenx.com

[Dang Griffith]

Re: Python's simplicity philosophy

On Fri, 14 Nov 2003 18:07:44 GMT, Dang Griffith
<noemail@noemai l4u.com> wrote:
[color=blue]
>On Wed, 12 Nov 2003 13:19:15 -0500, Douglas Alan <nessus@mit.edu >
>wrote:
>[color=green]
>>I would say that if you didn't get introduced to at least the concept
>>of functional programming and a hint of how it works, then something
>>was seriously wrong with your CS education.
>>|>oug[/color]
>
>I've been lurking this thread for a while, but missed the beginning.
>Can I ask where you got your CS education (school and year)?
>From the conversation, it seems that right or wrong, your education
>exceeds those in this group. Where should I send my children
>such that they receive a better CS education that I?
> --dang[/color]
Nevermind--I saw more posts and summarily reached a conclusion,
reducing the alternatives to one.
--dang

[Terry Reedy]

Re: Python's simplicity philosophy


"Alex Martelli" <aleax@aleax.it > wrote in message
news:WQ1tb.1972 6$9_.707480@new s1.tin.it...[color=blue]
> Terry Reedy wrote:[color=green]
> > If the builtins are reduced in 3.0, as I generally would like, I[/color][/color]
would[color=blue][color=green]
> > be fine with moving apply, map, filter, and a repaired version of
> > reduce to a 'fun'ctional or hof module. But the argument of some
> > seems to be that this batteries-included language should[/color][/color]
specifically[color=blue][color=green]
> > exclude even that.[/color]
>
> A functional module would be neat.[/color]

Good. I wrongly thought you might be in the abolish camp.
[color=blue]
> A great way to enhance the chance that there will be one
> would be starting one today (e.g. on sourceforge),
> ideally with both pure-Python and C-helped (or pyrex, etc)
> implementations ,
> and get it reasonably-widely used, debugged, optimized.[/color]

Interesting idea. Maybe I will do something with it.
[color=blue]
> Also, I advocate that 3.0 should have a module or package (call it
> "legacy" for example) such that, if you started your program with
> some statement such as:
>
> from legacy import *
>
> compatibility with Python 2.4 or thereabouts would be repaired as
> much as feasible, to ease running legacy code, and to the expense
> of performance, 'neatness' and all such other great things if needed
> (e.g., no "repaired" versions or anything -- just compatibility).[/color]

Running old code in new interpreters seems not to be much of a problem
yet because of the current policy of not deleting features or (with
pretty minor or obscure exceptions) changing semantics. But if any
deprecations take effect before 3.0, legacy could also be added
before.

I think there should also be an official 'retroxy' module to help run
(a feasible subset of) pythonx.y code in older interpreters. A
retro23 module would define True, False, sum, enumerate and perhaps
other stuff. Accompanying instructions could discuss which older
versions a new module like sets will work with. I am sure this has
been invented privately several times.
[color=blue]
> One reasonably popular counterproposal to that was to have it as
>
> from __past__ import *
>
> by analogy with today's "from __future__".[/color]

which Guido has strongly rejected since it would mean keeping old
stuff in the interpreter forever -- unless it were a synonym for
'import legacy' -- in which case your spelling is better.
[color=blue]
> I'd also like to make it
> easy to get this functionality with a commandline switch, like is
> the case today with -Q specifically for _division_ legacy issues.[/color]

-L to mean 'import legacy' on startup should be possible.
[color=blue]
> But mostly, each time I mention that on python-dev, I'm rebuffed[/color]
with[color=blue]
> remarks about such issues being way premature today. Somebody's
> proposed starting a new list specifically about 3.0, to make sure
> remarks and suggestions for it made today are not lost about more
> day-to-day python-dev traffic, but I don't think anything's been
> done about that yet.[/color]

Perhaps Guido is trying to avoid pressure to start before he and the
PSF are ready.

I personally wish 3.0 were out now or the next release. That is what
I more or less expected 2+ years ago when I suggested that the
division switch be delayed until 3.0 -- or rather, suggested that the
first release after 2 years make the switch *and* be called 3.0. I
was not asking to have to import the new division rules for years and
years;-).

Terry

[Thomas Heller]

Re: Python's simplicity philosophy

Alex Martelli <aleax@aleax.it > writes:
[color=blue]
> Terry Reedy wrote:
> ...[color=green][color=darkred]
>>> personally argued that reduce() should be removed from the language,
>>> but I do agree that it does not have to be part of "core" Python,
>>> and could easily be relegated to a module.)[/color]
>>
>> If the builtins are reduced in 3.0, as I generally would like, I would
>> be fine with moving apply, map, filter, and a repaired version of
>> reduce to a 'fun'ctional or hof module. But the argument of some
>> seems to be that this batteries-included language should specifically
>> exclude even that.[/color]
>
> A functional module would be neat. A great way to enhance the chance
> that there will be one would be starting one today (e.g. on sourceforge),
> ideally with both pure-Python and C-helped (or pyrex, etc) implementations ,
> and get it reasonably-widely used, debugged, optimized.[/color]

I would suggest: don't move the implementation to C too fast or too much
of the code. With pypy on the horizon, this may never be needed (?).

Thomas

[Terry Reedy]

Re: Too much builtins (was Re: Python's simplicity philosophy


"Alex Martelli" <aleax@aleax.it > wrote in message
news:IT6tb.2744 5$hV.1005380@ne ws2.tin.it...[color=blue]
> I'd rather put map/filter/reduce in a 'legacy' module -- warts and
> all, e.g. map's horrible habit of None-padding shorter sequences,
> EEK -- and have a designed-from-scratch functional module without
> the warts.[/color]

What a liberating thought. I sometimes forget that the only thing I
am really stuck with when programming in Python is the core syntax (in
the Ref Manual) and that I am free to wrap or replace anything else
(in the Lib Manual). For a project I hope to start soon, I have been
worried about how to work around or explain away the deficiencies of
Python's of reduce(). Instead, I should just write the version I want
for my purposes (especially since speed does not matter). So your
voluminous writing on this has benefited at least one person.
[color=blue]
> Probably, yes. What functions, as opposed to types, do you
> think should absolutely be in the builtins rather than in a separate
> module, and (unless it's obvious) why?[/color]

I have thought some about this also. Type objects could be put/left
in types, but as constructors, they are too useful and basic not to
have immediately available (unless builtins was reduced to nearly
nothing).
[color=blue]
> Of course __import__ had better stay or we won't
> be able to get anything imported, for example:-).[/color]

Does it have to be in builtins for import statements to work?
Direct use of __import__ seems relatively rare.
[color=blue]
> The attribute-related functions hasattr, getattr,
> setattr, and delattr, seem very fundamental
> (but I'd want the same status for the item-functions
> currently over in operator),
> as well as
> (at least some of them -- delattr isn't -- but I do think that[/color]
trying to[color=blue]
> discriminate too finely would make things too hard to learn)
> very frequently used in code.[/color]

I had to re-lineate this to parse apart the three thoughts. A static
frequency-of-use analysis for some large code collection would be
interesting. I might write something eventually.
[color=blue]
> iter[/color]
I group this with type constructor objects, even though not one
itself[color=blue]
> len[/color]
unless made a method, keep in[color=blue]
> pow [for the crucial 3-arguments case][/color]
very specialized and rarely used? move to math as pow3[color=blue]
> range (or some preferable variant that returns an iterator)[/color]
how about iter(3), etc, currently an arg type error?
think of 3 as the sentinal value.
is not typing '0,' worth the wartiness of optional first arg?[color=blue]
> and zip seem pretty fundamental[/color]
agree except for pow

Terry J. Reedy

[Andrew Dalke]

Re: Python's simplicity philosophy

Alex:[color=blue]
> Anyway, computational scientists using Python should be using Numeric
> (if they aren't, they're sadly misguided).[/color]

Or they are like me and work in a subfield where (specialized)
database searches and graph theory is more useful. It was strange
at SciPy with all those people using NumPy and doing CFD and
our little group of computational life sciences people being rather
bored.
[color=blue]
> Indeed, that's why 'sum' is a commonly used word in English -- exactly
> because nobody's every DOING anything like that -- while, of course,
> 'reduce' is totally obvious -- why, _anybody_ who's ever taken
> Chemistry 101 knows it means "to remove oxygen"![/color]

While in Chemistry 102 they learn that it means to add electrons
and can occur in a non-oxygen environment ;)

http://reference.allrefer.com/encyclopedia/O/oxidreduc.html

Andrew
dalke@dalkescie ntific.com

[Terry Reedy]

Re: Python's simplicity philosophy


"Alex Martelli" <aleax@aleax.it > wrote in message
news:8Y7tb.2190 1$9_.802189@new s1.tin.it...[color=blue]
> Dave Brueck wrote:
> ...[color=green][color=darkred]
> >> results = [ func(x) for x in sequence ]
> >> ... instead of ...
> >> results = sequence.map(fu nc) ??[/color][/color][/color]
[color=blue][color=green]
> > Because I find the first much more readable>[/color][/color]
[color=blue]
> I entirely agree with both points.[/color]

For this pair, I like the second better. Different aesthetics.
[color=blue]
> They're even clearer when the contrast is between, e.g.:
> results = [ x+23 for x in sequence ]
> and:
> results = sequence.map(la mbda x: x+23)
> where using the HOF approach forces you
>to understand (and read) lambda too.[/color]

Here I might take the first. 'lambda' is something I feed 'stuck'
with.

Would the hypothetical
results = sequence.map(fu nc x: x+23)
be any better?
How about a very hypothetical (post ``==repr deprecation)
results = sequence..map(` x+23`)
?

Terry J. Reedy