On 30 Jul 2009, at 23:52 , Jan Kaliszewski wrote:
Dnia 30-07-2009 o 22:41:57 Masklinn <maskl...@masklinn.net>
napisał(a):
On 30 Jul 2009, at 22:23 , Jan Kaliszewski wrote:
30-07-2009 o 13:36:49 Masklinn <maskl...@masklinn.net> wrote:
On 30 Jul 2009, at 06:04 , alex23 wrote:
On Jul 30, 1:06 pm, r <rt8...@gmail.com> wrote:
2.) the .each method
container.each{|localVar| block}
This method can really cleanup some ugly for loops, although i
really
like the readability of for loops.
map(lambda localVar: <block>, sequence)
or:
def usefully_named_func(var):
<block>
return var
transformed = [usefully_named_func(v) for v in sequence]
The issue here is of course that `map` and comprehensions are
transformations. `#each` exists for effectful iterations (Ruby
has `#map` for the map operation). So the intent expressed by
`#each` and `map` isn't the same. Furthermore and this is the
most problematic limitation of Python here, `lambda` doesn't
allow complex transformations due to its restrictions, so one has
to switch to named functions which works but isn't sexy (and
tends to lower readability imo).
I don't see any real limitation. What's wrong in:
for localVar in container:
block
Well what's wrong with using that rather than `map`, `filter` or a
list comprehension? (and if you don't see what the limitations of
`lambda` are, you probably very rarely use it)
I know well about the expression-only-limitation of lambda, fortnately
there is the 'for' loop construct (or, alternatively, you can define
a named function).
And then, what's wrong with using 'for' rather than 'map', 'filter'
etc.?
Nothing, but then again nothing's wrong using C's for either.
But I do think that using higher-order functions:
* tends to be terser while not going overly terse, it only removes
boilerplate
* is more composable (it's pretty easy to tack another transformer in
your chain, the same way defining iterator/generator transformers and
chaining them is simpler than doing the same thing using explicit
`for…in`)
* it clearly spells the intent of the programmer, while `for` can be
anything and everything, and one has to dive into the code to know
even the high-level operations performed (is it a basic
transformation? A filtering or partitioning? A reduction? An
application of side effects?)
Agree, that 'anonymous block syntax' would be nice in some cases, but
I don't see any real limitation caused by lack of it i.e. something
you
can't (all you can only with unreasonable effort).
There are no limitations, but once again there never are. There are no
actual limitations to using conditional jumps over iterators either.
And ruby's container.each is very similar to Python's iter()
Uh… not at all…
OK, .each is like Python's iter() + some form of iterating over it
('for' loop or '[i]map'...).
Well of course Enumerable#each is similar to map/imap, it's the same
core principle.
--
http://mail.python.org/mailman/listinfo/python-list
