Mailman 3 August 2005 - Python-Dev

Re: [Python-Dev] Proof of the pudding: str.partition()
by Delaney, Timothy (Tim) 06 Sep '05

06 Sep '05

Fredrik Lundh wrote: > the problem isn't the time it takes to unpack the return value, the > problem is that it takes time to create the substrings that you don't > need. I'm actually starting to think that this may be a good use case for views of strings i.e. rather than create 3 new strings, each "string" is a view onto the string that was partitioned. Most of the use cases I've seen, the partitioned bits are discarded almost as soon as the original string, and often the original string persists beyond the partitioned bits. Tim Delaney

7 16

Revising RE docs (was: partition() (was: Remove str.find in 3.0?))
by Michael Chermside 05 Sep '05

05 Sep '05

Barry Warsaw writes: > Although it's mildly annoying that the docs describe the compiled method > names in terms of the uncompiled functions. I always find myself > looking up the regexp object's API only to be shuffled off to the > module's API and then having to do the argument remapping myself. An excellent point. Obviously, EITHER (1) the module functions ought to be documented by reference to the RE object methods, or vice versa: (2) document the RE object methods by reference to the module functions. (2) is what we have today, but I would prefer (1) to gently encourage people to use the precompiled objects (which are distinctly faster when re-used). Does anyone else think we ought to swap that around in the documentation? I'm not trying to assign more work to Fred... but if there were a python-dev consensus that this would be desirable, then perhaps someone would be encouraged to supply a patch. -- Michael Chermside

9 12

partition() (was: Remove str.find in 3.0?)
by Delaney, Timothy (Tim) 02 Sep '05

02 Sep '05

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

25 59

Re: [Python-Dev] Proof of the pudding: str.partition()
by Phillip J. Eby 01 Sep '05

01 Sep '05

At 04:55 AM 8/31/2005 -0700, Michael Chermside wrote: >Raymond's original definition for partition() did NOT support any >of the following: > > (*) Regular Expressions This can be orthogonally added to the 're' module, and definitely should not be part of the string method. > (*) Ways to generate just 1 or 2 of the 3 values if some are > not going to be used Yep, subscripting and slicing are more than adequate to handle *all* of those use cases, even the ones that some people have been jumping through odd hoops to express: before = x.partition(sep)[0] found = x.partition(sep)[1] after = x.partition(sep)[2] before, found = x.partition("foo")[:2] found, after = x.partition("foo")[1:] before, after = x.partition("foo")[::2] Okay, that last one is maybe a little too clever. I'd personally just use '__' or 'DONTCARE' or something like that for the value(s) I didn't care about, because it actually takes slightly less time to unpack a 3-tuple into three function-local variables than it does to pull out a single element of the tuple, and it's almost twice as fast as taking a slice and unpacking it into two variables. So, using three variables is both faster *and* easier to read than any of the variations anybody has proposed, including the ones I just showed above. > (*) Clever use of indices to avoid copying strings > (*) Behind-the-scenes tricks to allow repeated re-partitioning > to be faster than O(n^2) Yep, -1 on these. >The absence of these "features" is a GOOD thing. It makes the >behavior of partition() so simple and straightforward that it is >easily documented and can be instantly understood by a competent >programmer. I *like* keeping it simple. In fact, if anything, I'd >give UP the one fancy feature he chose to include: > > (*) An rpartition() function that searches from the right > >...except that I understand why he included it and am convinced >by the arguments (use cases can be demonstrated and people would >expect it to be there and complain if it weren't). I'd definitely like to keep rpartition. For example, splitting an HTTP url's hostname from its port should be done with rpartition, since you can have a 'username:password@' part before the host, and because the host can be a bracketed bracketed IPv6 host address with colons in it. >Simplicity and elegence are two of the reasons that this is such >an excellent proposal, +1.

9 10

Re: [Python-Dev] [Python-checkins] python/dist/src/Lib/test test_re.py, 1.45.6.3, 1.45.6.4
by Jim Jewett 01 Sep '05

01 Sep '05

On 8/31/05, akuchling(a)users.sourceforge.net <akuchling(a)users.sourceforge.net> wrote: > Log Message: > ... the tests aren't run by default because I wanted to minimize > upheaval to the 2.3 test suite What is the reasoning behind this? It seems to me that if a (passing) test is being added, maintenance releases are the *most* important places to run them. On the other hand, I've also seen Raymond check (regression) tests into only development, so it seems to be a conscious choice. *I* just don't understand it. -jJ

2 1

Re: [Python-Dev] Proof of the pudding: str.partition()
by Michael Chermside 01 Sep '05

01 Sep '05

Raymond's original definition for partition() did NOT support any of the following: (*) Regular Expressions (*) Ways to generate just 1 or 2 of the 3 values if some are not going to be used (*) Clever use of indices to avoid copying strings (*) Behind-the-scenes tricks to allow repeated re-partitioning to be faster than O(n^2) The absence of these "features" is a GOOD thing. It makes the behavior of partition() so simple and straightforward that it is easily documented and can be instantly understood by a competent programmer. I *like* keeping it simple. In fact, if anything, I'd give UP the one fancy feature he chose to include: (*) An rpartition() function that searches from the right ...except that I understand why he included it and am convinced by the arguments (use cases can be demonstrated and people would expect it to be there and complain if it weren't). Simplicity and elegence are two of the reasons that this is such an excellent proposal, let's not lose them. We have existing tools (like split() and the re module) to handle the tricky problems. -- Michael Chermside

7 7

import exceptions
by Neal Norwitz 01 Sep '05

01 Sep '05

Is there any reason to import exceptions? It's only done in 4 places: Lib/asyncore.py, Lib/shutil.py, Lib/idlelib/PyShell.py, and Lib/test/test_exceptions.py. I can understand the one in test, but should the other 3 be removed since exceptions are builtin? n

2 1

Proof of the pudding: str.partition()
by Jim Jewett 31 Aug '05

31 Aug '05

Michael Chermside wrote (but I reordered): >Simplicity and elegence are two of the reasons that this > is such an excellent proposal, let's not lose them. > Raymond's original definition for partition() did NOT support > any of the following: > (*) Regular Expressions While this is obviously more powerful, and an analogue should probably go in re ... it doesn't belong in strings. I don't want to have to explain why "www.python.org".part('.') acts strangely (forget to escape the period). > (*) Ways to generate just 1 or 2 of the 3 values if some are > not going to be used > (*) Clever use of indices to avoid copying strings > (*) Behind-the-scenes tricks to allow repeated re-partitioning > to be faster than O(n^2) I think these may be useful behind the scenes, but the API should not expose them unless they are made more general. For instance, the compiler could recognize that junk variables (or variable names matching a certain pattern?) don't really have to be created -- and that would be useful for more than string splitting. Doing it as a special case here just leads to a backwards compatibility wart later. -jJ

1 0

Alternative name for str.partition()
by Jim Jewett 31 Aug '05

31 Aug '05

[In http://mail.python.org/pipermail/python-dev/2005-August/055880.html ] Andrew Durdin wrote: > one of the "fixed stdlib" examples that Raymond > posted actually uses rpartition and partition in two consecutive lines Even with that leadin, even right next to each other, it took me a bit of time to see the difference between rest.rpartition and rest.partition. > rest, _, query = rest.rpartition('?') > script, _, rest = rest.partition('/') Shortening the names helps, because a single letter matters more. > rest, _, query = rest.rpart('?') > script, _, rest = rest.part('/') A different-looking word (such as Greg's suggestion) might be even better, if the word also works on its own. > rest, _, query = rest.rsplit_at('?') > script, _, rest = rest.split_at('/') -jJ

1 0

Switching re and sre
by A.M. Kuchling 31 Aug '05

31 Aug '05

FYI: In a discussion on the Python security response list, Guido suggested that the sre.py and re.py modules should be switched. Currently re.py just imports the contents of sre.py -- once it supported both sre and the PCRE-based pre.py -- and sre.py contains the actual code. Now that pre.py is gone, we can move the actual code into re.py and make sre.py just import re.py, so that any user code that actually imports sre will still work. I'll make this change today. --amk

1 0