[ python-Bugs-1001011 ] str.join([ str-subtype-instance ]) misbehaves

SourceForge.net noreply at sourceforge.net
Wed Aug 4 21:39:48 CEST 2004

Bugs item #1001011, was opened at 2004-07-30 20:08
Message generated for change (Comment added) made by tjreedy
You can respond by visiting: 

Category: Type/class unification
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Thomas Wouters (twouters)
Assigned to: Nobody/Anonymous (nobody)
Summary: str.join([ str-subtype-instance ]) misbehaves

Initial Comment:
Joining a list of string subtype instances usually
results in a single string instance:

  >>> class mystr(str): pass
  >>> type("".join([mystr("a"), mystr("b")]))
  <type 'str'>

But if the list only contains one object that is a
string subtype instance, that instance is returned

  >>> type("".join([mystr("a")]))
  <class '__main__.mystr'>

This can have odd effects, for instance when the result
of "".join(lst) is used as the returnvalue of a __str__
hook. "".join should perhaps return the type of the
joining string, but definately vary its type based on
the *number* of items its joining.


Comment By: Terry J. Reedy (tjreedy)
Date: 2004-08-04 15:39

Logged In: YES 

This behavior does not, to me, clearly violate the current doc:
"Return a string which is the concatenation of the strings in 
the sequence seq"
where string is bytestring or Unicodestring.  If one takes
'string' narrowly, then your subclass instances should be 
rejected as input.  If one takes 'string' more broadly as 
isinstance(s,basestring) then your subclass should be equally 
acceptible as input or output.  If neither consistent 
interpretation of 'string' is meant, then there is a doc bug, or 
at least an underspecification.

Workaround 0: if len(seq) == 1: ...
Workaround 1. map(str, seq)) to force str out.

*However*, in playing around (in 2.2), I discovered:

>>> type(''.join((a)))
<type 'str'>
>>> type(''.join([a]))
<class '__main__.ms'>
>>> type(''.join({a:None}))
<class '__main__.ms'>

Having the type of the join of a singleton depend on the type 
(mutability?) of the singleton wrapper is definitely disquieting.

Workaround 2: tuple(seq)


Comment By: Michael Hudson (mwh)
Date: 2004-08-02 10:25

Logged In: YES 

What are you asking?  I agree it's a bug.  I'm sure you're 
competent to write a patch :-)


You can respond by visiting: 

More information about the Python-bugs-list mailing list