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
No need to take it back, as a long time python-* list reader I only took
your initial post as thinking out loud.
List readers can spot similar threads in the future by looking for these
three indicators:
1) Behavioral function arguments are discouraged and mostly on your say-so.
2) You didn't t
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, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> >If changing zip()'s behavior to match the most common use case is
> >totally out, the stdlib code at least argues for adding something like
> >itertools.izip_exact().
>
> I open to that.
>
> For this time being, let's do this. Add itertoo
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
Actually given Raymond's preferences I take it back
On 8/30/06, Ron Adam <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > Perhaps a compromise could be to add a keyword parameter to request
> > such an exception? (We could even add three options: truncate, pad,
> > error, with truncate b
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
Guido van Rossum wrote:
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception? (We could even add three options: truncate, pad,
> error, with truncate being the default, and pad being the old map()
> and filter() behavior.)
Maybe it can be done with just two op
Guido van Rossum wrote:
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception?
But who is going to bother using such a keyword,
when it's not necessary for correct operation of
the program in the absence of bugs?
> (We could even add three options: truncate, p
>Proposed change:
>
>zip( [iterable, ...])
>This function returns a list of tuples, where the i-th tuple
>contains the i-th element from each of the argument sequences or
>iterables. It is an error if the argument sequences are of different
>lengths...
>
>That seems pretty comparable in comp
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
>If changing zip()'s behavior to match the most common use case is
>totally out, the stdlib code at least argues for adding something like
>itertools.izip_exact().
>
>
I open to that.
For this time being, let's do this. Add itertools.izip_longest() in
Py2.5 and include a recipe for izip_exac
On 8/30/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Steven Bethard wrote:
>
> >A couple Python-3000 threads [1] [2] have indicated that the most
> >natural use of zip() is with sequences of the same lengths. I feel
> >the same way, and run into this all the time. Because the error would
>
On 8/30/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> Until now, there have been zero requests for zip() to have exception
> raising behavior.
>
> For Python 3k, I recommend:
> * simply replacing zip() with itertools.izip()
> * keeping the zip_longest() in a separate module
> * punting on an e
>
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception? (We could even add three options: truncate, pad,
> error, with truncate being the default, and pad being the old map()
> and filter() behavior.)
FWIW, I intend to add an itertool called izip_longest() wh
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Aug 30, 2006, at 5:57 PM, Guido van Rossum wrote:
> Perhaps a compromise could be to add a keyword parameter to request
> such an exception? (We could even add three options: truncate, pad,
> error, with truncate being the default, and pad being th
> Steven Bethard wrote:
> >A couple Python-3000 threads [1] [2] have indicated that the most
> >natural use of zip() is with sequences of the same lengths. I feel
> >the same way, and run into this all the time. Because the error would
> >otherwise pass silently, I usually end up adding checks be
Steven Bethard wrote:
>A couple Python-3000 threads [1] [2] have indicated that the most
>natural use of zip() is with sequences of the same lengths. I feel
>the same way, and run into this all the time. Because the error would
>otherwise pass silently, I usually end up adding checks before each
A couple Python-3000 threads [1] [2] have indicated that the most
natural use of zip() is with sequences of the same lengths. I feel
the same way, and run into this all the time. Because the error would
otherwise pass silently, I usually end up adding checks before each
use of zip() to raise an e
"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
On 8/29/06, Talin <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
> > I'm not sure I follow.
> >
> > We *definitely* don't want to use stdio -- it's not part of the OS
> > anyway, and has some annoying quirks like not giving you any insight
> > in how it is using the buffer, nor changing the b
Talin wrote:
> It seems to me that no matter how you slice it, you can't have an
> abstract "buffering" layer that is independent of both the layer beneath
> and the layer above. Both the text decoding layer and the disk i/o layer
> need to have fairly intimate knowledge of their buffers if you
Guido van Rossum wrote:
> Over lunch with Neal we came upon the topic of optimization and Python 3000.
>
> It is our strong opinion that in this stage of the Py3k project we
> should focus on getting the new language spec and implementation
> feature-complete, without worrying much about optimizat
Talin <[EMAIL PROTECTED]> writes:
> It seems to me that no matter how you slice it, you can't have an
> abstract "buffering" layer that is independent of both the layer
> beneath and the layer above.
I think buffering makes sense as the topmost layer, and typically only
there.
Encoding conversio
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
34 matches
Mail list logo
