"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:
> chunk, sep, data = data.partition()
>
> but the partition ca
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 implemented in C so I'm
On 8/26/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/26/06, 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,
It is not my intention to adopt the Path module in Py3k.
On 8/26/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> In Py3K, is it still safe to assume that a list of paths will be
> (enough like) ordinary strings?
>
> I ask because of the various Path object discussions; it wasn't clear
> that a Path ob
On 8/26/06, 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 method
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 implemented in C so I'm not
sure I follow.
--
--Guido van Rossum (home page: http://www.python.org/~gui
In Py3K, is it still safe to assume that a list of paths will be
(enough like) ordinary strings?
I ask because of the various Path object discussions; it wasn't clear
that a Path object should be a sequence of (normalized unicode?)
characters (rather than path components), that the path would alwa
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. Neither of these is
> > particular convenient to work with
On Thu, Aug 24, 2006 at 03:48:57PM +0200, Fredrik Lundh wrote:
> Michael Chermside wrote:
>
> >> WOW, I love partition. In all the instances that weren't a simple "in"
> >> test I ended up using [r]partition. In some cases one of the returned
> >> strings gets thrown away but in those cases it i
Nick Coghlan <[EMAIL PROTECTED]> wrote:
>
> This idea is inspired by the find/rfind string discussion (particularly a
> couple of comments from Jim and Ron), but I think the applicability may prove
> to be wider than just string methods (e.g. I suspect it may prove useful for
> the bytes() typ
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
elegant that we could write aft
On 8/25/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > In the integer case, it reminds me of James Knight's tagged integer
> > patch to 2.3 [1]. If using long exclusively is 50% slower, why not try
> > the improved speed approach?
>
> looks like GvR was -1000 on this id
"Nick Coghlan" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> I think an enriched slicing model that allows sequence views to be
> expressed
> easily as "this slice of this sequence" would allow this to be dealt with
> cleanly, without requiring every sequence to provide a corres
Josiah Carlson <[EMAIL PROTECTED]> writes:
> Also, depending on the objects, one may consider a few other tagged
> objects, like perhaps None, True, and False
I doubt that it's worth it: they are not dynamically computed anyway,
so there is little gain (only avoiding manipulating their refcounts)
Nick Coghlan wrote:
> Ron Adam wrote:
>> Nick Coghlan wrote:
[clipped]
>> It might be nice if slice objects could be used in more ways in python.
>> That may work in most cases where you would want a string view.
>
> That's quite an interesting idea. With that approach, rather than having to
>
Nick Coghlan wrote:
A couple of errors in the sample code.
> The new method would have semantics like:
>
>def partition_indices(self, sep, limits=None):
>if limits is None:
>limits = range(0, len(self))
>else:
>limits = limits.indices(len(self))
Eith
This idea is inspired by the find/rfind string discussion (particularly a
couple of comments from Jim and Ron), but I think the applicability may prove
to be wider than just string methods (e.g. I suspect it may prove useful for
the bytes() type as well).
Copy-on-slice semantics are by far the
Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Ivan KrstiÄ wrote:
> > Jean-Paul Calderone wrote:
> >> http://twistedmatrix.com/trac/browser/sandbox/itamar/cppreactor/fusion
> >
> > This is the same Itamar who, in the talk I linked a few days ago
> > (http://ln-s.net/D+u) extolled buffer as a very rea
Ron Adam wrote:
> Nick Coghlan wrote:
>> Fredrik Lundh wrote:
>>> Nick Coghlan wrote:
>>>
> Nick Coghlan wrote:
>
>> With a variety of "view types", that work like the corresponding builtin
>> type,
>> but reference the original data structure instead of creating copies
> s
Ivan Krstić wrote:
> Jean-Paul Calderone wrote:
>> http://twistedmatrix.com/trac/browser/sandbox/itamar/cppreactor/fusion
>
> This is the same Itamar who, in the talk I linked a few days ago
> (http://ln-s.net/D+u) extolled buffer as a very real performance
> improvement in fast python networking,
20 matches
Mail list logo
