Greg Ewing <[EMAIL PROTECTED]> writes:
> It might be possible to represent it in a narrower format,
> however. Perhaps there should be an explicit operation for
> re-packing a string into the narrowest possible format?
I suppose it's better to always normalize a polymorphic string
representation.
Talin wrote:
> So for example, any string operation which produces a subset of the
> string (such as partition, split, index, slice, etc.) will produce a
> string of the same width as the original string.
It might be possible to represent it in a narrower format,
however. Perhaps there should b
> spending that theorizing.
make that "spending that time theorizing about what you could, in theory, do."
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/
Talin wrote:
> (Another option is to simply make all strings UTF-32 -- which is not
> that unreasonable, considering that text strings normally make up only a
> small fraction of a program's memory footprint. I am sure that there are
> applications that don't conform to this generalization, howeve
Guido van Rossum wrote:
> A way to handle UTF-8 strings and other variable-length encodings
> would be to maintain a small cache of index positions with the string
> object.
I think just delaying decoding would take us most of the way. the big
advantage of storage polymorphism is that you can a
tjreedy wrote:
> These two similar features would be enough, to me, to make Py3 more than
> just 2.x with cruft removed.
well, it's really only C API issues that keeps us from implementing this
in 2.x... (too much code uses PyString_Check and/or PyUnicode_Check and
then happily digs into the a
Guido van Rossum wrote:
> BTW, in some sense Python 2.x *has* polymorphic strings -- str and
> unicde have the same API (99% anyway) but different implementations,
> and there's even a common abstract base class (basestring). But this
> clearly isn't what the ObjectiveC folks want to see!
on the
Talin wrote:
> So essentially what I am proposing is this:
"look at me! look at me!"
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/listinfo/python-3000
Unsubscribe:
http://mail.python.org/mailman/options/python-3
On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
> > Here you are effectively voting against polymorphic strings. I believe
> > Fredrik has good reasons to doubt this assertion.
>
> Yes, that is correct. I'm just throwing it out there as a possibility,
> as it is by far the simplest solution. Its a que
Guido van Rossum wrote:
> On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
>> One way to handle this efficiently would be to only support the
>> encodings which have a constant character size: ASCII, Latin-1, UCS-2
>> and UTF-32. In other words, if the content of your text is plain ASCII,
>> use an 8-b
(Adding back py3k list assuming you just forgot it)
On 8/31/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> On 8/31/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> > > (The difference between UCS-2 and UTF-16 is that UCS-2 is always 2 bytes
> > > per character, and doesn't support the supplement
"Bob Ippolito" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
> +1 for polymorphic strings.
A strong +1 here also.
>
> This would give us the best of both worlds: compact representations
> for ASCII and Latin-1, full 32 bit text when needed, and the
> possibility to implement furthe
On 8/31/06, Talin <[EMAIL PROTECTED]> wrote:
> One way to handle this efficiently would be to only support the
> encodings which have a constant character size: ASCII, Latin-1, UCS-2
> and UTF-32. In other words, if the content of your text is plain ASCII,
> use an 8-bit-per-character string; If th
Jack Diederich wrote:
>>> (in other words, I'm convinced that we need a polymorphic string type. I'm
>>> not
>>> so sure we need views, but if we have the former, we can use that mechanism
>>> to
>>> support the latter)
>> +1 for polymorphic strings.
>>
>> This would give us the best of both wor
Jack Diederich wrote:
> That said can you guys expand on what polymorphic[1] means here in particular?
> Python wise I can only think of the str/unicode/buffer split. If the
> fraternity of strings doesn't include views (which I haven't needed either)
> what are you considering for the other kin
On 8/30/06, Jack Diederich <[EMAIL PROTECTED]> wrote:
On Wed, Aug 30, 2006 at 08:56:03PM -0700, Bob Ippolito wrote:> > and also based on the cET (and NFS) experiences, it wouldn't surprise me> > if a naive 32-bit text string implementation will, on average, slow things down
> > *more* than any stri
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>> The 'characters' data type would be particularly optimized for
>> character-at-a-time operations, i.e. building up a string one character
>> at a time. An example use would be processing escape sequences in
>> strings, where you are tra
Ron Adam <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
>
> > If views are always returned, then we can perform some optimizations
> > (adjacent view concatenation, etc.), which may reduce running time,
> > memory use, etc. d
>
> Given a empty string and a view to it, how much memory do
On Wed, Aug 30, 2006 at 08:56:03PM -0700, Bob Ippolito wrote:
> On 8/30/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> > Fredrik Lundh wrote:
> >
> > > not necessarily, but there are lots of issues involved when doing
> > > high-performance XML stuff, and I'm not sure views would help quite as
> >
Josiah Carlson wrote:
> If views are always returned, then we can perform some optimizations
> (adjacent view concatenation, etc.), which may reduce running time,
> memory use, etc. d
Given a empty string and a view to it, how much memory do you think a
view object will take in comparison to th
On 8/30/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Fredrik Lundh wrote:
>
> > not necessarily, but there are lots of issues involved when doing
> > high-performance XML stuff, and I'm not sure views would help quite as
> > much as one might think.
> >
> > (writing and tuning cET was a great way
Talin <[EMAIL PROTECTED]> wrote:
> I know this was shot down before, but I would still like to see a
> "characters" type - that is, a mutable sequence of wide characters, much
> like the Java StringBuffer class - to go along with "bytes". From my
> perspective, it makes perfect sense to have an
On 8/30/06, Talin <[EMAIL PROTECTED]> wrote:
> I know this was shot down before, but I would still like to see a
> "characters" type - that is, a mutable sequence of wide characters, much
> like the Java StringBuffer class - to go along with "bytes". From my
> perspective, it makes perfect sense to
Josiah Carlson wrote:
> If views are always returned, then we can perform some optimizations
> (adjacent view concatenation, etc.), which may reduce running time,
> memory use, etc. If the user *needs* a string to be returned, they can
> always perform str(view). But remember, since 2.x strings
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > Up until this morning I was planning on writing everything such that
> > constructive manipulation (upper(), __add__, etc.) returned views of
> > strings.
>
> I was about to say that this would be completely pointless,
> when I
Josiah Carlson wrote:
> Up until this morning I was planning on writing everything such that
> constructive manipulation (upper(), __add__, etc.) returned views of
> strings.
I was about to say that this would be completely pointless,
when I realised the point is so that further operations on
the
"Paul Prescod" <[EMAIL PROTECTED]> wrote:
> Yes, thanks for the clarification. From a type theory point of view there is
> nothing stopping string + view returning a view always (even if it is a view
> of a new string) but that would have very poor performance characteristics.
It depends. Assume
I'd phrase it differently -- that would be plain silly. :-)
On 8/30/06, Paul Prescod <[EMAIL PROTECTED]> wrote:
> Yes, thanks for the clarification. From a type theory point of view there is
> nothing stopping string + view returning a view always (even if it is a view
> of a new string) but that
Yes, thanks for the clarification. From a type theory point of view there is nothing stopping string + view returning a view always (even if it is a view of a new string) but that would have very poor performance characteristics.
On 8/30/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
The differenc
The difference between a string and a view is one of TYPE. (Because
they can have such different performance and memory usage
characteristics, it's not right to treat them as the same type.)
You seem to be misunderstanding what I said. I want the return type
only to depend on the input types. This
I don't understand. If the difference between a string and a string view is a difference of VALUES, not TYPES, then the return type is varying based upon the difference of input types (which you say is okay). Conversely, if the strings and string views only vary in their values (share a type) then
Fredrik Lundh wrote:
> not necessarily, but there are lots of issues involved when doing
> high-performance XML stuff, and I'm not sure views would help quite as
> much as one might think.
>
> (writing and tuning cET was a great way to learn that not everything
> that you think you know about C pe
On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > This is changing return types based on variable type,
>
> How do you make that out? It seems the opposite to me --
> Guido is saying that the return type of s+t should *not*
> depend on whether s or t happens to be a view
On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > If views are not automatically returned for methods on strings, then you
> > won't have to worry about views unless you explicitly construct them.
>
> Although you might have to worry about someone else
> handing you a
On Tue, Aug 29, 2006, Guido van Rossum wrote:
> On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
>> Guido van Rossum wrote:
>>>
>>> Having views in a library module alleviates many of my objections.
>>> While I still worry that it will be overused, deque doesn't seem to
>>> be overused, so perhaps
Josiah Carlson wrote:
> On the other hand, its performance characteristics could be
> confusing to users of Python who may have come to expect that "st+''" is
> a constant time operation, regardless of the length of st.
Even if that's always true, I'm not sure it's really a
useful thing to know. H
Jim Jewett wrote:
> Why is it essential that string views be a different type, rather than
> an internal implementation detail, like long vs int?
We're talking about a more abstract notion of "type" here.
Strings and views are different things with different
performance characteristics, so it's i
Josiah Carlson wrote:
> This is changing return types based on variable type,
How do you make that out? It seems the opposite to me --
Guido is saying that the return type of s+t should *not*
depend on whether s or t happens to be a view rather than
a real string.
--
Greg
Josiah Carlson wrote:
> If views are not automatically returned for methods on strings, then you
> won't have to worry about views unless you explicitly construct them.
Although you might have to worry about someone else
handing you a view when you weren't expecting it. Minimising
the chance of t
On 8/29/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Having views in a library module alleviates many of my objections.
> > While I still worry that it will be overused, deque doesn't seem to be
> > overused, so perhaps I should relax.
>
> Another thought is that there
Guido van Rossum wrote:
> Having views in a library module alleviates many of my objections.
> While I still worry that it will be overused, deque doesn't seem to be
> overused, so perhaps I should relax.
Another thought is that there will already be ways
in which Py3k views could lead to ineffic
On 8/29/06, Jim Jewett <[EMAIL PROTECTED]> wrote:
> On 8/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> > The type consistency and predictability is more important to me.
>
> Why is
Barry Warsaw <[EMAIL PROTECTED]> wrote:
>
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On Aug 29, 2006, at 5:01 PM, Jim Jewett wrote:
>
> > Why is it essential that string views be a different type, rather than
> > an internal implementation detail, like long vs int? Today's strings
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 29, 2006, at 5:01 PM, Jim Jewett wrote:
> Why is it essential that string views be a different type, rather than
> an internal implementation detail, like long vs int? Today's strings
> can already return a new object or an existing one which
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > > For operations that may be forced to return a new string (e.g.
> > > concatenation) I think the return value should always be a new string,
On 8/29/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> The type consistency and predictability is more important to me.
Why is it essential that string views be a different type, rather th
On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > For operations that may be forced to return a new string (e.g.
> > concatenation) I think the return value should always be a new string,
> > even if it could be optimized. So for example if v
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > String operations always returning views would be arguably insane. I
> > hope no one was recommending it (I certainly wasn't, but if my words
> > were confusing on that part, I apologize); st
Josiah Carlson wrote:
>> when did you last write an XML parser ?
>
> Comparing what I have written as an XML parser to xml.dom, xml.sax,
> ElementTree, or others, is a bit like comparing a go-kart with an
> automobile. That is to say, it's been a few years, and it was to
> scratch an itch for a
On 8/29/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > On 8/28/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > While there are examples where views can be slower, this is no different
> > > than the cases where deque is slower than list; some
Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > 1. Let us say I was parsing XML. Rather than allocating a bunch of small
> > strings for the various tags, attributes, and data, I could instead
> > allocate a bunch of string views with pointers into the one larger XML
> > s
Josiah Carlson wrote:
> 1. Let us say I was parsing XML. Rather than allocating a bunch of small
> strings for the various tags, attributes, and data, I could instead
> allocate a bunch of string views with pointers into the one larger XML
> string.
when did you last write an XML parser ?
___
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 8/28/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > While there are examples where views can be slower, this is no different
> > than the cases where deque is slower than list; sometimes some data
> > structures are more applicable to the probl
On 8/28/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> > Those are all microbenchmarks. It's easy to prove the superiority of
> > an approach that way. But what about realistic applications? What if
> > your views don't end up saving memory or time
Greg Ewing wrote:
> Ron Adam wrote:
>
>> And in addition to that... 0 is not the beginning if the step is -1.
>
> Negative steps are downright confusing however you
> think about them. :-)
Yes, and it seems to me it could be easier. Of course that would mean
changing something, and any solutio
Ron Adam wrote:
> And in addition to that... 0 is not the beginning if the step is -1.
Negative steps are downright confusing however you
think about them. :-)
> In most cases I've seen only integers
> and None are ever used.
Numeric uses various strange things as array indexes, such
as Ellips
Greg Ewing wrote:
> Ron Adam wrote:
>
>> 1. Remove None stored as indices in slice objects. Depending on the step
>> value, Any Nones can be converted to 0 or -1 immediately,
>
> But None isn't the same as -1 in a slice. None means the end
> of the sequence, whereas -1 means one less than the en
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
>
> > If every operation on a view returned a string copy, then what would be
> > the point of the view in the first place?
>
> String views would have all the same methods as a real
> string, so you could find(), index(), etc. while
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> Those are all microbenchmarks. It's easy to prove the superiority of
> an approach that way. But what about realistic applications? What if
> your views don't end up saving memory or time for an application, but
> still cost in terms of added complex
On 8/28/06, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > You seem to be utterly convinced of the superior performance of your
> > proposal without having done any measurements.
>
> For my part, superior performance isn't the main
> reason for considering string views. Rathe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 28, 2006, at 9:20 PM, Greg Ewing wrote:
> I'm also not all that happy about forcing slice indices to
> be ints. Traditionally they are, but someone might want to
> define a class that uses them in a more general way.
In fact, we do. Our appli
Guido van Rossum wrote:
> You seem to be utterly convinced of the superior performance of your
> proposal without having done any measurements.
For my part, superior performance isn't the main
reason for considering string views. Rather it's
the simplification that would result from replacing
the
Ron Adam wrote:
> 1. Remove None stored as indices in slice objects. Depending on the step
> value, Any Nones can be converted to 0 or -1 immediately,
But None isn't the same as -1 in a slice. None means the end
of the sequence, whereas -1 means one less than the end.
I'm also not all that happ
Josiah Carlson wrote:
> If every operation on a view returned a string copy, then what would be
> the point of the view in the first place?
String views would have all the same methods as a real
string, so you could find(), index(), etc. while operating
efficiently on the original data. To my min
Those are all microbenchmarks. It's easy to prove the superiority of
an approach that way. But what about realistic applications? What if
your views don't end up saving memory or time for an application, but
still cost in terms of added complexity in all string operations?
Anyway, let me begin wit
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>
> Josiah (and other supporters of string views),
>
> You seem to be utterly convinced of the superior performance of your
> proposal without having done any measurements.
>
> You appear to have a rather naive view on what makes code execute fast
>
Guido van Rossum wrote:
> (e.g. you don't seem to appreciate the savings due to a string
> object header and its data being consecutive in memory).
footnote: note that the Unicode string type still doesn't do that (my
original implementation *did* support string views, and nobody's ever
gotten
Josiah (and other supporters of string views),
You seem to be utterly convinced of the superior performance of your
proposal without having done any measurements.
You appear to have a rather naive view on what makes code execute fast
or slow (e.g. you don't seem to appreciate the savings due to a
Guido van Rossum wrote:
> On 8/27/06, Nick Coghlan <[EMAIL PROTECTED]> wrote:
>> I believe the current mixed model is actually an artifact of the
>> transition
>> from simple slicing to extended slicing,
>
> Really? Extended slicing mostly meant adding a third "step" option to
> the slice syntax,
Nick Coghlan 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() type as well).
If I'm foll
On 8/28/06, Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote:
> For when/*if* views ever become considered to be a good thing for
> builtin classes, etc, may I suggest that the following syntax be
> reserved for view creation:
>
> obj{start:stop:step}
>
> mapping to something like:
>
> def
Greg Ewing <[EMAIL PROTECTED]> wrote:
> 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 abo
"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, 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
"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
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
"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 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,
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, 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
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
"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
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
1 - 100 of 101 matches
Mail list logo
