Re: [Python-Dev] Proof of the pudding: str.partition()
Raymond Hettinger [EMAIL PROTECTED] wrote: As promised, here is a full set of real-world comparative code transformations using str.partition(). The patch isn't intended to be applied; rather, it is here to test/demonstrate whether the new construct offers benefits under a variety of use cases. Having looked at many of Raymond's transformations earlier today (just emailing him a copy of my thoughts and changes minutes ago), I agree that this simplifies essentially every example I have seen translated, and translated myself. There are a handful of errors I found during my pass, most of which seem corrected in the version he has sent to python-dev (though not all). To those who are to reply in this thread, rather than nitpicking about the correctness of individual transformations (though perhaps you should email him directly about those), comment about how much better/worse they look. Vote to add str.partition to 2.5: +1 Vote to dump str.find sometime later if str.partition makes it: +1 - Josiah ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
Raymond writes: That suggests that we need a variant of split() that has been customized for typical find/index use cases. Perhaps introduce a new pair of methods, partition() and rpartition() +1 My only suggestion is that when you're about to make a truly inspired suggestion like this one, that you use a new subject header. It will make it easier for the Python-Dev summary authors and for the people who look back in 20 years to ask That str.partition() function is really swiggy! It's everywhere now, but I wonder what language had it first and who came up with it? -- Michael Chermside [PS: To explain what swiggy means I'd probably have to borrow the time machine.] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] partition() (was: Remove str.find in 3.0?)
Michael Chermside wrote:
Raymond writes:
That suggests that we need a variant of split() that has been
customized for typical find/index use cases. Perhaps introduce a
new pair of methods, partition() and rpartition()
+1
My only suggestion is that when you're about to make a truly
inspired suggestion like this one, that you use a new subject
header. It will make it easier for the Python-Dev summary
authors and for the people who look back in 20 years to ask
That str.partition() function is really swiggy! It's everywhere
now, but I wonder what language had it first and who came up with
it?
+1
This is very useful behaviour IMO.
Have the precise return values of partition() been defined?
Specifically, given:
'a'.split('b')
we could get back:
('a', '', '')
('a', None, None)
Similarly:
'ab'.split('b')
could be either:
('a', 'b', '')
('a', 'b', None)
IMO the most useful (and intuitive) behaviour is to return strings in
all cases.
My major issue is with the names - partition() doesn't sound right to
me. split() of course sounds best, but it has additional stuff we don't
necessarily want. However, I think we should aim to get the idea
accepted first, then work out the best name.
Tim Delaney
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Remove str.find in 3.0?
[Kay Schluehr] The discourse about Python3000 has shrunken from the expectation of the next big thing into a depressive rhetorics of feature elimination. The language doesn't seem to become deeper, smaller and more powerfull but just smaller. [Guido] There is much focus on removing things, because we want to be able to add new stuff but we don't want the language to grow. ISTM that a major reason that the Python 3.0 discussion seems focused more on removal than addition is that a lot of addition can be (and is being) done in Python 2.x. This is a huge benefit, of course, since people can start doing things the new and improved way in 2.x, even though it's not until 3.0 that the old and evil ;) way is actually removed. Removal of map/filter/reduce is an example - there isn't discussion about addition of new features, because list comps/gen expressions are already here... =Tony.Meyer ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Alternative name for str.partition()
A more descriptive name than 'partition' would be 'split_at'. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
[Delaney, Timothy (Tim)] +1 This is very useful behaviour IMO. Thanks. It seems to be getting +1s all around. Have the precise return values of partition() been defined? . . . IMO the most useful (and intuitive) behaviour is to return strings in all cases. Yes, there is a precise spec and yes it always returns three strings. Movitation and spec: http://mail.python.org/pipermail/python-dev/2005-August/055764.html Pure python implementation, sample invocations, and tests: http://mail.python.org/pipermail/python-dev/2005-August/055764.html My major issue is with the names - partition() doesn't sound right to me. FWIW, I am VERY happy with the name partition(). It has a long and delightful history in conjunction with the quicksort algorithm where it does something very similar to what we're doing here: partitioning data into three groups (left,center,right) with a small center element (called a pivot in the quicksort context and called a separator in our string parsing context). This name has enjoyed great descriptive success in communicating that the total data size is unchanged and that the parts can be recombined to the whole. IOW, it is exactly the right word. I won't part with it easily. http://www.google.com/search?q=quicksort+partition Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Raymond Hettinger wrote: Yes, there is a precise spec and yes it always returns three strings. Movitation and spec: http://mail.python.org/pipermail/python-dev/2005-August/055764.html Ah - thanks. Missed that in the mass of emails. My major issue is with the names - partition() doesn't sound right to me. FWIW, I am VERY happy with the name partition(). It has a long and delightful history in conjunction with the quicksort algorithm where it does something very similar to what we're doing here: I guessed that the motivation came from quicksort. My concern is that partition is not something that most users would associate with strings. I know I certainly wouldn't (at least, not immediately). The behaviour is obvious from the name, but I don't feel the name is obvious from the behaviour. If I were explaining the behaviour of partition() to someone, the words I would use are something like: partition() splits a string into 3 parts - the bit before the first occurrance of the separator, the separator, and the bit after the separator. If the separator isn't in the string at all then the entire string is returned as the bit before and the returned separator and bit after are empty strings. I'd probably also explain that if the separator is the very last thing in the string the bit after would be an empty string, but that is fairly intuitive in any case IMO. It's a pity split() is already taken - but then, you would want split() to do more in any case (specifically, split multiple times). Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: My major issue is with the names - partition() doesn't sound right to me. FWIW, I am VERY happy with the name partition(). I'm +1 on the functionality, and +1 on the name partition(). The only other name that comes to mind is 'separate()', but a) I always spell it 'seperate' (and I don't need another lamdba wink) b) It's too similar in name to 'split()' Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition()
Raymond == Raymond Hettinger [EMAIL PROTECTED] writes: Raymond FWIW, I am VERY happy with the name partition(). Raymond ... [I]t is exactly the right word. I won't part with it Raymond easily. +1 I note that Emacs has a split-string function which does not have those happy properties. In particular it never preserves the separator, and (by default) it discards empty strings. Raymond It has a long and delightful history in conjunction with Raymond the quicksort algorithm Now, that is a delightful mnemonic! -- School of Systems and Information Engineering http://turnbull.sk.tsukuba.ac.jp University of TsukubaTennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can do free software business; ask what your business can do for free software. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Hi, How about piece() ? Anthony can have his es that way too! ;-) and it's the same number of characters as .split(). Cheers, --ldl On 8/29/05, Anthony Baxter [EMAIL PROTECTED] wrote: On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: My major issue is with the names - partition() doesn't sound right to me. FWIW, I am VERY happy with the name partition(). I'm +1 on the functionality, and +1 on the name partition(). The only other name that comes to mind is 'separate()', but a) I always spell it 'seperate' (and I don't need another lamdba wink) b) It's too similar in name to 'split()' Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Hi, Re: multiples, etc... Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See: http://www.jacquardsystems.com/Examples/function/piece.htm Cheers, --ldl On 8/29/05, LD Gus Landis [EMAIL PROTECTED] wrote: Hi, How about piece() ? Anthony can have his es that way too! ;-) and it's the same number of characters as .split(). Cheers, --ldl -- LD Landis - N0YRQ - from the St Paul side of Minneapolis ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: FWIW, I am VERY happy with the name partition(). I like it too. +1 -Fred -- Fred L. Drake, Jr. fdrake at acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Delaney, Timothy (Tim) wrote: I think that one of the things I have against it is that most times I type it, I get a typo. If this function is accepted, I think it will (and should!) become one of the most used string functions around. As such, the name should be *very* easy to type. FWIW, the analogy with quicksort convinced me that partition is a good name, even though I'm a terirlbe tpyist. I'm a pretty good proofreader, though. ;-) Shane ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On Tue, Aug 30, 2005, Delaney, Timothy (Tim) wrote: Looks like I'm getting seriously outvoted here ... Still, as I said I don't think the name is overly important until the idea has been accepted anyway. How long did we go with people in favour of resource manager until context manager came up? In that case, though, it was more, Well, I'm not that happy with 'context manager', but there doesn't seem to be anything better. This time, it's closer to, That's a good name for the concept, yup. As you say, if someone comes up with a clearly better name, it likely will win; however, partition has been blessed by enough people that it's not worth putting much effort into finding anything better. Of course, if I (or someone else) can't come up with an obviously better name, partition() will win by default. I don't think it's a *bad* name - just don't think it's a particularly *obvious* name. It's at least as obvious as translate(). shrug -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ The way to build large Python applications is to componentize and loosely-couple the hell out of everything. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
On 2005-08-30, Anthony Baxter [EMAIL PROTECTED] wrote: On Tuesday 30 August 2005 11:26, Raymond Hettinger wrote: My major issue is with the names - partition() doesn't sound right to me. FWIW, I am VERY happy with the name partition(). I'm +1 on the functionality, and +1 on the name partition(). The only other name that comes to mind is 'separate()', but a) I always spell it 'seperate' (and I don't need another lamdba wink) b) It's too similar in name to 'split()' trisplit() ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] partition() (was: Remove str.find in 3.0?)
Raymond Hettinger wrote: Heh! Maybe AttributeError and NameError should be renamed to TypoError ;-) Afterall, the only time I get these exceptions is when the fingers press different buttons than the brain requested. You misspelled TyopError ;) Tim Delaney ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
