[ python-Feature Requests-1367936 ] split() string method has two splitting algorithms
SourceForge.net
noreply at sourceforge.net
Wed Dec 28 19:27:49 CET 2005
Feature Requests item #1367936, was opened at 2005-11-28 00:13
Message generated for change (Settings changed) made by rhettinger
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: Closed
>Resolution: Rejected
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
More information about the Python-bugs-list
mailing list