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 == "
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
"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-compatibilit
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("/"
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.p
"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. :-)
"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 al
""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
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
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,
> ra
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:
> > >
>
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
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, 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 part
> 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
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 'part
[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
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
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 Su
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.partiti
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, host.pa
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:
>>
>
[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']
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 t
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 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
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.p
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/
[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(':')
> > ! hea
[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-
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
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. p
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::
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
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 wa
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 u
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 toke
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
[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
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 suggest
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
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 g
[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 functi
[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 thi
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.pytho
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 funct
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 lik
>> 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
Py
>> 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 pattern
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 var
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 i
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
P
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 r
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 curr
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 S
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
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
>
>
[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 sec
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, s
[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 c
[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 assigne
[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.h
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. T
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 actual
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
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 argume
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 in
> 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
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
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 par
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 !
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
> > c
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
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
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 partit
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,
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]
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-de
(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
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 (th
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
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" v
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
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 rea
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,
b
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 t
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
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 t
"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 fa
90 matches
Mail list logo
