[ python-Feature Requests-1367936 ] split() string method has two splitting algorithms

[SourceForge.net]

Feature Requests item #1367936, was opened at 2005-11-28 00:13
Message generated for change (Comment added) made by mcherm
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: crackwitz (crackwitz)
Assigned to: Nobody/Anonymous (nobody)
Summary: split() string method has two splitting algorithms

Initial Comment:
The docs of Python 2.4.2 for .split([sep [,maxsplit]]) say:
"If sep is not specified or is None, a different
splitting algorithm is applied."
I would like to see that behavior exposed and
consistent, i.e. stripping (new key strip=...?)
independent of whether sep is None or not.
Making it consistent could break existing code because
people already built on split()'s special behavior.
You could say strip=None by default and only keep
switching if strip==None.
I don't like this magic behavior though because there's
no reason for it to exist.

# this is now (Python v2.4.2)
' foo  bar '.split() # => ['foo', 'bar']
' foo  bar '.split(' ') # => ['', 'foo', '', 'bar', '']

# this is how I would like it to be
' foo  bar '.split(strip=True) # => ['foo', 'bar']
' foo  bar '.split(strip=False) # => ['', 'foo', '',
'bar', '']

# compatibility preserved (strip=None by default):
' foo  bar '.split(strip=None) # => ['foo', 'bar']
' foo  bar '.split(' ', strip=None) # => ['', 'foo',
'', 'bar', '']

what do you think?

----------------------------------------------------------------------

>Comment By: Michael Chermside (mcherm)
Date: 2005-12-28 10:55

Message:
Logged In: YES 
user_id=99874

I'm -1 on changing it at all. I do understand how the
unnecessary inconsistancy can be grating, but it is clearly
documented, it is backward compatible, and it is useful.
Pragmatism wins out over theoretical consistancy in my opinion.

----------------------------------------------------------------------

Comment By: Raymond Hettinger (rhettinger)
Date: 2005-11-29 23:10

Message:
Logged In: YES 
user_id=80475

While unfortunate, this function already suffers from excess
complexity.  Changing the behavior and adding backwards
compatability features would make the situation worse.

Also, the two different behaviors were not accidental. 
Someone put them in for a reason.  There may be orthogonal
use cases.  Ideally, that need would have been been through
two different functions/methods.  But, if you change the
behavior, you're likely breaking an entire class of use cases.

So, I'm -1 on mucking with this prior to Py3.0.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1367936&group_id=5470