<div dir="ltr"><div class="gmail_extra">Getting back to the topic of this thread ...</div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Aug 10, 2014 at 8:33 AM, Nick Coghlan <span dir="ltr"><<a href="mailto:ncoghlan@gmail.com" target="_blank">ncoghlan@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'd be interested in seeing a concrete proposal for a "concat" builtin that accepted a "sep" keyword only argument.</blockquote>
</div><div class="gmail_extra"><br></div><div class="gmail_extra">I don't think concat() is the same operation as sep.join().  I view concat as an operation that is naturally defined on a pair of sequences and can be naturally (via reduce) extended to apply to an iterable of sequences:</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">z = concat(x, y) <=> len(z) = len(x) + len(y), z[i] = x[i] if i < len(x), z[i] = y[i - len(x)] otherwise.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
(Note that the definition works for any abstract sequence.)</div><div class="gmail_extra"><br></div><div class="gmail_extra">I find it odd that although CPython defines concatenation as a part of the sequence protocol at the implementation level, the abstract base class Sequence does not.  This omission may present an opportunity to design Sequence.__concat__ and builtin concat() so that concatenation of iterables of sequences can be implemented efficiently in concrete types.</div>
<br><br></div></div>