On Thu, 17 Mar 2005 06:09:44 GMT, rumours say that Raymond Hettinger
[EMAIL PROTECTED] might have written:
[snip]
Did I make you believe I cared about the fate of any function judged unworthy
even for the documentation?
No. My note was mainly for the benefit of those who had an interest in
On Sun, 13 Mar 2005 06:52:40 GMT, rumours say that Raymond Hettinger
[EMAIL PROTECTED] might have written:
[snip of lots of stuff]
itertools.window() with n=2 got rejected. Almost all proposed uses had better
solutions (such as an accumulator variable or fibonacci sequence style logic:
a, b =
itertools.window() with n=2 got rejected. Almost all proposed uses had better
solutions (such as an accumulator variable or fibonacci sequence style logic:
a, b = b, a+b). Writing it in C afforded only small speed advantage over a
solution using izip() and tee().
[Christos TZOTZIOY Georgiou]
Raymond == Raymond Hettinger [EMAIL PROTECTED] writes:
Raymond Each one of the options listed is a reason that flatten()
Raymond shouldn't be an itertool. It fails tests of obviousness,
Raymond learnability, complexity of implementation, and
Raymond simplicity of API. The
Ville Vainio wrote:
A simpler API:
def flatten(sequence, atomic_test = lambda o: isinstance(o,basestring)):
don't recurse into iterables if atomic_test - True
Yes, this is also the API I would have suggested. Simple, but flexible
enough to handle the odd cases with the occasional
Steven Bethard wrote:
Ville Vainio wrote:
A simpler API:
def flatten(sequence, atomic_test = lambda o:
isinstance(o,basestring)):
don't recurse into iterables if atomic_test - True
Yes, this is also the API I would have suggested. Simple,
but flexible enough to handle the odd
Robert Brewer wrote:
Steven Bethard wrote:
Ville Vainio wrote:
A simpler API:
def flatten(sequence, atomic_test = lambda o:
isinstance(o,basestring)):
don't recurse into iterables if atomic_test - True
Yes, this is also the API I would have suggested. Simple,
but flexible enough to handle
Steven == Steven Bethard [EMAIL PROTECTED] writes:
Steven complex atomicity test). I also have the feeling that any
Steven complicated atomictiy test is more than a simple and-ing
Steven of several tests...
I also have the feeling that if the atomicity criterion was any more
Steven complex atomicity test). I also have the feeling that any
Steven complicated atomictiy test is more than a simple and-ing
Steven of several tests...
Ville Vainio
I also have the feeling that if the atomicity criterion was any more
complex in the API, the proposal would be
Raymond == Raymond Hettinger [EMAIL PROTECTED] writes:
Steven complex atomicity test). I also have the feeling that any
Steven complicated atomictiy test is more than a simple and-ing
Steven of several tests...
Raymond Ville Vainio
I also have the feeling that if the
Raymond Hettinger [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
FWIW, requests for additions to the itertools module have not fallen on
deaf
ears. There are no arbitrary restraints on building out this module.
Each
request has gotten careful thought and a couple of them were
[bearophile]
This was my suggestion for a possible flatten():
flatten(sequence, level=-1, tuples=True, strings=False, safe=False)
- tuples=True then it flattens tuples too.
- strings=True then it flattens strings with len(s)1 too.
- safe if True it cheeks (with something like an iterative
[Ville Vainio]
For quick-and-dirty stuff, it's often convenient to flatten a sequence
(which perl does, surprise surprise, by default):
. . .
but something like this would be handy in itertools as well.
It seems trivial, but I managed to screw up several times when trying
to produce my own
13 matches
Mail list logo
