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
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
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
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
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
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
(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
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
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,
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()
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
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
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
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
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
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
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
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
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
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
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
[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
[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
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
[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
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
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
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
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
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()...
wink
Skip
___
Python-Dev mailing list
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,
[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
[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
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
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
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
[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 =
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
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,
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
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()
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
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:
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 =
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.
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
[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']
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 =
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 =
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,
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
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
[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
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'
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
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().
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.
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 =
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,
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())
snip
(Just think of it as rpartition() stopping at the last occurrence,
rather
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.
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
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
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
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,
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, /,
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
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
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())
69 matches
Mail list logo
