Josiah Carlson wrote:
> One of the issues with the -1 return on find failure is that it is
> ambiguous, one must really check for a -1 return. Here's an API that is
> non-ambiguous:
An alternative would be to return None for not found.
It wouldn't solve the problem of people using the
return valu
On Wed, 23 Aug 2006, Greg Ewing wrote:
> Josiah Carlson wrote:
>
>> One of the issues with the -1 return on find failure is that it is
>> ambiguous, one must really check for a -1 return. Here's an API that is
>> non-ambiguous:
>
> An alternative would be to return None for not found.
> It wouldn'
Guido van Rossum wrote:
> At today's sprint, one of the volunteers completed a patch to rip out
> find() and rfind(), replacing all calls with index()/rindex(). But now
> I'm getting cold feet -- is this really a good idea? (It's been listed
> in PEP 3100 for a long time, but I haven't thought abou
I agree with Tim -- if we have to get rid of one of them, let's get
rid of index/rindex and keep find/rfind. Catching the exception is
much less convenient than testing for -1.
-Barry
___
Python-3000 mailing list
[email protected]
http://mail.
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I agree with Tim -- if we have to get rid of one of them, let's get
> rid of index/rindex and keep find/rfind. Catching the exception is
> much less convenient than testing for -1.
But the -1 is very error-prone, as many have experienced. Also
On 8/23/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > I agree with Tim -- if we have to get rid of one of them, let's get
> > rid of index/rindex and keep find/rfind. Catching the exception is
> > much less convenient than testing for -1.
On Wed, Aug 23, 2006 at 07:20:54AM -0700, Guido van Rossum wrote:
> in py3k I
> want to rip out lots of "harmless" to make the language smaller. A
> smaller language is also a feature, and a very important one -- a
> frequent complaint I hear is that over time the language has lost some
> of its or
That's too narrow a view on the language. Surely the built-in types
(especially those with direct compiler support, like literal
notations) are part of the language. The people who complain most
frequently about Python getting too big aren't language designers,
they are users (e.g. scientists) and
On Wed, Aug 23, 2006 at 08:18:03AM -0700, Guido van Rossum wrote:
> That's too narrow a view on the language.
I narrowed it by purpose for this discussion.
> Surely the built-in types
> (especially those with direct compiler support, like literal
> notations) are part of the language.
And
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Wed, 23 Aug 2006 08:18:03 -0700
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> That's too narrow a view on the language. Surely the built-in types
> (especially those with direct compiler support, like literal
> notations) are part of the language
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Where it comes to the library, I think we ought to concentrate on
> reducing duplication. TOOWTDI. Get rid of the User* modules.
Generally a good idea, but we still need somewhere to put DictMixin.
It's too bad you can't just use the unbound
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> Where it comes to the library, I think we ought to concentrate on
> reducing duplication. TOOWTDI. Get rid of the User* modules.
Until it is possible to inherit from multiple extension types, there
will be a need to mimic inheritance with del
On Wed, 23 Aug 2006, John J Lee wrote:
[...]
>> An alternative would be to return None for not found.
>> It wouldn't solve the problem of people using the
>> return value as a boolean, but at least you'd get
>> an exception if you tried to use the not-found value
>> as an index.
>>
>> Or maybe it c
On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> I agree with Tim -- if we have to get rid of one of them, let's get
> rid of index/rindex and keep find/rfind. Catching the exception is
> much less convenient than testing for -1.
Could you post a simple example or two? I keep imagining thin
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
>
> On 8/23/06, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> > I agree with Tim -- if we have to get rid of one of them, let's get
> > rid of index/rindex and keep find/rfind. Catching the exception is
> > much less convenient than testing for -1.
>
> Co
Steven Bethard wrote:
> Could you post a simple example or two?
Josiah Carlson wrote:
> index = text.find(...)
> if index >= 0:
> ...
>
[snip]
> index = 0
> while 1:
> index = text.find(..., index)
> if index == -1:
> break
> ...
>
Thank
Just throwing it out but what about something like:found, index = text.index("abc")if found: doSomething(index)If you were confident that the index was in there you would do something more like this:
something = text[text.index("abc")[1]:](although there are clearer ways to do that)On 8/23/06, St
Steven Bethard wrote:
> Steven Bethard wrote:
>> Could you post a simple example or two?
>
> Josiah Carlson wrote:
>> index = text.find(...)
>> if index >= 0:
>> ...
>>
> [snip]
>> index = 0
>> while 1:
>> index = text.find(..., index)
>> if index == -1:
>>
Paul Prescod wrote:
> Just throwing it out but what about something like:
>
> found, index = text.index("abc")
>
> if found:
>doSomething(index)
-1. str.index()'s semantics should not be different from list.index().
Georg
___
Python-3000 mailing
"Steven Bethard" <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
> > Could you post a simple example or two?
>
> Josiah Carlson wrote:
> > index = text.find(...)
> > if index >= 0:
> > ...
> >
> [snip]
> > index = 0
> > while 1:
> > index = text.find(..., index)
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> And yet offense is taken. Have you watched the video of my Py3k talk?
> Search for it on Google Video.
I spent some time yesterday and watched it. All I was proposing is that
similar to Perl 5 and 6, users of Python 2.x may not feel an
overwhelmin
On 8/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> or even
>
> index = 0
> while 1:
> index = text.find(..., index)
> if index == -1:
> break
> ...
> compared with
>
> index = 0
> while 1:
> try:
> index = text.index(...,
On Wed, Aug 23, 2006 at 02:18:59PM -0700, Guido van Rossum wrote:
> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> modify stringobject.c or unicodeobject.c. It doesn't use
> [r]partition()'; someone could l
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> modify stringobject.c or unicodeobject.c. It doesn't use
> [r]partition()'; someone could look for opportuniti
"BJörn Lindqvist" <[EMAIL PROTECTED]> wrote:
>
> On 8/23/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > or even
> >
> > index = 0
> > while 1:
> > index = text.find(..., index)
> > if index == -1:
> > break
> > ...
> > compared with
> >
> > in
On 23/08/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
...that looks to have been done by a script, it has inconsistant stylecompared to the code it replaces, etc.I made the minimal change that implements the functionality suggested, in terms of find/rfind, they return -1. The least painful way to
Josiah Carlson wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
>> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
>> modify stringobject.c or unicodeobject.c. It doesn't use
>> [r]partition()'; someone
Georg Brandl <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> >> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> >> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> >> modify stringobject.c or unico
"Hasan Diwan" <[EMAIL PROTECTED]> wrote:
> On 23/08/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > ...that looks to have been done by a script, it has inconsistant style
> > compared to the code it replaces, etc.
> >
>
> I made the minimal change that implements the functionality suggested
"Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> The intent of my post was to say that all of us want Py3k to succeed,
I should hope that we all do.
> but I believe that in order for it to succeed that breakage from the 2.x
> series should be gradual, in a similar
"Brian Holmes" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
>Even after reading Terry Reedy's arguments, I don't see why we need to
> >remove this option.
Since this is my first post in this current thread, you either meant
someone else or are remembering my posts about in- and
On Wed, Aug 23, 2006 at 02:18:59PM -0700, Guido van Rossum wrote:
> Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> modify stringobject.c or unicodeobject.c. It doesn't use
> [r]partition()'; someone could l
On 8/23/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
> 2. change find()'s error return to None, and remove index();
+1
It is particularly unfortunate that the error code of -1 is a valid index.
>>> substring = string[string.find(marker):]
will silently produce garbage.
> or possibly conside
Josiah Carlson wrote:
> Given search as a potential replacement, about the only question is
> whether count should default to sys.maxint or 1.
Do you think that there will be many use cases for
count values *other* than 1 or sys.maxint? If not,
it might be more sensible to have two functions,
sea
Nick Coghlan wrote:
> I also like Josiah's idea of replacing find() with a search() method
> that returned an iterator of indices, so that you can do:
>
> for idx in string.search(sub):
> # Process the indices (if any)
Need to be careful with this - the original search proposal returned a
li
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote:
>
> Nick Coghlan wrote:
>
> > I also like Josiah's idea of replacing find() with a search() method
> > that returned an iterator of indices, so that you can do:
> >
> > for idx in string.search(sub):
> > # Process the indices (if any)
>
>
"Terry Reedy" <[EMAIL PROTECTED]> wrote:
> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
> news:[EMAIL PROTECTED]
> > The intent of my post was to say that all of us want Py3k to succeed,
>
> I should hope that we all do.
>
> > but I believe that in order for it to succeed that breakage
Zitat von Josiah Carlson <[EMAIL PROTECTED]>:
> > To the contrary, you seem to have a basic disagreement with the plan to
> > make all the core language changes at once and to clear the decks of old
> > baggage so we can move forward with a learner language that is a bit easier
> > to learn and re
I don't find the current attempts to come up with a better substring
search API useful.
We did a lot of thinking about this not too long ago, and the result
was the addition of [r]partition() to 2.5 and the intent to drop
[r]find() from py3k as both redundant with [r]index() and error-prone
(I thi
On 8/23/06, Terry Reedy <[EMAIL PROTECTED]> wrote:
"Brian Holmes" <[EMAIL PROTECTED]> wrote in messagenews:[EMAIL PROTECTED]>Even after reading Terry Reedy's arguments, I don't see why we need to
> >remove this option.Since this is my first post in this current thread, you either meantsomeone else
Josiah Carlson wrote:
> "Terry Reedy" <[EMAIL PROTECTED]> wrote:
>> "Josiah Carlson" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> The intent of my post was to say that all of us want Py3k to succeed,
>> I should hope that we all do.
>>
>>> but I believe that in order for it t
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > Given search as a potential replacement, about the only question is
> > whether count should default to sys.maxint or 1.
>
> Do you think that there will be many use cases for
> count values *other* than 1 or sys.maxint? If not,
>
[EMAIL PROTECTED] wrote:
>
> Zitat von Josiah Carlson <[EMAIL PROTECTED]>:
>
> > > To the contrary, you seem to have a basic disagreement with the plan to
> > > make all the core language changes at once and to clear the decks of old
> > > baggage so we can move forward with a learner language t
On 8/23/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> On Wed, Aug 23, 2006 at 02:18:59PM -0700, Guido van Rossum wrote:
> > Here's the patch (by Hasan Diwan, BTW) for people's perusal. It just
> > gets rid of all *uses* of find/rfind from Lib; it doesn't actually
> > modify stringobject.c or unic
44 matches
Mail list logo
