Feature Requests item #1367936, was opened at 2005-11-28 00:13
Message generated for change (Comment added) 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: 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: 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
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
