"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > The seemingly proposed textobj(start:stop) returning a view is not
> > terribly intuitive, as () and [] aren't so terribly different from
> > each other to not confuse someone initially.
>
> Nor {} as I proposed
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 8/27/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > [1] When I say "tree persistance", I mean those cases like a -> b -> c,
> > where view b persist because view a persists, even though b doesn't have
> > a reference otherwise. Making both
Josiah Carlson wrote:
> If one wants a view of text, one needs to manually
> construct the view via 'view = textview(st, start, stop)' or some
> equivalent spelling. After that, any operations on a view returns views
Given Guido's sensitivity about potential misuses of
views, it might be better i
Josiah Carlson wrote:
> The seemingly proposed textobj(start:stop) returning a view is not
> terribly intuitive, as () and [] aren't so terribly different from
> each other to not confuse someone initially.
Nor {} as I proposed for that matter ;)
Tim Delaney
_
Jim Jewett wrote:
> On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > Any object? And how is that supposed to work for arbitrary
> > objects?
>
> For non-iterables, it will raise a TypeError.
I think the question was what benefit would there be
in a general slice-view object which knew
"Delaney, Timothy (Tim)" <[EMAIL PROTECTED]> wrote:
>
> Jim Jewett wrote:
>
> > On 8/27/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> >> Jim Jewett wrote:
> >
> >>> s[start:stop].find(prefix)
> >
> >> No matter what, I really think the obj[start:stop:step]
> >> syntax needs to be
On 8/27/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>
> > > For example, you wanted to keep the rarely used optional arguments to
> > > find because of efficiency.
>
> > I don't believe the
Jim Jewett wrote:
> On 8/27/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
>> Jim Jewett wrote:
>
>>> s[start:stop].find(prefix)
>
>> No matter what, I really think the obj[start:stop:step]
>> syntax needs to be consistent in its behaviour - either
>> returning a copy or a view -
>
>
On 8/27/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> Jim Jewett wrote:
> > s[start:stop].find(prefix)
> No matter what, I really think the obj[start:stop:step]
> syntax needs to be consistent in its behaviour - either
> returning a copy or a view -
Does it still matter if we're lo
Jim Jewett wrote:
> s[start:stop].find(prefix)
No matter what, I really think the obj[start:stop:step] syntax needs to
be consistent in its behaviour - either returning a copy or a view - and
that that behaviour be to return a copy. I'm not at all in favour of
sometimes getting a copy, and so
On 8/27/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > For example, you wanted to keep the rarely used optional arguments to
> > find because of efficiency.
> I don't believe they are rarely used. They are (currently) essential
> for code t
On 8/27/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> What is with the sudden rush to solve all problems by using slice objects?>
> I've never used a slice object and I don't care to start now. The above code
> reads just fine as
>
> i = s.find('\n', start, stop)
> if i >= 0:
> yield s[:i]
H
On 8/27/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> [1] When I say "tree persistance", I mean those cases like a -> b -> c,
> where view b persist because view a persists, even though b doesn't have
> a reference otherwise. Making both views a and b reference c directly
> allows for b to be fr
On Mon, Aug 28, 2006 at 01:37:59AM +1000, Nick Coghlan wrote:
> Jack Diederich wrote:
> > On Sat, Aug 26, 2006 at 07:51:03PM -0700, Guido van Rossum wrote:
> >> On 8/26/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
> >>> After some benchmarking find() can't go away without really hurting
> >>> rea
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> On 8/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > "Jim Jewett" <[EMAIL PROTECTED]> wrote:
> > > With stringviews, you wouldn't need to be reindexing from the start of
> > > the original string. The idiom would instead be a generalizat
On 8/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > Can you explain in a sentence or two how these changes would be
> > *used*? Your code examples don't speak for themselves (maybe because
> > It's Saturday morning :-). Short examples of something clumsy and/or
> > slo
On 8/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Jim Jewett" <[EMAIL PROTECTED]> wrote:
> > With stringviews, you wouldn't need to be reindexing from the start of
> > the original string. The idiom would instead be a generalization of
> > "for line in file:"
> >
> > while data:
> >
On 8/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> > > As I understand it, Nick is suggesting that slice
> > > objects be used as a sequence (not just string)
> > > view.
>
> > I have a hard time parsing this sentence. A slice is
> > an object with three immutable attributes -- start,
> > stop, st
Nick Coghlan <[EMAIL PROTECTED]> wrote:
[snip]
> that isn't likely to trigger an obvious error. It also breaks the persistent
> idiom that "seq[:]" makes a copy (which is true throughout the standard
> library, even if it isn't true for external number-crunching libraries like
> NumPy).
The co
Jack Diederich wrote:
> On Sat, Aug 26, 2006 at 07:51:03PM -0700, Guido van Rossum wrote:
>> On 8/26/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
>>> After some benchmarking find() can't go away without really hurting
>>> readline()
>>> performance.
>> Can you elaborate? readline() is typically i
Guido van Rossum wrote:
> Can you explain in a sentence or two how these changes would be
> *used*? Your code examples don't speak for themselves (maybe because
> It's Saturday morning :-). Short examples of something clumsy and/or
> slow that we'd have to write today compared to something fast and
Jim Jewett wrote:
> On 8/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> On 8/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
>> > As I understand it, Nick is suggesting that slice
>> > objects be used as a sequence (not just string)
>> > view.
>
>> I have a hard time parsing this sentence. A s
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
>
> On 8/26/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> > > There are a couple of existing workarounds for
> > > this: buffer() objects, and the start/stop arguments
> > > to a variety of string methods. Ne
23 matches
Mail list logo
