Re: [Python-ideas] This seems like a wart to me...

Bruce Leban wrote:
[i for i in s.split(x) if i] is simple enough if I don't know how to write "(" + re.escape(x) + ")+".
The point of the dropempty keyword would be less the dropempty=True case as the s.split(None, dropempty=False) case, which would otherwise require a regexp. -- Carl

Carl Johnson writes:
-0. Eliminating str.split()'s implementation in favor of using str.split() in the no argument case and re.split when an argument is present is backward incompatible, so I can't really object although I prefer a fix by documenting re.split() in appropriate places. I do file a technical objection and ask the judge to strike the wording "require a regexp" from the transcript as prejudicial to the accused.<wink> Preferred phrasing is "would otherwise require an import of re."

Whoa. I haven't wasted much time trying to follow this (IMO rather silly) argument about consistency. We're not going to introduce backwards incompatibilities or deprecate existing usage of str.split() with or without arguments are we? A dropempty argument also seems excessive -- we can't possibly add ad-hoc filtering options to every function that returns a list or iterator, that would be madness. As long as the discussion is just about giving regexps a bad name I don't really care enough to comment; but I have to draw the line when actual API changes are being considered seriously. --Guido van Rossum (home page: http://www.python.org/~guido/) On Sat, Dec 13, 2008 at 4:24 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

Guido> We're not going to introduce backwards incompatibilities or Guido> deprecate existing usage of str.split() with or without arguments Guido> are we? As the OP, I long ago (in terms of number of posts on the topic) gave up on the thought that the str.split() API might change. Someone suggested this idiom: [elt for elt in s.split(",") if elt] which I will adopt (with a comment explaining why it's necessary). Skip

Carl Johnson writes:
-0. Eliminating str.split()'s implementation in favor of using str.split() in the no argument case and re.split when an argument is present is backward incompatible, so I can't really object although I prefer a fix by documenting re.split() in appropriate places. I do file a technical objection and ask the judge to strike the wording "require a regexp" from the transcript as prejudicial to the accused.<wink> Preferred phrasing is "would otherwise require an import of re."

Whoa. I haven't wasted much time trying to follow this (IMO rather silly) argument about consistency. We're not going to introduce backwards incompatibilities or deprecate existing usage of str.split() with or without arguments are we? A dropempty argument also seems excessive -- we can't possibly add ad-hoc filtering options to every function that returns a list or iterator, that would be madness. As long as the discussion is just about giving regexps a bad name I don't really care enough to comment; but I have to draw the line when actual API changes are being considered seriously. --Guido van Rossum (home page: http://www.python.org/~guido/) On Sat, Dec 13, 2008 at 4:24 PM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

Guido> We're not going to introduce backwards incompatibilities or Guido> deprecate existing usage of str.split() with or without arguments Guido> are we? As the OP, I long ago (in terms of number of posts on the topic) gave up on the thought that the str.split() API might change. Someone suggested this idiom: [elt for elt in s.split(",") if elt] which I will adopt (with a comment explaining why it's necessary). Skip
participants (4)
-
Carl Johnson
-
Guido van Rossum
-
skip@pobox.com
-
Stephen J. Turnbull