Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com wrote: I see your point but I'm not totally convinced I don't understand unicode that well so I'll just be quiet now. Unicode is horrible, but better than the available alternatives when it comes to character sets with more than 128 characters :) Your point about int and long vs str and unicode is interesting though. Does it mean str and unicode will some time in the future be unified once all the differences are sorted out ? Eventually, all Python text strings will be unicode, with a separate type for manipulating a sequence of bytes. That's a long way away, though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT]: Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: I'm sure theres got to be a few copy cats in those 12 though. Those that don't come up with original answers alter the existing ones a bit and call it their own. Does that mean you just haven't had time to finish ? or you have been studying philosophy for 15 years ? Sort of an extended break, really. Every year I plan to finish up, but then can't find the time and/or money to do it. Nick -- # sigmask || 0.2 || 20030107 || public domain || feed this to a python print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?') -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Nick Vargish wrote: Leo Breebaart [EMAIL PROTECTED] writes: That suggests to me an obvious default of the kind that exists elsewhere in Python as well. I feel pretty much the opposite... If a non-string-type has managed to get into my list-of-strings, then something has gone wrong and I would like to know about this potential problem. If you want to do force a conversion before the join, you can use a list comp: ', '.join([str(x) for x in l]) Nick Explicit is better than Implicit Really ? Then why are you using python. Python or most dynamic languages are are so great because of their common sense towards the implicit. You must have heard of never say never but never say always (as in always better) is more appropriate here. There are many cases of python's implicitness. What about a = string b = 2 c = %s%s % (a, b) There is an implicit str(b) here. ''.join([string, 2]) to me is no different then the example above. Huy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com wrote: Nick Explicit is better than Implicit Really ? Then why are you using python. Python or most dynamic languages are are so great because of their common sense towards the implicit. You must have heard of never say never but never say always (as in always better) is more appropriate here. There are many cases of python's implicitness. a certain princess bride quote would fit here, I think. What about a = string b = 2 c = %s%s % (a, b) There is an implicit str(b) here. nope. it's explicit: %s means convert using str(). from the documentation: %s String (converts any python object using str()). ''.join([string, 2]) to me is no different then the example above. so where's the %s in your second example? /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Nick Vargish [EMAIL PROTECTED] wrote: I feel pretty much the opposite... If a non-string-type has managed to get into my list-of-strings, then something has gone wrong and I would like to know about this potential problem. This is a good argument. Why not have another method to do this? I propose joinany which will join any type of object together, not just strings That way it becomes less of a poke in the eye to backwards compatibility too. Nick Explicit is better than Implicit Aye! -- Nick Craig-Wood [EMAIL PROTECTED] -- http://www.craig-wood.com/nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Nick Craig-Wood wrote: Nick Vargish [EMAIL PROTECTED] wrote: Why not have another method to do this? I propose joinany which will join any type of object together, not just strings l = [1,2,3,'four'] ','.join(map(str, l)) '1,2,3,four' Is this really that hard to do, that you want it in the library? -- hilsen/regards Max M, Denmark http://www.mxm.dk/ IT's Mad Science -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Nick Craig-Wood wrote: Why not have another method to do this? I propose joinany which will join any type of object together, not just strings I think that's what Frederik was proposing. Except that it would be called join and be a built-in (not a str method). -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Max M wrote: ','.join(map(str, l)) '1,2,3,four' Is this really that hard to do, that you want it in the library? I think it's a sufficiently common use case that having to do that is a wart. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart wrote: All I've been able to find is a 1999 python-dev post by Tim Peters which would seem to indicate he doesn't understand it either: string.join(seq) doesn't currently convert seq elements to string type, and in my vision it would. At least three of us admit to mapping str across seq anyway before calling string.join, and I think it would be a nice convenience [...] But now it's 2005, and both string.join() and str.join() still explicitly expect a sequence of strings rather than a sequence of stringifiable objects. There's a more recent discussion than that, because I tried to change it shortly after I offered a patch to fix a corner case for string subclasses. This seems to be the last relevant message in the thread: http://mail.python.org/pipermail/python-dev/2004-August/048516.html So it was tried, but we found too many weird corner cases we weren't quite sure what to do with. At that point, explicit is better than implicit kicked in :) A shame, since it was both faster and more convenient than using a list comp. But the convenience wasn't worth the ambiguity of the semantics. Cheers, Nick. P.S. For anyone else that uses Firefox: Linking the pydev keyword to http://www.google.com/search?q=site:mail.python.org+inurl:python-dev+%s; and the pylist keyword to http://www.google.com/search?q=site:mail.python.org+inurl:python-list+%s; makes searching the archives on python.org really easy. Of course, knowing what you're looking for because you were a participant in the discussion helps, too ;) -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments I don't really like that idea for the reasons others have stated. But a related and (IMHO) more Pythonic idea would be to allow arbitrary objects to be str.join()ed if they use __radd__ to allow concatenation with strings. This would be consistent with how the + operator behaves: Python 2.4 (#2, Jan 8 2005, 20:18:03) [GCC 3.3.5 (Debian 1:3.3.5-5)] on linux2 Type help, copyright, credits or license for more information. class Foo(object): ... def __radd__(self, other): ... if isinstance(other, basestring): ... return other + str(self) ... def __str__(self): ... return 'Foo()' ... 'foo:' + Foo() 'foo:Foo()' ''.join(['foo', Foo()]) Traceback (most recent call last): File stdin, line 1, in ? TypeError: sequence item 1: expected string, Foo found -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: Really ? Then why are you using python. Try import this at a Python prompt. I didn't invent Explicit is better than implicit. Python or most dynamic languages are are so great because of their common sense towards the implicit. Python is not most dynamic languages, and does not seem to implicitly cast objects into other types. Python may be dynamic, but it's also strongly typed, a feature I consider a benefit, though you are of course free to disagree. c = %s%s % (a, b) There is an implicit str(b) here. Not if you read the docs, as another poster has pointed out. ''.join([string, 2]) to me is no different then the example above. TypeError: sequence item 1: expected string, int found Which pretty much supports my initial argument -- if a non-string got into the list, something needs to be fixed, and it isn't the behavior of the join() method! Nick -- # sigmask || 0.2 || 20030107 || public domain || feed this to a python print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?') -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Fredrik Lundh wrote: news.sydney.pipenetworks.com wrote: Nick Explicit is better than Implicit Really ? Then why are you using python. Python or most dynamic languages are are so great because of their common sense towards the implicit. You must have heard of never say never but never say always (as in always better) is more appropriate here. There are many cases of python's implicitness. a certain princess bride quote would fit here, I think. I'm not really familiar with it, can you enlighten please. What about a = string b = 2 c = %s%s % (a, b) There is an implicit str(b) here. nope. it's explicit: %s means convert using str(). ok you got me there, although it must be bad practice compared to c = %s%d % (a, b) because this is much more explicit and will tell you if b is ever anything other then an integer even though you may not care. from the documentation: %s String (converts any python object using str()). ''.join([string, 2]) to me is no different then the example above. so where's the %s in your second example? /F I'm not sure if this has been raised in the thread but I sure as heck always convert my join arguments using str(). When does someone use .join() and not want all arguments to be strings ? Any examples ? Regards, Huy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Nick Vargish wrote: news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: Really ? Then why are you using python. Try import this at a Python prompt. I didn't invent Explicit is better than implicit. Thanks for the pointer. Let's see how many zen points are for the OP's idea vs against Against Explicit is better than implicit. Special cases aren't special enough to break the rules. On the wall Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. Namespaces are one honking great idea -- let's do more of those! For Beautiful is better than ugly. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Although practicality beats purity. Unless explicitly silenced. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. Well this is clearly a goer ;-) Python or most dynamic languages are are so great because of their common sense towards the implicit. Python is not most dynamic languages, and does not seem to implicitly cast objects into other types. Python may be dynamic, but it's also strongly typed, a feature I consider a benefit, though you are of course free to disagree. c = %s%s % (a, b) There is an implicit str(b) here. Not if you read the docs, as another poster has pointed out. ''.join([string, 2]) to me is no different then the example above. TypeError: sequence item 1: expected string, int found Which pretty much supports my initial argument -- if a non-string got into the list, something needs to be fixed, and it isn't the behavior of the join() method! Nick -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com wrote: Nick Vargish wrote: news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: Really ? Then why are you using python. Try import this at a Python prompt. I didn't invent Explicit is better than implicit. Thanks for the pointer. Let's see how many zen points are for the OP's idea vs against Against Explicit is better than implicit. Special cases aren't special enough to break the rules. On the wall Errors should never pass silently. In the face of ambiguity, refuse the temptation to guess. There should be one-- and preferably only one --obvious way to do it. Although that way may not be obvious at first unless you're Dutch. Now is better than never. Although never is often better than *right* now. Namespaces are one honking great idea -- let's do more of those! For Beautiful is better than ugly. Simple is better than complex. Complex is better than complicated. Flat is better than nested. Sparse is better than dense. Readability counts. Although practicality beats purity. Unless explicitly silenced. If the implementation is hard to explain, it's a bad idea. If the implementation is easy to explain, it may be a good idea. From the point of view of someone who actually *tried* doing this to the relevant method, while maintaining backward compatibility. . . Against: Explicit is better than implicit Special cases aren't special enough to break the rules In the face of ambiguity, refuse the temptation to guess - there are plenty of ambiguious cases to handle Simple is better than complex (Semantics C code) - and much complexity in dealing with the ambiguities Errors should never pass silently. Unless explicitly silenced. - and a bunch of them are likely to indicate errors. Maybe. Readability counts (C code) - This makes the implemenation hard to read If the implementation is hard to explain, it's a bad idea. - or explain to anyone, too For: Beautiful is better than ugly. - the explicit calls to str() aren't that clean. There should be one-- and preferably only one --obvious way to do it. - Currently listcomp, genexp, map, string interpolation, etc IMO, the rest can be used to argue either side, or simply don't weigh heavily either way. The things that make it a real cow are the current behaviour of auto-promotion to the Unicode version when there are any Unicode strings in the list, and the existence of __str__ and __repr__ methods which actually return instances of unicode rather than str. Calling str() explicitly makes the different behaviours unsurprising. Trying to do the same thing behind the scenes has the potential to make the method behave *very* suprisingly depending on the objects involved. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.skystorm.net -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
In article [EMAIL PROTECTED], ! Nick Vargish [EMAIL PROTECTED] wrote: If a non-string-type has managed to get into my list-of-strings, then something has gone wrong and I would like to know about this potential problem. Thinking about where I use join(), I agree. If there's something other than a string in my list, either I know about it and can explicitly convert it (Explicit is better than implicit.) or it's an error, and Errors should never pass silently. -- \S -- [EMAIL PROTECTED] -- http://www.chaos.org.uk/~sion/ ___ | Frankly I have no feelings towards penguins one way or the other \X/ |-- Arthur C. Clarke her nu becomeþ se bera eadward ofdun hlæddre heafdes bæce bump bump bump -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com wrote:
I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
.join() and not want all arguments to be strings ? Any examples ?
This has already been raised, but maybe not in exactly this context. You
don't want to convert your arguments to be strings if some of them are
unicode.
If I do:
res = str.join(', ', [a, b, c])
then res is of type str if, and only if, a, b, and c are of type str.
If any of a, b, or c are of type unicode, then res is unicode.
In effect, this means you don't have to worry about whether you are
manipulating str or unicode at this point in your program (kind of
comparable to not caring whether the integer you are using is int or long).
When you come to output the string you do need to care, as when it is
unicode you may have to encode it, but at least the internal manipulations
can ignore this possibility.
Of course you could just call unicode on everything but for simple
applications you might not want to handle unicode at all. That's not a
decision Python can make for you so it shouldn't guess.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com wrote: Fredrik Lundh wrote: a certain princess bride quote would fit here, I think. I'm not really familiar with it, can you enlighten please. (Taking a guess at which quote /F had in mind...) Vezzini: Inconceivable! Inigo:You keep using that word. I do not think that it means what you think it means. Jeff Shannon -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Jeremy Bowers wrote: I'd point out that the Zen that can be comprehended by checking off items in a list is not the true Zen. The Zen that can be imported is not the eternal Zen. =) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
I did some timings of ''.join( list comprehension ) vs. ''.join( generator expression ) and found that generator expressions were slightly slower, so I looked at the source code to find out why. It turns out that the very first thing string_join(self, orig) does is: seq = PySequence_Fast(orig, ); thus iterating over your generator expression and creating a list, making it less efficient than passing a list in the first place via a list comprehension. The reason it does this is exactly why you said: It iterates over the sequence and gets the sum of the lengths, adds the length of n-1 separators, and then allocates a string this size. Then it iterates over the list again to build up the string. For generators, you'd have to make a trial allocation and start appending stuff as you go, periodically resizing. This *might* end up being more efficient in the case of generators, but the only way to know for sure is to write the code and benchmark it. I will be at PyCon 2005 during the sprint days, so maybe I'll write it then if someone doesn't beat me to it. I don't think it'll be all that hard. It might be best done as an iterjoin() method, analogous to iteritems(), or maybe xjoin() (like xrange(), xreadlines()). Incidentally, I was inspired to do the testing in the first place from this: http://www.skymind.com/~ocrow/python_string/ Those tests were done with Python-2.3. With 2.4, naive appending (i.e. doing s1 += s2 in a loop) is about 13-15% slower than a list comprehension, but uses much less memory (for large loops); and a generator expression is about 7% slower and uses slightly *more* memory. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
On 2005-02-18, Andy Dustman [EMAIL PROTECTED] wrote: The reason it does this is exactly why you said: It iterates over the sequence and gets the sum of the lengths, adds the length of n-1 separators, and then allocates a string this size. Then it iterates over the list again to build up the string. The other (and, I suspect, the real) reason for materializing the argument is to be able to call unicode.join if it finds Unicode elements in the sequence. If it finds such an element, unicode.join has to be called on the entire sequence; the part already accumulated can't be used because unicode.join wants to call PyUnicode_FromObject on all the elements. Since it can't know whether the original argument is reiterable, it has to keep around the materialized sequence. For generators, you'd have to make a trial allocation and start appending stuff as you go, periodically resizing. This *might* end up being more efficient in the case of generators, but the only way to know for sure is to write the code and benchmark it. Even if it's not faster, it should use about half as much memory for non-sequence arguments. That can be a big win if elements are being generated on the fly (e.g., it's a generator that does something other than just iterate over an existing sequence). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Looking at the code, it seems that if it finds a unicode object on the first pass (the sizing pass), it punts and returns PyUnicode_Join(self, seq), which is the sequence from above and not necessarily the original object (orig), and starts over. In the worst-case scenario, you have a long sequence of strings with one unicode string at the end... Actually, I guess I'm a little surprised that str.join(arg) doesn't require arg to be an iterator that returns str instances. unicode.join(arg) can afford to be a little more flexible. I wonder how common it is to pass a mixture of str and unicode to str.join(). -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Duncan Booth wrote:
news.sydney.pipenetworks.com wrote:
I'm not sure if this has been raised in the thread but I sure as heck
always convert my join arguments using str(). When does someone use
.join() and not want all arguments to be strings ? Any examples ?
This has already been raised, but maybe not in exactly this context. You
don't want to convert your arguments to be strings if some of them are
unicode.
If I do:
res = str.join(', ', [a, b, c])
then res is of type str if, and only if, a, b, and c are of type str.
If any of a, b, or c are of type unicode, then res is unicode.
In effect, this means you don't have to worry about whether you are
manipulating str or unicode at this point in your program (kind of
comparable to not caring whether the integer you are using is int or long).
When you come to output the string you do need to care, as when it is
unicode you may have to encode it, but at least the internal manipulations
can ignore this possibility.
Of course you could just call unicode on everything but for simple
applications you might not want to handle unicode at all. That's not a
decision Python can make for you so it shouldn't guess.
I see your point but I'm not totally convinced I don't understand
unicode that well so I'll just be quiet now.
Your point about int and long vs str and unicode is interesting though.
Does it mean str and unicode will some time in the future be unified
once all the differences are sorted out ?
Regards,
Huy
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Jeremy Bowers wrote: On Fri, 18 Feb 2005 01:19:44 +1100, news.sydney.pipenetworks.com wrote: Thanks for the pointer. Let's see how many zen points are for the OP's idea vs against Along with the fact that I agree with Nick that you've seriously miscounted (most of your fors are simply irrelevant and I think you added them to bolster your point, at least I *hope* you don't think they are all relevant... for instance if you really think Flat is better than nested applies here, you don't understand what that one is saying...), You're right there. It's my own interpretation :-) I'd point out that the Zen that can be comprehended by checking off items in a list is not the true Zen. Well I didn't create or bring up the list of items originally. I was zenning it out until someone pointed me to the Python commandments. I always wished computer science was more engineering then philosophy. That way there'd always be an obvious answer. Regards, Huy -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
On Fri, 18 Feb 2005 14:14:55 +1100, news.sydney.pipenetworks.com wrote: I always wished computer science was more engineering then philosophy. That way there'd always be an obvious answer. I hear that! To be fair, computer *science* is more like mathematics than philosophy; once a correctly-framed question has been asked there is only one answer, or at least the answers are definite, or definite in their indefiniteness. (For the most part.) We're programming here though, and there we are groping through the formless void, arguing about whether my infinitesimal is better than your infinitesimal. Sorry, I was Zenning it out too, I guess. :-) By the way, just to be clear, my infinitesimal's dad can beat up your infinitesimal's dad any day of the week. (Looks like the Zen mood has passed...) -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: I always wished computer science was more engineering then philosophy. That way there'd always be an obvious answer. You don't have a lot of experience with philosophers, do you? Most of them are quite willing to go on at great length about the obvious answer to just about any question... You get a dozen obvious answers with every twelve philosophers. Nick p.s. I've been working on a philosophy degree for about... 15 years now. -- # sigmask || 0.2 || 20030107 || public domain || feed this to a python print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?') -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Jeremy Bowers wrote: By the way, just to be clear, my infinitesimal's dad can beat up your infinitesimal's dad any day of the week. Ouchit's getting personal :-). Your dad may be infinitesimal but my dad is a complex number (I'm not joking, he really has a real and imaginary part). (Looks like the Zen mood has passed...) :-) Huy -- http://mail.python.org/mailman/listinfo/python-list
[OT]: Re: Why doesn't join() call str() on its arguments?
Nick Vargish wrote: news.sydney.pipenetworks.com [EMAIL PROTECTED] writes: I always wished computer science was more engineering then philosophy. That way there'd always be an obvious answer. You don't have a lot of experience with philosophers, do you? No Most of them are quite willing to go on at great length about the obvious answer to just about any question... You get a dozen obvious answers with every twelve philosophers. Interesting. I guess its obvious once stated, because if it wasn't obvious, many people wouldn't agree. I'm sure theres got to be a few copy cats in those 12 though. Nick p.s. I've been working on a philosophy degree for about... 15 years now. Does that mean you just haven't had time to finish ? or you have been studying philosophy for 15 years ? Huy -- http://mail.python.org/mailman/listinfo/python-list
Why doesn't join() call str() on its arguments?
I've tried Googling for this, but practically all discussions on str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method? issue, which is not my problem/question at all. What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. All I've been able to find is a 1999 python-dev post by Tim Peters which would seem to indicate he doesn't understand it either: string.join(seq) doesn't currently convert seq elements to string type, and in my vision it would. At least three of us admit to mapping str across seq anyway before calling string.join, and I think it would be a nice convenience [...] But now it's 2005, and both string.join() and str.join() still explicitly expect a sequence of strings rather than a sequence of stringifiable objects. I'm not complaining as such -- sep.join(str(i) for i in seq) is not *that* ugly, but what annoys me is that I don't understand *why* this was never changed. Presumably there is some counter-argument involved, some reason why people preferred the existing semantics after all. But for the life of me I can't think what that counter-argument might be... -- Leo Breebaart [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments [...] [...] Presumably there is some counter-argument involved, some reason why people preferred the existing semantics after all. But for the life of me I can't think what that counter-argument might be... One possibility I can think of would be Unicode. I don't think that implicitly calling str() on Unicode strings is desirable. (But then again, I know embarrassingly little about unicode, so this may or may not be a valid concern.) Of course, one could ensure that unicode.join() used unicode() and str.join() used str(), but I can conceive of the possibility of wanting to use a plain-string separator to join a list that might include unicode strings. Whether this is a realistic use-case is, of course, a completely different question... Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Jeff Shannon wrote: One possibility I can think of would be Unicode. I don't think that implicitly calling str() on Unicode strings is desirable. it's not. but you could make an exception for basestring types. Of course, one could ensure that unicode.join() used unicode() and str.join() used str(), but I can conceive of the possibility of wanting to use a plain-string separator to join a list that might include unicode strings. yes. Whether this is a realistic use-case it is. mixing 8-bit ascii strings with unicode works perfectly fine, and is a good way to keep memory use down in programs that uses ascii in most cases (or for most strings), but still needs to support non-ascii text. I've proposed adding a join built-in that knows about the available string types, and does the right thing for non-string objects. unfortunately, the current crop of py-dev:ers don't seem to use strings much, so they prioritized really important stuff like sum() and reversed() instead... /F -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
In article [EMAIL PROTECTED], Fredrik Lundh [EMAIL PROTECTED] wrote: I've proposed adding a join built-in that knows about the available string types, and does the right thing for non-string objects. unfortunately, the current crop of py-dev:ers don't seem to use strings much, so they prioritized really important stuff like sum() and reversed() instead... You know where the patch tracker is ;-) -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The joy of coding Python should be in seeing short, concise, readable classes that express a lot of action in a small amount of clear code -- not in reams of trivial code that bores the reader to death. --GvR -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart wrote: I'm not complaining as such -- sep.join(str(i) for i in seq) is not *that* ugly, but what annoys me is that I don't understand *why* this was never changed. py chars = [u'ä', u'å'] py ', '.join(chars) u'\xe4, \xe5' py ', '.join(str(c) for c in chars) Traceback (most recent call last): File interactive input, line 1, in ? File interactive input, line 1, in generator expression UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 0: ordinal not in range(128) py u', '.join(chars) u'\xe4, \xe5' py u', '.join(unicode(c) for c in chars) u'\xe4, \xe5' Currently, str.join will return a unicode object if any of the items to be joined are unicode. That means that str.join accepts unicode objects as well as str objects. So you couldn't just call str on all the objects... Maybe you could call str or unicode on each object as appropriate though... If str.join already determines that it must return a unicode object, it could call unicode on all the items instead of str... I don't know the code well enough though to know if this is feasible... STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
On 16 Feb 2005 18:47:21 GMT, Leo Breebaart [EMAIL PROTECTED] wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. For a start, I think you meant ''.join([1,2,4,5]) to yield 1245. Secondly, concatenating arbitrary types with a null separator doesn't appear to be a good use case. E.g. ''.join([str(x) for x in [1,2,1./3,4]]) '120.4' Some possible explanations: 1. Explicit is better than implicit. 2. It would only be a good trick IMHO with a non-null separator and types with a 'clean' str() result (unlike float) -- like int; I can't think of more at the moment. 3. It would be one step on the slippery downwards path to perlishness. 4. For consistency, would you like 1 + 2 to produce 12? -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
John 4. For consistency, would you like 1 + 2 to produce 12? No, the correct answer is obviously 3. ;-) S -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
John Machin [EMAIL PROTECTED] writes: On 16 Feb 2005 18:47:21 GMT, Leo Breebaart [EMAIL PROTECTED] wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. For a start, I think you meant ''.join([1,2,4,5]) to yield 1245. Yep. Sorry. Bad example. Secondly, concatenating arbitrary types with a null separator doesn't appear to be a good use case. E.g. ''.join([str(x) for x in [1,2,1./3,4]]) '120.4' Okay: ', '.join(str(x) for x in [1,2,1./3,4]) '1, 2, 0., 4' Isn't that better? I am not claiming that *all* uses of calling join() on arbitrary types are useful. But then neither are *all* uses of calling join() on actual strings, or all uses of adding arbitrarily typed elements to a list, or... It's just that in my experience so far, whenever I have felt a need for the 'join()' function, it has *always* been in a situation where I also have to do the str(x) thing. That suggests to me an obvious default of the kind that exists elsewhere in Python as well. It is entirely possible that my experience is not shared (or not to the same extent) by others, but part of my reason for asking this question here is investigating precisely that. Some possible explanations: 1. Explicit is better than implicit. Sure. But it's always a tradeoff -- list comprehensions are more implicit than for loops... 2. It would only be a good trick IMHO with a non-null separator and types with a 'clean' str() result (unlike float) -- like int; I can't think of more at the moment. I don't agree that the str() result for a float isn't clean. Sometimes it can be exactly what you need, or even just sufficient. If you want more control, then pure join() isn't what you need, anyway. Right? 3. It would be one step on the slippery downwards path to perlishness. I think you're exaggerating, and I really would prefer to have this discussion without gratuitous swipes against other languages, please? 4. For consistency, would you like 1 + 2 to produce 12? No. A foolish consistency etc. etc. I sincerely do like the fact that Python does not try to second-guess the programmer, I do value explicit over implicit, and I have no desire to open the can of worms that would be the changing the semantics of +. I think my main dissatisfaction with your four possible explanations stems from the fact that a join() function that would be a bit more type-agnostic strikes me as *more* Pythonic, not *less*. Isn't that what duck typing is about? Why does join() care that its arguments should be actual strings only? If the function of join() is to produce a string, why isn't it sufficient for its arguments to have a string representation -- why do they have to *be* strings? Isn't that sort of thing exactly how we are taught *not* to write our own argument handling when we learn Python? -- Leo Breebaart [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Skip Montanaro [EMAIL PROTECTED] writes: John 4. For consistency, would you like 1 + 2 to produce 12? No, the correct answer is obviously 3. ;-) S No, '12' is correct. Or '1+2'. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've tried Googling for this, but practically all discussions on str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method? issue, which is not my problem/question at all. What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. All I've been able to find is a 1999 python-dev post by Tim Peters which would seem to indicate he doesn't understand it either: string.join(seq) doesn't currently convert seq elements to string type, and in my vision it would. At least three of us admit to mapping str across seq anyway before calling string.join, and I think it would be a nice convenience [...] But now it's 2005, and both string.join() and str.join() still explicitly expect a sequence of strings rather than a sequence of stringifiable objects. I'm not complaining as such -- sep.join(str(i) for i in seq) is not *that* ugly, but what annoys me is that I don't understand *why* this was never changed. Presumably there is some counter-argument involved, some reason why people preferred the existing semantics after all. But for the life of me I can't think what that counter-argument might be... -- Leo Breebaart [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] I've tried Googling for this, but practically all discussions on str.join() focus on the yuck-ugly-shouldn't-it-be-a-list-method? issue, which is not my problem/question at all. What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. All I've been able to find is a 1999 python-dev post by Tim Peters which would seem to indicate he doesn't understand it either: string.join(seq) doesn't currently convert seq elements to string type, and in my vision it would. At least three of us admit to mapping str across seq anyway before calling string.join, and I think it would be a nice convenience [...] But now it's 2005, and both string.join() and str.join() still explicitly expect a sequence of strings rather than a sequence of stringifiable objects. I'm not complaining as such -- sep.join(str(i) for i in seq) is not *that* ugly, but what annoys me is that I don't understand *why* this was never changed. Presumably there is some counter-argument involved, some reason why people preferred the existing semantics after all. But for the life of me I can't think what that counter-argument might be... I was originally going to say performance, but I don't think that's all that much of an issue. For me, at least, I've already got a way of taking just about anything and turning it into a string: the % operator. It's powerful enough that there have been attempts to make a less powerful and simpler to understand version. The limitation here is that you have to know how many elements you want to join, although even that isn't the world's hardest issue. Consider: (untested) result = (%s * len(list)) % list Not the most obvious code in the world, but it might work. And as someone else (you?) pointed out, this will also work: (untested) result = .join([str(x) for x in list]) and it's got the advantage that it will handle separators properly. John Roth -- Leo Breebaart [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Leo Breebaart [EMAIL PROTECTED] writes: That suggests to me an obvious default of the kind that exists elsewhere in Python as well. I feel pretty much the opposite... If a non-string-type has managed to get into my list-of-strings, then something has gone wrong and I would like to know about this potential problem. If you want to do force a conversion before the join, you can use a list comp: ', '.join([str(x) for x in l]) Nick Explicit is better than Implicit -- # sigmask || 0.2 || 20030107 || public domain || feed this to a python print reduce(lambda x,y:x+chr(ord(y)-1),' Ojdl!Wbshjti!=obwAcboefstobudi/psh?') -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
On Wed, 16 Feb 2005 14:24:02 -0600, Skip Montanaro [EMAIL PROTECTED] wrote: John 4. For consistency, would you like 1 + 2 to produce 12? No, the correct answer is obviously 3. ;-) Obviously, in awk. Bletch! I once had to help out some users of a system where software development had been outsourced and upstuffed and they needed some data file fixups done but their system was so locked down even the manufacturer-supplied free pre-ANSI C compiler had been deleted and one couldn't download stuff off the net but the thought police had overlooked awk ... I even had to implement proper CSV-reading routines in awk. No thanks for reminding me :-( -- http://mail.python.org/mailman/listinfo/python-list
RE: Why doesn't join() call str() on its arguments?
John Roth wrote: result = .join([str(x) for x in list]) As of 2.4, you should use a generator expression here instead (unless you require backwards-compatibility with 2.3). result = ''.join(str(x) for x in iterable) Easier to read, more memory-efficient, potentially faster (depending on performance characteristics of building large lists). Tim Delaney -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Delaney, Timothy C (Timothy) [EMAIL PROTECTED] writes: John Roth wrote: result = .join([str(x) for x in list]) As of 2.4, you should use a generator expression here instead (unless you require backwards-compatibility with 2.3). result = ''.join(str(x) for x in iterable) Easier to read, more memory-efficient, potentially faster (depending on performance characteristics of building large lists). Stop me if I sound too whiney, but in my original post that started this thread just a couple of hours ago, I did in fact get this right, so I'm not entirely sure who the two of you are actually talking to... -- Leo Breebaart [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Fredrik Lundh wrote: I've proposed adding a join built-in that knows about the available string types, and does the right thing for non-string objects. That would be *so* useful. I frequently have to use the .join(map(str, mylist)) idiom, which is a wart. -- Michael Hoffman -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
In article [EMAIL PROTECTED], David Eppstein [EMAIL PROTECTED] wrote: In article [EMAIL PROTECTED], Leo Breebaart [EMAIL PROTECTED] wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. That would be the wrong thing to do when the arguments are unicodes. Why would it be wrong? I ask this with honest naivete, being quite ignorant of unicode issues. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why doesn't join() call str() on its arguments?
Roy Smith wrote: What I can't find an explanation for is why str.join() doesn't automatically call str() on its arguments, so that e.g. str.join([1,2,4,5]) would yield 1245, and ditto for e.g. user-defined classes that have a __str__() defined. That would be the wrong thing to do when the arguments are unicodes. Why would it be wrong? I ask this with honest naivete, being quite ignorant of unicode issues. As someone else demonstrated earlier... str(u'ü') Traceback (most recent call last): File interactive input, line 1, in ? UnicodeError: ASCII encoding error: ordinal not in range(128) Using str() on a unicode object works... IF all of the unicode characters are also in the ASCII charset. But if you're using non-ASCII unicode characters (and there's no point to using Unicode unless you are, or might be), then str() will throw an exception. The Effbot mentioned a join() implementation that would be smart enough to do the right thing in this case, but it's not as simple as just implicitly calling str(). Jeff Shannon Technician/Programmer Credit International -- http://mail.python.org/mailman/listinfo/python-list
