Re: [Python-Dev] partition()
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> writes: > Phillip J. Eby wrote: > >> +1 for partition(). > > 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? Certainly no longer than until I got up the morning after the discussion started :) partition() works for me. It's not perfect, but it'll do. The idea works for me rather more; it even simplifies the if s.startswith(prefix): t = s[len(prefix):] ... idiom I occasionally wince at. Cheers, mwh -- Gullible editorial staff continues to post links to any and all articles that vaguely criticize Linux in any way. -- Reason #4 for quitting slashdot today, from http://www.cs.washington.edu/homes/klee/misc/slashdot.html ___ 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?)
Phillip J. Eby wrote: >> Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See: >> http://www.jacquardsystems.com/Examples/function/piece.htm > > As far as I can see, either you misunderstand what partition() does, or > I'm > completely misunderstanding what $PIECE does. As far as I can tell, > $PIECE > and partition() have absolutely nothing in common except that they take > strings as arguments. :) both split on a given token. partition splits once, and returns all three parts, while piece returns the part you ask for (the 3-argument form is similar to x.split(s)[i]) ___ 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?)
Well, I want to come back on a point that wasn't discussed. I only found
one positive comment here :
http://mail.python.org/pipermail/python-dev/2005-August/055775.html
It's about that :
Raymond Hettinger wrote:
> * The function always succeeds unless the separator argument is not a
> string type or is an empty string. So, a typical call doesn't have to
> be wrapped in a try-suite for normal usage.
Well, I wonder if it's so good ! Almost all the use case I find would
require something like:
head, sep, tail = s.partition(t)
if sep:
do something
else:
do something else
Like, if you want to extract the drive letter from a windows path :
drive, sep, tail = path.partition(":")
if not sep:
drive = get_current_drive() # Because it's a local path
Or, if I want to iterate over all the path parts in a UNIX path:
sep = '/'
while sep:
head, sep, path = path.partition(sep)
IMO, that read strange ... partitionning until sep is None :S
Then, testing with "if" in Python is always a lot slower than having an
exception launched from C extension inside a try...except block.
So both construct would read like already a lot of Python code:
try:
head,sep,tail = s.partition(t)
do something
except SeparatorException:
do something else
and:
sep='/'
try:
while 1:
head, drop, path = path.partition(sep)
except SeparatorException:
The end
To me, the try..except block to test end or error conditions are just
part of Python design. So I don't understand why you don't want it !
For the separator, keeping it in the return values may be very useful,
mainly because I would really like to use this function replacing string
with a regexp (like a simplified version of the Qt method
QStringList::split) and, in that case, the separator would be the actual
matched separator string.
Pierre
--
Pierre Barbier de Reuille
INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP
Botanique et Bio-informatique de l'Architecture des Plantes
TA40/PSII, Boulevard de la Lironde
34398 MONTPELLIER CEDEX 5, France
tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68
___
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 30/08/05, JustFillBug <[EMAIL PROTECTED]> wrote: > 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 ) > > b) It's too similar in name to 'split()' > > > > trisplit() split3() ? I'm +1 on the name "partition" but I think this is shorter, communicates the similarity to split and the fact that it always returns exactly three parts. Oren ___ 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?)
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, I want to come back on a point that wasn't discussed. I only found
> one positive comment here :
> http://mail.python.org/pipermail/python-dev/2005-August/055775.html
You apparently haven't been reading python-dev for around 36 hours,
because there have been over a dozen positive comments in regards to
str.partition().
> Raymond Hettinger wrote:
> > * The function always succeeds unless the separator argument is not a
> > string type or is an empty string. So, a typical call doesn't have to
> > be wrapped in a try-suite for normal usage.
>
> Well, I wonder if it's so good ! Almost all the use case I find would
> require something like:
>
> head, sep, tail = s.partition(t)
> if sep:
>do something
> else:
>do something else
Why don't you pause for a second and read Raymond's post here:
http://mail.python.org/pipermail/python-dev/2005-August/055781.html
In that email there is a listing of standard library translations from
str.find to str.partition, and in every case, it is improved. If you
believe that str.index would be better used, take a moment and do a few
translations of the sections provided and compare them with the
str.partition examples.
> Like, if you want to extract the drive letter from a windows path :
>
> drive, sep, tail = path.partition(":")
> if not sep:
>drive = get_current_drive() # Because it's a local path
>
> Or, if I want to iterate over all the path parts in a UNIX path:
>
> sep = '/'
> while sep:
> head, sep, path = path.partition(sep)
>
> IMO, that read strange ... partitionning until sep is None :S
> Then, testing with "if" in Python is always a lot slower than having an
> exception launched from C extension inside a try...except block.
In the vast majority of cases, all three portions of the returned
partition result are used. The remaining few are generally split
between one or two instances. In the microbenchmarks I've conducted,
manually generating the slicings are measureably slower than when Python
does it automatically. Also, exceptions are actually quite slow in
relation to comparisons, specifically in the case of find vs. index
(using 2.4)...
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... if x.find('i')>=0:
... pass
... print time.time()-t
...
0.95368665
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... try:
... x.index('i')
... except ValueError:
... pass
... print time.time()-t
...
6.53100013733
I urge you to take some time to read Raymond's translations.
- 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] partition() (was: Remove str.find in 3.0?)
Josiah Carlson a écrit : > Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote: > >>Well, I want to come back on a point that wasn't discussed. I only found >>one positive comment here : >>http://mail.python.org/pipermail/python-dev/2005-August/055775.html > > > You apparently haven't been reading python-dev for around 36 hours, > because there have been over a dozen positive comments in regards to > str.partition(). Well, I wasn't criticizing the overall idea of str.partition, which I found very useful ! I'm just discussing one particular idea, which is to avoid the use of exceptions. > >>Raymond Hettinger wrote: >> >>>* The function always succeeds unless the separator argument is not a >>>string type or is an empty string. So, a typical call doesn't have to >>>be wrapped in a try-suite for normal usage. >> >>Well, I wonder if it's so good ! Almost all the use case I find would >>require something like: >> >>head, sep, tail = s.partition(t) >>if sep: >> do something >>else: >> do something else > > > Why don't you pause for a second and read Raymond's post here: > http://mail.python.org/pipermail/python-dev/2005-August/055781.html > > In that email there is a listing of standard library translations from > str.find to str.partition, and in every case, it is improved. If you > believe that str.index would be better used, take a moment and do a few > translations of the sections provided and compare them with the > str.partition examples. Well, what it does is exactly what I tought, you can express most of the use-cases of partition with: head, sep, tail = s.partition(sep) if not sep: #do something when it does not work else: #do something when it works And I propose to replace it by : try: head, sep, tail = s.partition(sep) # do something when it works except SeparatorError: # do something when it does not work What I'm talking about is consistency. In most cases in Python, or at least AFAIU, error testing is avoided and exception launching is preferred mainly for efficiency reasons. So my question remains: why prefer for that specific method returning an "error" value (i.e. an empty separator) against an exception ? Pierre -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ 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()
Michael Hudson wrote: > partition() works for me. It's not perfect, but it'll do. The idea > works for me rather more; it even simplifies the > > if s.startswith(prefix): > t = s[len(prefix):] > ... How would you do it? Something like: head, found, tail = s.partition(prefix) if found and not head: ... I guess I agree that's an improvement - only a slight one, though. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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?)
Pierre Barbier de Reuille wrote: > What I'm talking about is consistency. In most cases in Python, or at > least AFAIU, error testing is avoided and exception launching is > preferred mainly for efficiency reasons. So my question remains: why > prefer for that specific method returning an "error" value (i.e. an > empty separator) against an exception ? Because, in many cases, there is more to it than just the separator not being found. Given a non-empty some_str and some_sep: head, sep, tail = some_str.partition(some_sep) There are actually five possible results: head and not sep and not tail (the separator was not found) head and sep and not tail (the separator is at the end) head and sep and tail (the separator is somewhere in the middle) not head and sep and tail (the separator is at the start) not head and sep and not tail (the separator is the whole string) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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: > 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. What about simply "str.parts" and "str.rparts"? That is, rather than splitting the string on a separator, we are breaking it into parts - the part before the separator, the separator itself, and the part after the separator. Same concept as 'partition', just a shorter method name. Another option would be simply "str.part()" and "str.rpart()". Then you could think of it as an abbreviation of either 'partition' or 'parts' depending on your inclination. > 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. I've been typing 'partition' a lot lately at work, and Tim's right - typing this correctly is harder than you might think. It is very easy to only type the 'ti' in the middle once, so that you end up with 'partion'. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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?)
Nick Coghlan wrote: > Another option would be simply "str.part()" and "str.rpart()". Then you could > think of it as an abbreviation of either 'partition' or 'parts' depending on > your inclination. I momentarily forgot that "part" is also a verb in its own right, with the right meaning, too (think "parting your hair" and "parting the Red Sea"). So call it +1 for str.part and str.rpart, and +0 for str.partition and str.rpartition. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://boredomandlaziness.blogspot.com ___ 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?)
(unlurking) Le mardi 30 août 2005 à 23:20 +1000, Nick Coghlan a écrit : > I momentarily forgot that "part" is also a verb in its own right, with the > right meaning, too (think "parting your hair" and "parting the Red Sea"). "parts" sounds more obvious than the verb "part" which is little known to non-native English speakers (at least to me anyway). Just my 2 cents. Regards Antoine. ___ 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?)
Concerning names for partition(), I immediately thought of break().
Unfortunately it's taken.
So, how about snap()?
head, sep, tail = line.snap(':')
-j
___
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?)
I have some use cases with: cut_at = some_str.find(sep) head, tail = some_str[:cut_at], some_str[cut_at:] and: cut_at = some_str.find(sep) head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset != len(sep) So if partition() [or whatever it'll be called] could have an optional second argument that defines the width of the 'cut' made, I would be helped enormously. The default for this second argument would be len(sep), to preserve the current proposal. --eric ___ 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?)
Jason Orendorff <[EMAIL PROTECTED]> wrote: > Concerning names for partition(), I immediately thought of break(). > Unfortunately it's taken. > > So, how about snap()? I like .part()/.rpart() (or failing that, .parts()/.rparts()). But if you really want something short that's similar in meaning, there's also .cut(). Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/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?)
Eric Nieuwland a écrit : > I have some use cases with: > cut_at = some_str.find(sep) > head, tail = some_str[:cut_at], some_str[cut_at:] > and: > cut_at = some_str.find(sep) > head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset != > len(sep) > > So if partition() [or whatever it'll be called] could have an optional > second argument that defines the width of the 'cut' made, I would be > helped enormously. The default for this second argument would be > len(sep), to preserve the current proposal. Well, IMO, your example is much better written: import re rsep = re.compile(sep + '.'*offset) lst = re.split(resp, some_str, 1) head = lst[0] tail = lst[1] Or you want to have some "partition" method which accept regular expressions: head, sep, tail = some_str.partition(re.compile(sep+'.'*offset)) > > --eric > > ___ > 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/pierre.barbier%40cirad.fr > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ 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?)
Nick> What about simply "str.parts" and "str.rparts"? -1 because "parts" is not a verb. When I see an attribute that is a noun I generally expect it to be a data attribute. Skip ___ 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()
Hey guys, don't get lost in random naming suggestions (cut, snap, part, parts, yada yada yada). Each of those is much less descriptive and provides less differentiation from other string methods. Saving a few characters is not worth introducing ambiguity. Also, the longer name provides a useful visual balance between the three assigned variables and the separator argument. As an extreme example, contrast the following: head, found, tail = s.p(separator) head, found, tail = s.partition(separator) The verb gets lost if it doesn't have visual weight. Also, for those suggesting alternate semantics (raising exceptions when the separator is not found), I challenge you to prove their worth by doing all the code transformations that I did. It is a remarkably informative exercise that quickly reveals that this alternative is dead-on-arrival. For the poster suggesting an optional length argument, I suggest writing out the revised method invariants. I think you'll find that it snarls them into incomprehensibility and makes the tool much more difficult to learn. Also, I recommend scanning my sample library code transformations to see if any of them would benefit from the length argument. I think you'll find that it comes up so infrequently and with such differing needs that it would be a mistake to bake this into the proposal. 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?)
At 10:01 AM 8/30/2005 +0200, Fredrik Lundh wrote: >Phillip J. Eby wrote: > > >> Check out (and Pythonify) the ANSI M[UMPS] $PIECE(). See: > >> http://www.jacquardsystems.com/Examples/function/piece.htm > > > > As far as I can see, either you misunderstand what partition() does, or > > I'm > > completely misunderstanding what $PIECE does. As far as I can tell, > > $PIECE > > and partition() have absolutely nothing in common except that they take > > strings as arguments. :) > >both split on a given token. partition splits once, and returns all three >parts, while piece returns the part you ask for No, because looking at that URL, there is no piece that is the token split on. partition() always returns 3 parts for 1 occurrence of the token, whereas $PIECE only has 2. >(the 3-argument form is >similar to x.split(s)[i]) Which is quite thoroughly unlike partition. ___ 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?)
At 04:28 PM 8/30/2005 +0200, Eric Nieuwland wrote: >I have some use cases with: > cut_at = some_str.find(sep) > head, tail = some_str[:cut_at], some_str[cut_at:] >and: > cut_at = some_str.find(sep) > head, tail = some_str[:cut_at], some_str[cut_at+offset:] # offset != >len(sep) > >So if partition() [or whatever it'll be called] could have an optional >second argument that defines the width of the 'cut' made, I would be >helped enormously. The default for this second argument would be >len(sep), to preserve the current proposal. Unrelated comment: maybe 'cut()' and rcut() would be nice short names. I'm not seeing the offset parameter, though, because this: head,__,tail = some_str.cut(sep) tail = tail[offset:] is still better than the original example. ___ 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?)
I like partition() but maybe even better would be if strings supported
slicing by string indices.
key, sep, val = 'foo = 32'.partition('=')
would be:
key, val = 'foo = 32'[:'='], 'foo = 32'['=':]
To me it feels very natural to extend Python's slices to string
indices and would cover most of partition()'s use cases. The if sep:
idiom of parition() could be solved by throwing an IndexError: e.g:
_, sep, port = host.partition(':')
if sep:
try:
int(port)
except ValueError:
becomes:
try:
port = host[':':]
int(port)
except IndexError:
pass
except ValueError:
An advantage of using slices would be that you could specify both a
beginning and ending string like this:
>>> s
'http://192.168.12.22:8080'
>>> s['http://':':']
'192.168.12.22'
Sorry if this idea has already been discussed.
--
mvh Björn
___
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?)
Pierre Barbier de Reuille wrote: > Or you want to have some "partition" method which accept regular > expressions: > > head, sep, tail = some_str.partition(re.compile(sep+'.'*offset)) Neat! +1 on regexps as an argument to partition(). --eric ___ 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?)
> Neat! > +1 on regexps as an argument to partition(). It sounds better to have a separate function and call it re.partition, doesn't it ? By the way, re.partition() is *really* useful compared to re.split() because with the latter you don't which string precisely matched the pattern (it isn't an issue with str.split() since matching is exact). Regards Antoine. ___ 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?)
Eric Nieuwland wrote: > Pierre Barbier de Reuille wrote: > >>Or you want to have some "partition" method which accept regular >>expressions: >> >>head, sep, tail = some_str.partition(re.compile(sep+'.'*offset)) > > > Neat! > +1 on regexps as an argument to partition(). Are you sure? I would instead expect to find a .partition method on a regexp object: head, sep, tail = re.compile(sep+'.'*offset).partition(some_str) 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?)
Shane Hathaway a écrit : > Eric Nieuwland wrote: > >> Pierre Barbier de Reuille wrote: >> >>> Or you want to have some "partition" method which accept regular >>> expressions: >>> >>> head, sep, tail = some_str.partition(re.compile(sep+'.'*offset)) >> >> >> >> Neat! >> +1 on regexps as an argument to partition(). > > > Are you sure? I would instead expect to find a .partition method on a > regexp object: > > head, sep, tail = re.compile(sep+'.'*offset).partition(some_str) Well, to be consistent with current re module, it would be better to follow Antoine's suggestion : head, sep, tail = re.partition(re.compile(sep+'.'*offset), some_str) Pierre > > Shane > -- Pierre Barbier de Reuille INRA - UMR Cirad/Inra/Cnrs/Univ.MontpellierII AMAP Botanique et Bio-informatique de l'Architecture des Plantes TA40/PSII, Boulevard de la Lironde 34398 MONTPELLIER CEDEX 5, France tel : (33) 4 67 61 65 77fax : (33) 4 67 61 56 68 ___ 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?)
Pierre Barbier de Reuille wrote: > > Shane Hathaway a écrit : >>Are you sure? I would instead expect to find a .partition method on a >>regexp object: >> >> head, sep, tail = re.compile(sep+'.'*offset).partition(some_str) > > > Well, to be consistent with current re module, it would be better to > follow Antoine's suggestion : > > head, sep, tail = re.partition(re.compile(sep+'.'*offset), some_str) Actually, consistency with the current re module requires new methods to be added in *both* places. Apparently Python believes TMTOWTDI is the right practice here. ;-) See search, match, split, findall, finditer, sub, and subn: http://docs.python.org/lib/node114.html http://docs.python.org/lib/re-objects.html 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
[Python-Dev] setdefault's second argument
Anyone remember why setdefault's second argument is optional?
>>> d = {}
>>> d.setdefault(666)
>>> d
{666: None}
just doesn't seem useful. In fact, it's so silly that someone calling
setdefault with just one arg seems far more likely to have a bug in
their code than to get an outcome they actually wanted. Haven't found
any 1-arg uses of setdefault() either, except for test code verifying
that you _can_ omit the second arg.
This came up in ZODB-land, where someone volunteered to add
setdefault() to BTrees. Some flavors of BTrees are specialized to
hold integer or float values, and then setting None as a value is
impossible. I resolved it there by making BTree.setdefault() require
both arguments. It was a surprise to me that dict.setdefault() didn't
also require both.
If there isn't a sane use case for leaving the second argument out,
I'd like to drop the possibility in P3K (assuming setdefault()
survives).
___
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] setdefault's second argument
Tim Peters <[EMAIL PROTECTED]> wrote:
>
> Anyone remember why setdefault's second argument is optional?
>
> >>> d = {}
> >>> d.setdefault(666)
> >>> d
> {666: None}
For quick reference for other people, d.setdefault(key [, value])
returns the value that is currently there, or just assigned. The only
case where it makes sense to omit the value parameter is in the case
where value=None.
> just doesn't seem useful. In fact, it's so silly that someone calling
> setdefault with just one arg seems far more likely to have a bug in
> their code than to get an outcome they actually wanted. Haven't found
> any 1-arg uses of setdefault() either, except for test code verifying
> that you _can_ omit the second arg.
>
> This came up in ZODB-land, where someone volunteered to add
> setdefault() to BTrees. Some flavors of BTrees are specialized to
> hold integer or float values, and then setting None as a value is
> impossible. I resolved it there by making BTree.setdefault() require
> both arguments. It was a surprise to me that dict.setdefault() didn't
> also require both.
>
> If there isn't a sane use case for leaving the second argument out,
> I'd like to drop the possibility in P3K (assuming setdefault()
> survives).
I agree, at least that in the case where people actually want None (the
only time where the second argument is really optional, I think that
they should have to specify it. EIBTI and all that.
- 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] partition() (was: Remove str.find in 3.0?)
[Shane Hathaway writes about the existence of both module-level functions and object methods to do the same regex operations] > Apparently Python believes TMTOWTDI is the right practice here. ;-) > See search, match, split, findall, finditer, sub, and subn: > > http://docs.python.org/lib/node114.html > http://docs.python.org/lib/re-objects.html Dare I ask whether the uncompiled versions should be considered for removal in Python 3.0? *puts on his asbestos jacket* -- Michael Hoffman <[EMAIL PROTECTED]> European Bioinformatics Institute ___ 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] setdefault's second argument
[Tim Peters]
>> Anyone remember why setdefault's second argument is optional?
>>
>> >>> d = {}
>> >>> d.setdefault(666)
>> >>> d
>> {666: None}
>> ...
[Josiah Carlson]
> For quick reference for other people, d.setdefault(key [, value])
> returns the value that is currently there, or just assigned. The only
> case where it makes sense to omit the value parameter is in the case
> where value=None.
Yes, that's right. Overwhelmingly most often in the wild, a
just-constructed empty container object is passed as the second
argument. Rarely, I see 0 passed. I've found no case where None is
wanted (except in the test suite, verifying that the 1-argument form
does indeed default to using None).
> ...
> I agree, at least that in the case where people actually want None (the
> only time where the second argument is really optional, I think that
> they should have to specify it. EIBTI and all that.
And since there apparently aren't any such cases outside of Python's
test suite, that wouldn't be much of a burden on them .
___
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] setdefault's second argument
[Tim] > Anyone remember why setdefault's second argument is optional? IIRC, this is a vestige from its ancestor. The proposal for setdefault() described it as behaving like dict.get() but inserting the key if not found. > Haven't found > any 1-arg uses of setdefault() either, except for test code verifying > that you _can_ omit the second arg. Likewise, I found zero occurrences in the library, in my cumulative code base, and in the third-party packages on my system. > If there isn't a sane use case for leaving the second argument out, > I'd like to drop the possibility in P3K (assuming setdefault() > survives). Give a lack of legitimate use cases, do we have to wait to Py3.0? It could likely be fixed directly and not impact any code that people care about. 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?)
Michael Hoffman writes: > Dare I ask whether the uncompiled versions [of re object methods] should > be considered for removal in Python 3.0? > > *puts on his asbestos jacket* No flames here, but I'd rather leave them. The docs make it clear that the two sets of functions/methods are equivalent, so the conceptual overhead is small (at least it doesn't scale with the number of methods in re). The docs make it clear that the compiled versions are faster, so serious users should prefer them. But the uncompiled versions are preferable in one special situation: short simple scripts -- the kind of thing often done with shell scriping except that Python is Better (TM). For these uses, performance is irrelevent and it turns a 2-line construct into a single line. Of course the uncompiled versions can be written as little 2-line functions but that's even WORSE for short simple scripts. Nearly everything I write these days is larger and more complex, but I retain a soft spot for short simple scripts and want Python to continue to be the best tool available for these tasks. -- Michael Chermside ___ 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] setdefault's second argument
[Raymond]
> setdefault() described it as behaving like dict.get() but inserting the
> key if not found.
...
> Likewise, I found zero occurrences in the library, in my cumulative code
> base, and in the third-party packages on my system.
[Tim]
>> If there isn't a sane use case for leaving the second argument out,
>> I'd like to drop the possibility in P3K (assuming setdefault()
>> survives).
[Raymond]
> Give a lack of legitimate use cases, do we have to wait to Py3.0? It
> could likely be fixed directly and not impact any code that people care
> about.
That would be fine by me, but any change really requires a
deprecation-warning release first.
Dang! I may have just found a use, in Zope's
lib/python/docutils/parsers/rst/directives/images.py (which is part of
docutils, not really part of Zope):
figwidth = options.setdefault('figwidth')
figclass = options.setdefault('figclass')
del options['figwidth']
del options['figclass']
I'm still thinking about what that's trying to do <0.5 wink>.
Assuming options is a dict-like thingie, it probably meant to do:
figwidth = options.pop('figwidth', None)
figclass = options.pop('figclass', None)
David, are you married to that bizarre use of setdefault ?
Whatever, I can't claim there are _no_ uses of 1-arg setdefault() in
the wild any more.
___
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?)
Pierre Barbier de Reuille <[EMAIL PROTECTED]> wrote:
> Well, what it does is exactly what I tought, you can express most of the
> use-cases of partition with:
>
> head, sep, tail = s.partition(sep)
> if not sep:
> #do something when it does not work
> else:
> #do something when it works
>
> And I propose to replace it by :
>
> try:
> head, sep, tail = s.partition(sep)
> # do something when it works
> except SeparatorError:
> # do something when it does not work
No, you can't. As Tim Peters pointed out, in order to be correct, you
need to use...
try:
head, found, tail = s.partition(sep)
except ValueError:
# do something when it can't find sep
else:
# do something when it can find sep
By embedding the 'found' case inside the try/except clause as you offer,
you could be hiding another exception, which is incorrect.
> What I'm talking about is consistency. In most cases in Python, or at
> least AFAIU, error testing is avoided and exception launching is
> preferred mainly for efficiency reasons. So my question remains: why
> prefer for that specific method returning an "error" value (i.e. an
> empty separator) against an exception ?
It is known among those who tune their Python code that try/except is
relatively expensive when exceptions are raised, but not significantly
faster (if any) when they are not. I'll provide an updated set of
microbenchmarks...
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... _ = x.find('h')
... if _ >= 0:
... pass
... else:
... pass
... print time.time()-t
...
0.8423515
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... try:
... _ = x.index('h')
... except ValueError:
... pass
... else:
... pass
... print time.time()-t
...
0.8126376
BUT!
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... try:
... _ = x.index('i')
... except ValueError:
... pass
... else:
... pass
... print time.time()-t
...
4.29700016975
We should subtract the time of the for loop, the method call overhead,
perhaps the integer object creation/fetch, and the assignment.
str.__len__() is pretty fast (really just a member check, which is at a
constant offset...), let us use that.
>>> if 1:
... x = 'h'
... t = time.time()
... for i in xrange(100):
... _ = x.__len__()
... print time.time()-t
...
0.5
So, subtracting that .5 seconds from all the cases gives us...
0.343 seconds for .find's comparison
0.313 seconds for .index's exception handling when an exception is not
raised
3.797 seconds for .index's exception handling when an exception is
raised.
In the case of a string being found, .index is about 10% faster than
.find . In the case of a string not being found, .index's exception
handlnig mechanics are over 11 times slower than .find's comparison.
Those numbers should speak for themselves. In terms of the strings
being automatically chopped up vs. manually chopping them up with slices,
it is obvious which will be faster: C-level slicing.
I agree with Raymond that if you are going to poo-poo on str.partition()
not raising an exception, you should do some translations using the
correct structure that Tim Peters provided, and post them here on
python-dev as 'proof' that raising an exception in the cases provided is
better.
- 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] partition() (was: Remove str.find in 3.0?)
Raymond Hettinger wrote: > [Delaney, Timothy (Tim)] > >>+1 >> >>This is very useful behaviour IMO. > > > Thanks. It seems to be getting +1s all around. Wow, a lot of approvals! :) >>Have the precise return values of partition() been defined? +1 on the Name partition, I considered split or parts, but i agree partition reads better and since it's not so generic as something like get_parts, it creates a stronger identity making the code clearer. >>IMO the most useful (and intuitive) behaviour is to return strings in >>all cases. Wow, a lot of approvals! :-) A possibly to consider: Instead of partition() and rpartition(), have just partition with an optional step or skip value which can be a positive or negative non zero integer. head, found, tail = partition(sep, [step=1]) step = -1 step would look for sep from the right. step = 2, would look for the second sep from left. step = -2, would look for the second sep from the right. Default of course would be 1, find first step from the left. This would allow creating an iterator that could iterate though a string splitting on each sep from either the left, or right. Weather a 0 or a |value|>len(string) causes an exception would need to be decided. I can't think of an obvious use for a partition iterator at the moment, maybe someone could find an example. In any case, finding the second, or third sep is probably common enough. Cheers, Ron ___ 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?)
Nick> I momentarily forgot that "part" is also a verb in its own right, Nick> with the right meaning, too (think "parting your hair" and Nick> "parting the Red Sea"). If I remember correctly from watching "The Ten Commandments" as a kid, I believe Charlton Heston only parted the Red Sea in one place... Skip ___ 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, 2005-08-30 at 11:27, Phillip J. Eby wrote: > >So if partition() [or whatever it'll be called] could have an optional > >second argument that defines the width of the 'cut' made, I would be > >helped enormously. The default for this second argument would be > >len(sep), to preserve the current proposal. +1 on the concept -- very nice Raymond. > Unrelated comment: maybe 'cut()' and rcut() would be nice short names. FWIW, +1 on .cut(), +0 on .partition() -Barry signature.asc Description: This is a digitally signed message part ___ 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?)
Antoine> By the way, re.partition() is *really* useful compared to
Antoine> re.split() because with the latter you don't which string
Antoine> precisely matched the pattern (it isn't an issue with
Antoine> str.split() since matching is exact).
Just group your re:
>>> import re
>>>
>>> re.split("ab", "abracadabra")
['', 'racad', 'ra']
>>> re.split("(ab)", "abracadabra")
['', 'ab', 'racad', 'ab', 'ra']
and you get it in the return value. In fact, re.split with a grouped re is
very much like Raymond's str.partition method without the guarantee of
returning a three-element list.
Skip
___
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?)
In fact, re.split with a grouped re is very much like Raymond's str.partition method without the guarantee of returning a three-element list. Whoops... Should also have included the maxsplit=1 constraint. Skip ___ 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()
On 30 aug 2005, at 17.11, Raymond Hettinger wrote: > Hey guys, don't get lost in random naming suggestions (cut, snap, > part, > parts, yada yada yada). Each of those is much less descriptive and > provides less differentiation from other string methods. Saving a few > characters is not worth introducing ambiguity. Trisect would be pretty descriptive ... //Simon ___ 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?)
Michael Chermside <[EMAIL PROTECTED]> wrote: > Michael Hoffman writes: > > Dare I ask whether the uncompiled versions [of re object methods] should > > be considered for removal in Python 3.0? > > > > *puts on his asbestos jacket* > > No flames here, but I'd rather leave them. Me too. I have various programs that construct lots of large REs on the fly, knowing they'll only be used once. Not having to compile them to objects inline makes the code cleaner and easier to read. Charles -- --- Charles Cazabon <[EMAIL PROTECTED]> GPL'ed software available at: http://pyropus.ca/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?)
>> http://docs.python.org/lib/re-objects.html Michael> Dare I ask whether the uncompiled versions should be considered Michael> for removal in Python 3.0? It is quite convenient to not have to compile regular expressions in most cases. The module takes care of compiling your patterns and caching them for you. Skip ___ 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?)
>> Unrelated comment: maybe 'cut()' and rcut() would be nice short names. Barry> FWIW, +1 on .cut(), +0 on .partition() As long as people are free associating: snip(), excise(), explode(), invade_iraq()... Skip ___ 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()
Nick Coghlan <[EMAIL PROTECTED]> writes: > Michael Hudson wrote: >> partition() works for me. It's not perfect, but it'll do. The idea >> works for me rather more; it even simplifies the >> >> if s.startswith(prefix): >> t = s[len(prefix):] >> ... > > How would you do it? Something like: > >head, found, tail = s.partition(prefix) >if found and not head: > ... > > I guess I agree that's an improvement - only a slight one, though. Yes. I seem to fairly often[1] do this with prefix as a literal so only having to mention it once would be a win for me. Cheers, mwh [1] But not often enough to have defined a function to do this job, it seems. -- I must be missing something. It is not possible to be this stupid. you don't meet a lot of actual people, do you? ___ 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, 2005-08-30 at 12:39, Michael Chermside wrote: > Michael Hoffman writes: > > Dare I ask whether the uncompiled versions [of re object methods] should > > be considered for removal in Python 3.0? > No flames here, but I'd rather leave them. The docs make it clear that > the two sets of functions/methods are equivalent, so the conceptual > overhead is small (at least it doesn't scale with the number of methods > in re). The docs make it clear that the compiled versions are faster, so > serious users should prefer them. But the uncompiled versions are > preferable in one special situation: short simple scripts -- the kind > of thing often done with shell scriping except that Python is Better (TM). > For these uses, performance is irrelevent and it turns a 2-line > construct into a single line. 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. -Barry signature.asc Description: This is a digitally signed message part ___ 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?
On 8/28/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >>> s = 'http://www.python.org'
> >>> partition(s, '://')
> ('http', '://', 'www.python.org')
> >>> partition(s, '?')
> ('http://www.python.org', '', '')
> >>> partition(s, 'http://')
> ('', 'http://', 'www.python.org')
> >>> partition(s, 'org')
> ('http://www.python.', 'org', '')
>
What would be a result for rpartition(s, '?') ?
('', '', 'http://www.python.org')
or
('http://www.python.org', '', '')
BTW, I wrote a somewhat preliminary patch for this functionality
to let you save little of your time. :-)
http://people.freebsd.org/~perky/partition-r1.diff
Hye-Shik
___
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?)
[Ron Adam]
> This would allow creating an iterator that could iterate though a
string
> splitting on each sep from either the left, or right.
For uses more complex than basic partitioning, people should shift to
more powerful tools like re.finditer(), re.findall(), and re.split().
> I can't think of an obvious use for a partition iterator at the
moment,
> maybe someone could find an example.
I prefer to avoid variants that are searching of a purpose.
> In any case, finding the second,
> or third sep is probably common enough.
That case should be handled with consecutive partitions:
# keep everything after the second 'X'
head, found, s = s.partition('X')
head, found, s = s.partition('x')
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] Remove str.find in 3.0?
[Hye-Shik Chang]
> What would be a result for rpartition(s, '?') ?
> ('', '', 'http://www.python.org')
> or
> ('http://www.python.org', '', '')
The former. The invariants for rpartition() are a mirror image of those
for partition().
> BTW, I wrote a somewhat preliminary patch for this functionality
> to let you save little of your time. :-)
>
> http://people.freebsd.org/~perky/partition-r1.diff
Thanks. I've got one running already, but it is nice to have another
for comparison.
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] setdefault's second argument
On Tue, 30 Aug 2005 18:14:55 +0200, Tim Peters <[EMAIL PROTECTED]>
wrote:
d = {}
d.setdefault(666)
d
> {666: None}
>
> just doesn't seem useful. In fact, it's so silly that someone calling
> setdefault with just one arg seems far more likely to have a bug in
> their code than to get an outcome they actually wanted. Haven't found
reminds me of dict.get()... i think in both cases being explicit::
beast = d.setdefault( 666, None )
beast = d.get( 666, None )
just reads better, allthemore since at least in my code what comes
next is invariably a test 'if beast is None:...'. so
beast = d.setdefault( 666 )
if beast is None:
...
and
beast = d.get( 666 )
if beast is None:
...
a shorter but a tad too implicit for my feeling.
_wolf
___
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 30 aug 2005, at 17:40, Antoine Pitrou wrote:
>> Neat!
>> +1 on regexps as an argument to partition().
>
> It sounds better to have a separate function and call it re.partition,
> doesn't it ?
> By the way, re.partition() is *really* useful compared to re.split()
> because with the latter you don't which string precisely matched the
> pattern (it isn't an issue with str.split() since matching is exact).
Nice, too.
BUT, "spam! and eggs".partition(re.compile("!.*d"))
more closely resembles "xyz".split(), and that is the way things have
evolved up-to now.
--eric
___
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?)
At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
>That case should be handled with consecutive partitions:
>
># keep everything after the second 'X'
>head, found, s = s.partition('X')
>head, found, s = s.partition('x')
Or:
s=s.partition('X')[2].partition('X')[2]
which actually suggests a shorter, clearer way to do it:
s = s.after('X').after('X')
And the corresponding 'before' method, of course, such that if sep in s:
s.before(sep), sep, s.after(sep) == s.partition(sep)
Technically, these should probably be before_first and after_first, with
the corresponding before_last and after_last corresponding to rpartition.
___
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] setdefault's second argument
[Wolfgang Lipp] > reminds me of dict.get()... i think in both cases being explicit:: > > beast = d.setdefault( 666, None ) > beast = d.get( 666, None ) > > just reads better, allthemore since at least in my code what comes > next is invariably a test 'if beast is None:...'. so > > beast = d.setdefault( 666 ) > if beast is None: > ... Do you actually do this with setdefault()? It's not at all the same as the get() example next, because d.setdefault(666) may _also_ have the side effect of permanently adding a 666->None mapping to d. d.get(...) never mutates d. > and > > beast = d.get( 666 ) > if beast is None: > ... > > a shorter but a tad too implicit for my feeling. Nevertheless, 1-argument get() is used a lot. Outside the test suite, I've only found one use of 1-argument setdefault() so far, and it was a poor use (used two lines of code to emulate what dict.pop() does directly). ___ 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?)
Michael Hoffman wrote: > Dare I ask whether the uncompiled versions should be considered for > removal in Python 3.0? > > *puts on his asbestos jacket* there are no uncompiled versions, so that's not a problem. if you mean the function level api, it's there for convenience. if you're using less than 100 expressions in your program, you don't really have to *explicitly* compile your expressions. the function api will do that for you all by itself. ___ 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?)
Phillip J. Eby wrote: >>both split on a given token. partition splits once, and returns all three >>parts, while piece returns the part you ask for > > No, because looking at that URL, there is no piece that is the token split > on. partition() always returns 3 parts for 1 occurrence of the token, > whereas $PIECE only has 2. so "absolutely nothing in common" has now turned into "does the same thing but doesn't return the value you passed to it" ? sorry for wasting my time. ___ 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] setdefault's second argument
Tim Peters wrote:
> Anyone remember why setdefault's second argument is optional?
Some kind of symmetry with get, probably. if
d.get(x)
returns None if x doesn't exist, it makes some kind of sense that
d.setdefault(x)
returns None as well.
Anyone remember why nobody managed to come up with a better name
for setdefault (which is probably the worst name ever given to a method
in the standard Python distribution) ?
(if I were in charge, I'd rename it to something more informative. I'd also
add a "join" built-in (similar to the good old string.join) and a "textfile"
built-
in (similar to open("U") plus support for encodings). but that's me. I
want
my code nice and tidy.)
___
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] Proof of the pudding: str.partition()
Raymond Hettinger wrote:
> Overall, I found that partition() usefully encapsulated commonly
> occurring low-level programming patterns. In most cases, it completely
> eliminated the need for slicing and indices. In several cases, code was
> simplified dramatically; in some, the simplification was minor; and in a
> few cases, the complexity was about the same. No cases were made worse.
it is, however, a bit worrying that you end up ignoring one or more
of the values in about 50% of your examples...
> ! rest, _, query = rest.rpartition('?')
> ! script, _, rest = rest.partition('/')
> ! _, sep, port = host.partition(':')
> ! head, sep, _ = path.rpartition('/')
> ! line, _, _ = line.partition(';') # strip
> chunk-extensions
> ! host, _, port = host.rpartition(':')
> ! head, _, tail = name.partition('.')
> ! head, _, tail = tail.partition('.')
> ! pname, found, _ = pname.rpartition('.')
> ! head, _, tail = name.partition('.')
> ! filename, _, arg = arg.rpartition(':')
> ! line, _, _ = line.partition('#')
> ! protocol, _, condition = meth.partition('_')
> ! filename, _, _ = filename.partition(chr(0))
this is also a bit worrying
> ! head, found, tail = seq.find('-')
but that's more a problem with the test suite.
___
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?)
Phillip J. Eby wrote:
> At 02:25 PM 8/30/2005 -0400, Raymond Hettinger wrote:
>
>> That case should be handled with consecutive partitions:
>>
>> # keep everything after the second 'X'
>> head, found, s = s.partition('X')
>> head, found, s = s.partition('x')
I was thinking of cases where head is everything before the second 'X'.
A posible use case might be getting items in comma delimited string.
> Or:
>
> s=s.partition('X')[2].partition('X')[2]
>
> which actually suggests a shorter, clearer way to do it:
>
> s = s.after('X').after('X')
>
> And the corresponding 'before' method, of course, such that if sep in s:
>
> s.before(sep), sep, s.after(sep) == s.partition(sep)
>
> Technically, these should probably be before_first and after_first, with
> the corresponding before_last and after_last corresponding to rpartition.
Do you really think these are easer than:
head, found, tail = s.partition('X',2)
I don't feel there is a need to avoid numbers entirely. In this case I
think it's the better way to find the n'th seperator and since it's an
optional value I feel it doesn't add a lot of complication. Anyway...
It's just a suggestion.
Cheers,
Ron
___
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] setdefault's second argument
On Tue, 30 Aug 2005 20:55:45 +0200, Tim Peters <[EMAIL PROTECTED]>
wrote:
> [Wolfgang Lipp]
>> reminds me of dict.get()... i think in both cases being explicit::
>>
>> beast = d.setdefault( 666, None )
>> ...
>
> Do you actually do this with setdefault()?
well, actually more like::
def f( x ): return x % 3
R = {}
for x in range( 30 ):
R.setdefault( f( x ), [] ).append( x )
still contrived, but you get the idea. i was really excited when finding
out
that d.pop, d.get and d.setdefault work in very much the same way in
respect
to the default argument, and my code has greatly benefitted from that. e.g.
def f( **Q ):
myoption = Q.pop( 'myoption', 42 )
if Q:
raise TypeError(...)
_w
___
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?)
At 07:54 PM 8/30/2005 +0200, Fredrik Lundh wrote: >Phillip J. Eby wrote: > > >>both split on a given token. partition splits once, and returns all three > >>parts, while piece returns the part you ask for > > > > No, because looking at that URL, there is no piece that is the token split > > on. partition() always returns 3 parts for 1 occurrence of the token, > > whereas $PIECE only has 2. > >so "absolutely nothing in common" has now turned into "does the >same thing but doesn't return the value you passed to it" ? $PIECE returns exactly one value. partition returns exactly 3. partition always returns the separator as one of the three values. $PIECE never does. How many more differences does it have to have before you consider them to be nothing alike? >sorry for wasting my time. And sorry for you being either illiterate or humor-impaired, to have missed the smiley on the sentence that said "absolutely nothing in common except having string arguments". You quoted it in your first reply, so it's not like it didn't make it into your email client. ___ 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] setdefault's second argument
On Tue, 2005-08-30 at 14:53, Fredrik Lundh wrote: > Some kind of symmetry with get, probably. if > > d.get(x) > > returns None if x doesn't exist, it makes some kind of sense that > > d.setdefault(x) I think that's right, and IIRC the specific detail about the optional second argument was probably hashed out in private Pythonlabs email, or over a tasty lunch of kung pao chicken. I don't have access to my private archives at the moment, though the public record seems to start about here: http://mail.python.org/pipermail/python-dev/2000-August/007819.html > Anyone remember why nobody managed to come up with a better name > for setdefault (which is probably the worst name ever given to a method > in the standard Python distribution) ? Heh. http://mail.python.org/pipermail/python-dev/2000-August/008059.html > (if I were in charge, I'd rename it to something more informative. Maybe like getorset() . Oh, and yeah, I don't care if we change .setdefault() to require its second argument -- I've never used it without one. But don't remove the method, it's quite handy. -Barry signature.asc Description: This is a digitally signed message part ___ 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] setdefault's second argument
[Fredrik Lundh]
> ...
> Anyone remember why nobody managed to come up with a better name
> for setdefault (which is probably the worst name ever given to a method
> in the standard Python distribution) ?
I suggested a perfect name at the time:
http://mail.python.org/pipermail/python-dev/2000-August/008036.html
To save you from following that link, to this day I still mentally
translate "setdefault" to "getorset" whenever I see it. That it
didn't get that name is probably Skip's fault, for whining that
"getorsetandget" would be "more accurate" . Actually, there's
no evidence that Guido noticed:
http://mail.python.org/pipermail/python-dev/2000-August/008059.html
> (if I were in charge, I'd rename it to something more informative. I'd also
> add a "join" built-in (similar to the good old string.join) and a "textfile"
> built-in (similar to open("U") plus support for encodings). but that's me. I
> want my code nice and tidy.)
I'm not sure who is in charge, but I am sure they can be bribed ;-)
___
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] Proof of the pudding: str.partition()
[Fredrik Lundh]
> it is, however, a bit worrying that you end up ignoring one or more
> of the values in about 50% of your examples...
It drops to about 25% when you skip the ones that don't care about the
found/not-found field:
> > ! _, sep, port = host.partition(':')
> > ! head, sep, _ = path.rpartition('/')
> > ! line, _, _ = line.partition(';') # strip
> > ! pname, found, _ = pname.rpartition('.')
> > ! line, _, _ = line.partition('#')
> > ! filename, _, _ = filename.partition(chr(0))
The remaining cases don't bug me much. They clearly say, ignore the
left piece or ignore the right piece. We could, of course, make these
clearer and more efficient by introducing more methods:
s.before(sep) --> (left, sep)
s.after(sep) --> (right, sep)
s.rbefore(sep) --> (left, sep)
s.r_after(sep) --> (right, sep)
But who wants all of that?
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] setdefault's second argument
Tim Peters wrote: >> Anyone remember why nobody managed to come up with a better name >> for setdefault (which is probably the worst name ever given to a method >> in the standard Python distribution) ? > > I suggested a perfect name at the time: > >http://mail.python.org/pipermail/python-dev/2000-August/008036.html > > To save you from following that link, to this day I still mentally > translate "setdefault" to "getorset" whenever I see it. from this day, I'll do that as well. I have to admit that I had to follow that link anyway, just to make sure I wasn't involved in the decision at that time (which I wasn't, from what I can tell). But I stumbled upon this little naming protocol Protocol: if you have a suggestion for a name for this function, mail it to me. DON'T MAIL THE LIST. (If you mail it to the list, that name is disqualified.) Don't explain me why the name is good -- if it's good, I'll know, if it needs an explanation, it's not good. which I thought was most excellent, and something that we might PEP:ify for future use, until I realized that it gave us the "worst name ever"... oh well. ___ 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] Proof of the pudding: str.partition()
Raymond Hettinger wrote:
> [Fredrik Lundh]
>
>>it is, however, a bit worrying that you end up ignoring one or more
>>of the values in about 50% of your examples...
>
> It drops to about 25% when you skip the ones that don't care about the
> found/not-found field:
>
>>>! _, sep, port = host.partition(':')
>>>! head, sep, _ = path.rpartition('/')
>>>! line, _, _ = line.partition(';') # strip
>>>! pname, found, _ = pname.rpartition('.')
>>>! line, _, _ = line.partition('#')
>>>! filename, _, _ = filename.partition(chr(0))
I know it's been discussed in the past, but this makes me wonder about
language support for "dummy" or "don't care" placeholders for tuple
unpacking. Would the above cases benefit from that, or (as has been
suggested in the past) should slicing be used instead?
Original:
_, sep, port = host.partition(':')
head, sep, _ = path.rpartition('/')
line, _, _ = line.partition(';')
pname, found, _ = pname.rpartition('.')
line, _, _ = line.partition('#')
Slicing:
sep, port = host.partition(':')[1:]
head, sep = path.rpartition('/')[:2]
line = line.partition(';')[0]
pname, found = pname.rpartition('.')[:2]
line = line.partition('#')[0]
I think I like the original better, but can't use "_" in my code because
it's used for internationalization.
--
Benji York
___
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] setdefault's second argument
On Tue, 2005-08-30 at 16:46, Fredrik Lundh wrote: > But I stumbled upon this little naming protocol > > Protocol: if you have a suggestion for a name for this function, mail > it to me. DON'T MAIL THE LIST. (If you mail it to the list, that > name is disqualified.) Don't explain me why the name is good -- if > it's good, I'll know, if it needs an explanation, it's not good. > > which I thought was most excellent, and something that we might PEP:ify > for future use, until I realized that it gave us the "worst name ever"... /And/ the rule was self-admittedly broken by Guido not a few posts after that one. ;) -Barry signature.asc Description: This is a digitally signed message part ___ 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] Revising RE docs (was: partition() (was: Remove str.find in 3.0?))
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 ___ 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] Revising RE docs (was: partition() (was: Remove str.find in 3.0?))
On Tuesday 30 August 2005 17:35, Michael Chermside wrote: > 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. Agreed. I think the current arrangement is primarily a historical accident more than anything else, but I didn't write that section, so could be wrong. > 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. I'd rather see it reversed from what it is as well. While I don't have the time myself (and don't consider it a critical issue), I certainly won't revert a patch to make the change without good reason. :-) -Fred -- Fred L. Drake, Jr. ___ 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] setdefault's second argument
[Tim Peters]
> Dang! I may have just found a use, in Zope's
> lib/python/docutils/parsers/rst/directives/images.py (which is part
> of docutils, not really part of Zope):
>
> figwidth = options.setdefault('figwidth')
> figclass = options.setdefault('figclass')
> del options['figwidth']
> del options['figclass']
If a feature is available, it *will* eventually be used!
Whose law is that?
> I'm still thinking about what that's trying to do <0.5 wink>.
The code needs to store the values of certain dict entries, then
delete them. This is because the "options" dict is passed on to
another function, where those entries are not welcome. The code above
is simply shorter than this:
if options.has_key('figwidth'):
figwidth = options['figwidth']
del options['figwidth']
# again for 'figclass'
Alternatively,
try:
figwidth = options['figwidth']
del options['figwidth']
except KeyError:
pass
It saves between one line and three lines of code per entry. But
since those entries are probably not so common, it would actually be
faster to use one of the above patterns.
> Assuming options is a dict-like thingie, it probably meant to do:
>
> figwidth = options.pop('figwidth', None)
> figclass = options.pop('figclass', None)
Yes, but the "pop" method was only added in Python 2.3. Docutils
currently maintains compatibility with Python 2.1, so that's RIGHT
OUT!
> David, are you married to that bizarre use of setdefault ?
No, not at all. In fact, I will vehemently deny that I ever wrote
such code, and will continue to do so until someone looks up its
history and proves that I'm guilty, which I probably am.
--
David Goodger
signature.asc
Description: OpenPGP digital signature
___
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] Proof of the pudding: str.partition()
Benji York wrote:
> Raymond Hettinger wrote:
>
>>[Fredrik Lundh]
>>
>>
>>>it is, however, a bit worrying that you end up ignoring one or more
>>>of the values in about 50% of your examples...
>>
>>It drops to about 25% when you skip the ones that don't care about the
>>found/not-found field:
>>
>>
! _, sep, port = host.partition(':')
! head, sep, _ = path.rpartition('/')
! line, _, _ = line.partition(';') # strip
! pname, found, _ = pname.rpartition('.')
! line, _, _ = line.partition('#')
! filename, _, _ = filename.partition(chr(0))
>
>
> I know it's been discussed in the past, but this makes me wonder about
> language support for "dummy" or "don't care" placeholders for tuple
> unpacking. Would the above cases benefit from that, or (as has been
> suggested in the past) should slicing be used instead?
>
> Original:
> _, sep, port = host.partition(':')
> head, sep, _ = path.rpartition('/')
> line, _, _ = line.partition(';')
> pname, found, _ = pname.rpartition('.')
> line, _, _ = line.partition('#')
>
> Slicing:
> sep, port = host.partition(':')[1:]
> head, sep = path.rpartition('/')[:2]
> line = line.partition(';')[0]
> pname, found = pname.rpartition('.')[:2]
> line = line.partition('#')[0]
>
> I think I like the original better, but can't use "_" in my code because
> it's used for internationalization.
> --
> Benji York
For cases where single values are desired, attribues could work.
Slicing:
line = line.partition(';').head
line = line.partition('#').head
But it gets awkward as soon as you want more than one.
sep, port = host.partition(':').head, host.partition(':').sep
Ron
___
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] Proof of the pudding: str.partition()
Ron Adam wrote:
> For cases where single values are desired, attribues could work.
>
> Slicing:
> line = line.partition(';').head
> line = line.partition('#').head
>
> But it gets awkward as soon as you want more than one.
>
> sep, port = host.partition(':').head, host.partition(':').sep
You can do both: make partition() return a sequence with attributes,
similar to os.stat(). However, I would call the attributes "before",
"sep", and "after".
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] Proof of the pudding: str.partition()
Shane Hathaway wrote:
> Ron Adam wrote:
>> For cases where single values are desired, attribues could work.
>>
>> Slicing:
>> line = line.partition(';').head
>> line = line.partition('#').head
>>
>> But it gets awkward as soon as you want more than one.
>>
>> sep, port = host.partition(':').head, host.partition(':').sep
>
> You can do both: make partition() return a sequence with attributes,
> similar to os.stat(). However, I would call the attributes "before",
> "sep", and "after".
+0
I thought the same thing. I don't see a lot of use cases for it, but it
could be useful. I don't see how it could hurt.
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] Proof of the pudding: str.partition()
Ron Adam wrote:
> For cases where single values are desired, attribues could work.
>
> Slicing:
>line = line.partition(';').head
>line = line.partition('#').head
>
> But it gets awkward as soon as you want more than one.
>
>sep, port = host.partition(':').head, host.partition(':').sep
unless you go for the piece approach
host, port = host.piece(":", 1, 2)
(which, of course, is short for
host, port = host.piece(":").group(1, 2)
)
and wait for Mr Eby to tell you that piece has nothing whatsoever
to do with string splitting.
___
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] Proof of the pudding: str.partition()
I once wrote a similar method called cleave(). My use case involved a string-like class (Substr) whose instances could report their position in the original string. The re module wasn't preserving my class so I had to provide a different API. def cleave(self, pattern, start=0): """return Substr until match, match, Substr after match If there is no match, return Substr, None, '' """ Here are some observations/questions on Raymond's partition() idea. First of all, partition() is a much better name than cleave()! Substr didn't copy as partition() will have to, won't many of uses of partition() end up being O(N^2)? One way that gives the programmer a way avoid the copying would be to provide a string method findspan(). findspan() would returns the start and end of the found position in the string. start > end could signal no match; and since 0-character strings are disallowed in partition, end == 0 could also signal no match. partition() could be defined in terms of findspan(): start, end = s.findspan(sep) before, sep, after = s[:start], s[start:end], s[end:] Just a quick thought, -Tony ___ 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?)
JustFillBug wrote: > trisplit() And then for when you need to record the result somewhere, tricord(). :-) -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Proof of the pudding: str.partition()
[EMAIL PROTECTED] wrote:
> Substr didn't copy as partition() will have to, won't many of uses of
> partition() end up being O(N^2)?
Yes. But if you look at most cases provided for in the standard library,
that isn't an issue. In the case where it becomes an issue, it is
generally because a user wants to do repeated splitting on the same
token...which is better suited for str.split or re.split.
> One way that gives the programmer a way avoid the copying would be to
> provide a string method
> findspan(). findspan() would returns the start and end of the found
> position in the string. start >
> end could signal no match; and since 0-character strings are disallowed in
> partition, end == 0
> could also signal no match. partition() could be defined in terms of
> findspan():
> start, end = s.findspan(sep)
> before, sep, after = s[:start], s[start:end], s[end:]
Actually no. When str.parition() doesn't find the separator, you get s, '',
''.
Yours would produce '', '', s. On not found, you would need to use
start==end==len(s).
Further, findspan could be defined in terms of find...
def findspan(s, sep):
if len(sep) == 0:
raise ValueError("null separator strings are not allowed")
x = s.find(sep)
if x >= 0:
return x, x+len(sep)
return len(s),len(s)
Conceptually they are all the same. The trick with partition is that in
the vast majority of use cases, one wants 2 or 3 of the resulting
strings, and constructing the strings in the C-level code is far faster
than manually slicing (which can be error prone). I will say the same
thing that I've said at least three times already (with a bit of an
expansion):
IF YOU ARE GOING TO PROPOSE AN ALTERNATIVE, SHOW SOME
COMPARATIVE CODE SAMPLES WHERE YOUR PROPOSAL DEFINITELY
WINS OVER BOTH str.find AND str.partition. IF YOU CAN'T
PROVIDE SUCH SAMPLES, THEN YOUR PROPOSAL ISN'T BETTER,
AND YOU PROBABLY SHOULDN'T PROPOSE IT. bonus points for
those who take the time to compare all of those that
Raymond provided.
- 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] partition() (was: Remove str.find in 3.0?)
Nick Coghlan wrote: > Another option would be simply "str.part()" and "str.rpart()". Then you could > think of it as an abbreviation of either 'partition' or 'parts' depending on > your inclination. Or simply as the verb 'part', which also makes sense! Also it's short and snappy, whereas 'partition' seems rather too long-winded for such a useful little function. -- Greg Ewing, Computer Science Dept, +--+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | [EMAIL PROTECTED] +--+ ___ 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] Proof of the pudding: str.partition()
> Actually no. When str.parition() doesn't find the separator, you get s, > '', ''. > Yours would produce '', '', s. On not found, you would need to use > start==end==len(s). > You're right. Nevermind, then. > I will say the same > thing that I've said at least three times already (with a bit of an > expansion): > Thanks for the re-re-emphasis. -Tony ___ 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?
On 8/31/05, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> [Hye-Shik Chang]
> > What would be a result for rpartition(s, '?') ?
> > ('', '', 'http://www.python.org')
> > or
> > ('http://www.python.org', '', '')
>
> The former. The invariants for rpartition() are a mirror image of those
> for partition().
Just to put my spoke in the wheel, I find the difference in the
ordering of return values for partition() and rpartition() confusing:
head, sep, remainder = partition(s)
remainder, sep, head = rpartition(s)
My first expectation for rpartition() was that it would return exactly
the same values as partition(), but just work from the end of the
string.
IOW, I expected "www.python.org".partition("python") to return exactly
the same as "www.python.org".rpartition("python")
To try out partition(), I wrote a quick version of split() using
partition, and using partition() was obvious and easy:
def mysplit(s, sep):
l = []
while s:
part, _, s = s.partition(sep)
l.append(part)
return l
I tripped up when trying to make an rsplit() (I'm using Python 2.3),
because the return values were in "reverse order"; I had expected the
only change to be using rpartition() instead of partition().
For a second example: one of the "fixed stdlib" examples that Raymond
posted actually uses rpartition and partition in two consecutive lines
-- I found this example not immediately obvious for the above reason:
def run_cgi(self):
"""Execute a CGI script."""
dir, rest = self.cgi_info
rest, _, query = rest.rpartition('?')
script, _, rest = rest.partition('/')
scriptname = dir + '/' + script
scriptfile = self.translate_path(scriptname)
if not os.path.exists(scriptfile):
Anyway, I'm definitely +1 on partition(), but -1 on rpartition()
returning in "reverse order".
Andrew
___
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?
Andrew Durdin wrote:
> Just to put my spoke in the wheel, I find the difference in the
> ordering of return values for partition() and rpartition() confusing:
>
> head, sep, remainder = partition(s)
> remainder, sep, head = rpartition(s)
This is the confusion - you've got the terminology wrong.
before, sep, after = s.partition('?')
('http://www.python.org', '', '')
before, sep, after = s.rpartition('?')
('', '', 'http://www.python.org')
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?
On 8/31/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Andrew Durdin wrote:
>
> > Just to put my spoke in the wheel, I find the difference in the
> > ordering of return values for partition() and rpartition() confusing:
> >
> > head, sep, remainder = partition(s)
> > remainder, sep, head = rpartition(s)
>
> This is the confusion - you've got the terminology wrong.
>
> before, sep, after = s.partition('?')
> ('http://www.python.org', '', '')
>
> before, sep, after = s.rpartition('?')
> ('', '', 'http://www.python.org')
That's still confusing (to me), though -- when the string is being
processed, what comes before the separator is the stuff at the end of
the string, and what comes after is the bit at the beginning of the
string. It's not the terminology that's confusing me, though I find
it hard to describe exactly what is. Maybe it's just me -- does anyone
else have the same confusion?
___
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?
On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> On 8/31/05, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> > Andrew Durdin wrote:
> >
> > > Just to put my spoke in the wheel, I find the difference in the
> > > ordering of return values for partition() and rpartition() confusing:
> > >
> > > head, sep, remainder = partition(s)
> > > remainder, sep, head = rpartition(s)
> >
> > This is the confusion - you've got the terminology wrong.
> >
> > before, sep, after = s.partition('?')
> > ('http://www.python.org', '', '')
> >
> > before, sep, after = s.rpartition('?')
> > ('', '', 'http://www.python.org')
>
> That's still confusing (to me), though -- when the string is being
> processed, what comes before the separator is the stuff at the end of
> the string, and what comes after is the bit at the beginning of the
> string. It's not the terminology that's confusing me, though I find
> it hard to describe exactly what is. Maybe it's just me -- does anyone
> else have the same confusion?
Hm. The example is poorly chosen because it's an end case. The
invariant for both is (I'd hope!)
"".join(s.partition()) == s == "".join(s.rpartition())
Thus,
"a/b/c".partition("/") returns ("a", "/", "b/c")
"a/b/c".rpartition("/") returns ("a/b", "/", "c")
That can't be confusing can it?
(Just think of it as rpartition() stopping at the last occurrence,
rather than searching from the right. :-)
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
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?
On 8/31/05, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Hm. The example is poorly chosen because it's an end case. The > invariant for both is (I'd hope!) > > "".join(s.partition()) == s == "".join(s.rpartition()) > (Just think of it as rpartition() stopping at the last occurrence, > rather than searching from the right. :-) Ah, that makes a difference. I could see that there was a different way of looking at the function, I just couldn't see what it was... Now I understand the way it's been done. Cheers, Andrew. ___ 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] Proof of the pudding: str.partition()
At 01:05 AM 8/31/2005 +0200, Fredrik Lundh wrote:
>Ron Adam wrote:
>
> > For cases where single values are desired, attribues could work.
> >
> > Slicing:
> >line = line.partition(';').head
> >line = line.partition('#').head
> >
> > But it gets awkward as soon as you want more than one.
> >
> >sep, port = host.partition(':').head, host.partition(':').sep
>
>unless you go for the piece approach
>
> host, port = host.piece(":", 1, 2)
>
>(which, of course, is short for
>
> host, port = host.piece(":").group(1, 2)
>
>)
>
>and wait for Mr Eby to tell you that piece has nothing whatsoever
>to do with string splitting.
No, just to point out that you can make up whatever semantics you want, but
the semantics you show above are *not* the same as what are shown at the
page the person who posted about $PIECE cited, and on whose content I based
my reply:
http://www.jacquardsystems.com/Examples/function/piece.htm
If you were following those semantics, then the code you presented above is
buggy, as host.piece(':',1,2) would return the original string!
Of course, since I know nothing of MUMPS besides what's on that page, it's
entirely possible I've misinterpreted that page in some hideously subtle
way -- as I pointed out in my original post regarding $PIECE. I like to
remind myself and others of the possibility that I *could* be wrong, even
when I'm *certain* I'm right, because it helps keep me from appearing any
more arrogant than I already do, and it also helps to keep me from looking
too stupid in those cases where I turn out to be wrong. Perhaps you might
find that approach useful as well.
In any case, to avoid confusion, you should probably specify the semantics
of your piece() proposal in Python terms, so that those of us who don't
know MUMPS have some possibility of grasping the inner mysteries of your
proposal.
___
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?
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Terry Reedy wrote: >> One (1a) is to give an inband signal that is like a normal >> response except that it is not (str.find returing -1). >> >> Python as distributed usually chooses 1b or 2. >> I believe str.find and >> .rfind are unique in the choice of 1a. > > That is not true. str.find's choice is not 1a, It it the paradigm example of 1a as I meant my definition. > -1 does *not* look like a normal response, > since a normal response is non-negative. Actually, the current doc does not clearly specify to some people that the response is a count. That is what lead to the 'str.find is buggy' thread on c.l.p, and something I will clarify when I propose a doc patch. In any case, Python does not have a count type, though I sometime wish it did. The return type is int and -1 is int, though it is not meant to be used as an int and it is a bug to do so. >It is *not* the only method with choice 1a): > dict.get returns None if the key is not found, None is only the default default, and whatever the default is, it is not necessarily an error return. A dict accessed via .get can be regarded as an infinite association matching all but a finite set of keys with the default. Example: a doubly infinite array of numbers with only a finite number of non-zero entries, implemented as a dict. This is the view actually used if one does normal calculations with that default return. There is no need, at least for that access method, for any key to be explicitly associated with the default. If the default *is* regarded as an error indicator, and is only used to guard normal processing of the value returned, then that default must not be associated any key. There is the problem that the domain of dict values is normally considered to be any Python object and functions can only return Python objects and not any non-Python-object error return. So the effective value domain for the particular dict must be the set 'Python objects' minus the error indicator. With discipline, None often works. Or, to guarantee 1b-ness, one can create a new type that cannot be in the dict. > For another example, file.read() returns an empty string at EOF. If the request is 'give me the rest of the file as a string', then '' is the answer, not a 'cannot answer' indicator. Similarly, if the request is 'how many bytes are left to read', then zero is a numerical answer, not a non-numerical 'cannot answer' indicator. Terry J. Reedy ___ 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?
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote in message
> before, sep, after = s.partition('?')
> ('http://www.python.org', '', '')
>
> before, sep, after = s.rpartition('?')
> ('', '', 'http://www.python.org')
I can also see this as left, sep, right, with the sep not found case
putting all in left or right depending on whether one scanned to the right
or left. In other words, when the scanner runs out of chars to scan,
everything is 'behind' the scan, where 'behind' depends on the direction of
scanning. That seems nicely symmetric.
Terry J. Reedy
___
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] Revising RE docs (was: partition() (was: Removestr.find in 3.0?))
"Fred L. Drake, Jr." <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > I'd rather see it reversed from what it is as well. While I don't have > the > time myself (and don't consider it a critical issue), I certainly won't > revert a patch to make the change without good reason. :-) Do you mean 'not reject' rather than 'not revert'? Terry J. Reedy ___ 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] Proof of the pudding: str.partition()
Fredrik Lundh wrote:
> Ron Adam wrote:
>
>
>>For cases where single values are desired, attribues could work.
>>
>>Slicing:
>> line = line.partition(';').head
>> line = line.partition('#').head
>>
>>But it gets awkward as soon as you want more than one.
>>
>> sep, port = host.partition(':').head, host.partition(':').sep
>
>
> unless you go for the piece approach
>
> host, port = host.piece(":", 1, 2)
>
> (which, of course, is short for
>
> host, port = host.piece(":").group(1, 2)
>
> )
I'm not familiar with piece, but it occurred to me it might be useful to
get attributes groups in some way. My first (passing) thought was to do...
host, port = host.partition(':').(head, sep)
Where that would be short calling a method to return them:
host, port = host.partition(':').getattribs('head','sep')
But with only three items, the '_' is in the category of "Looks kind of
strange, but I can get used to it because it works well.".
Cheers,
Ron
___
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?
Guido van Rossum wrote:
> On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
[confusion]
>
>
> Hm. The example is poorly chosen because it's an end case. The
> invariant for both is (I'd hope!)
>
> "".join(s.partition()) == s == "".join(s.rpartition())
>
> Thus,
>
> "a/b/c".partition("/") returns ("a", "/", "b/c")
>
> "a/b/c".rpartition("/") returns ("a/b", "/", "c")
>
> That can't be confusing can it?
>
> (Just think of it as rpartition() stopping at the last occurrence,
> rather than searching from the right. :-)
>
So we can check that a substring x appears precisely once in the string
s using
s.partition(x) == s.rpartition(x)
Oops, it fails if s == "". I can usually find some way to go wrong ...
tongue-in-cheek-ly y'rs - steve
--
Steve Holden +44 150 684 7255 +1 800 494 3119
Holden Web LLC http://www.holdenweb.com/
___
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] Proof of the pudding: str.partition()
"Shane Hathaway" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > You can do both: make partition() return a sequence with attributes, > similar to os.stat(). However, I would call the attributes "before", > "sep", and "after". One could see that as a special-case back-compatibility kludge that maybe should disappear in 3.0. My impression is that the attributes were added precisely because unpacking several related attributes into several disconnected vars was found to be often awkward. The sequencing is arbitrary and one often needs less that all attributes. Terry J. Reedy ___ 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] Proof of the pudding: str.partition()
Terry Reedy wrote: > "Shane Hathaway" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > >>You can do both: make partition() return a sequence with attributes, >>similar to os.stat(). However, I would call the attributes "before", >>"sep", and "after". > > > One could see that as a special-case back-compatibility kludge that maybe > should disappear in 3.0. My impression is that the attributes were added > precisely because unpacking several related attributes into several > disconnected vars was found to be often awkward. The sequencing is > arbitrary and one often needs less that all attributes. Good point. Unlike os.stat(), it's very easy to remember the order of the return values from partition(). I'll add my +1 vote for part() and +0.9 for partition(). As for the regex version of partition(), I wonder if a little cleanup effort is in order so that new regex features don't have to be added in two places. I suggest a builtin for compiling regular expressions, perhaps called "regex". It would be easier to use the builtin than to import the re module, so there would no longer be a reason for the re module to have functions that duplicate the regular expression methods. 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] Remove str.find in 3.0?
Steve Holden <[EMAIL PROTECTED]> wrote:
>
> Guido van Rossum wrote:
> > On 8/30/05, Andrew Durdin <[EMAIL PROTECTED]> wrote:
> [confusion]
> >
> >
> > Hm. The example is poorly chosen because it's an end case. The
> > invariant for both is (I'd hope!)
> >
> > "".join(s.partition()) == s == "".join(s.rpartition())
> >
> > Thus,
> >
> > "a/b/c".partition("/") returns ("a", "/", "b/c")
> >
> > "a/b/c".rpartition("/") returns ("a/b", "/", "c")
> >
> > That can't be confusing can it?
> >
> > (Just think of it as rpartition() stopping at the last occurrence,
> > rather than searching from the right. :-)
> >
> So we can check that a substring x appears precisely once in the string
> s using
>
> s.partition(x) == s.rpartition(x)
>
> Oops, it fails if s == "". I can usually find some way to go wrong ...
There was an example in the standard library that used "s.find(y) ==
s.rfind(y)" as a test for zero or 1 instances of the searched for item.
Generally though, s.count(x)==1 is a better test.
- 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
