Tim Peters wrote: > > [M.-A. Lemburg] > > ... > > Uhm, aren't we discussing a generic sequence join API here ? > > It depends on whether your "we" includes me <wink>. > > > Well, in that case I'd still be interested in hearing about > > your thoughts so that I can intergrate such a beast in mxTools. > > The acceptance level neede for doing that is much lower than > > for the core builtins ;-) > > Heh heh. Python already has a generic sequence join API, called "reduce". > What else do you want beyond that? There's nothing else I want, and I don't > even want reduce <0.9 wink>. You can mine any modern Lisp, or any ancient > APL, for more of this ilk. NumPy has some use for stuff like this, but > effective schemes require dealing with multiple dimensions intelligently, > and then you're in the proper domain of matrices rather than sequences. The idea behind a generic join() API was that it could be used to make algorithms dealing with sequences polymorph -- but you're right: this goal is probably too far fetched. > > > That said, > > > > > > space.join((eggs, bacon, toast)) > > > > > > should <wink> produce > > > > > > str(egg) + space + str(bacon) + space + str(toast) > > > > > > although how Unicode should fit into all this was never clear to me. > > > But that would mask errors and, > > As I said elsewhere in the msg, I have never seen this "error" do anything > except irritate a user whose intent was the utterly obvious one (i.e., > convert the object to a string, than catenate it). > > > even worse, "work around" coercion, which is not a good idea, IMHO. > > Note that the need to coerce to Unicode was the reason why the > > implicit str() in " ".join() was removed from Barry's original string > > methods implementation. > > I'm hoping that in P3K we have only one string type, and then the ambiguity > goes away. In the meantime, it's a good reason to drop Unicode support > <snicker>. I'm hoping for that too... it should be Unicode everywhere if you'd ask me. In the meantime we can test drive this goal using the -U command line option: it turns "" into u"" without any source code change. The fun part about this is that running python in -U mode reveals quite a few places where the standard lib doesn't handle Unicode properly, so there's a lot of work ahead... > > space.join(map(str,seq)) is much clearer in this respect: it > > forces the user to think about what the join should do with non- > > string types. > > They're producing a string; they want join to turn the pieces into strings; > it's a no-brainer unless join is hypergeneralized into terminal obscurity > (like, indeed, Python's "reduce"). Hmm, the Unicode implementation does these implicit conversions during coercion and you've all seen the success... are you sure you want more of this ? We could have "".join() apply str() for all objects *except* Unicode. 1 + "2" == "12" would also be an option, or maybe 1 + "2" == 3 ? ;-) -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4