Why doesn't join() call str() on its arguments?

Nick Coghlan ncoghlan at iinet.net.au
Thu Feb 17 09:52:54 EST 2005


news.sydney.pipenetworks.com wrote:
> Nick Vargish wrote:
> 
>> "news.sydney.pipenetworks.com" <nytimes at swiftdsl.com.au> 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   |   ncoghlan at email.com   |   Brisbane, Australia
---------------------------------------------------------------
             http://boredomandlaziness.skystorm.net



More information about the Python-list mailing list