On 30-aug-2006, at 7:26, Talin wrote:
> Guido van Rossum wrote:
>>
>> Regarding optimal buffer size, I've never seen a program for which 8K
>> wasn't optimal. Larger buffers simply don't pay off.
Larger buffers can be useful when doing binary I/O through stdio (at
least on linux). I've recentl
Guido van Rossum wrote:
> On 8/29/06, Talin <[EMAIL PROTECTED]> wrote:
>> I've been thinking more about the iostack proposal. Right now, a typical
>> file handle consists of 3 "layers" - one representing the backing store
>> (file, memory, network, etc.), one for adding buffering, and one
>> repres
On 8/29/06, Talin <[EMAIL PROTECTED]> wrote:
> I've been thinking more about the iostack proposal. Right now, a typical
> file handle consists of 3 "layers" - one representing the backing store
> (file, memory, network, etc.), one for adding buffering, and one
> representing the program-level API f
I've been thinking more about the iostack proposal. Right now, a typical
file handle consists of 3 "layers" - one representing the backing store
(file, memory, network, etc.), one for adding buffering, and one
representing the program-level API for reading strings, bytes, decoded
text, etc.
I
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
>
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 optimizations.
We're doing major feature-l
Is anyone familiar enough with modulefinder.py to fix its breakage in
Py3k? It chokes in a nasty way (exceeding the recursion limit) on the
relative import syntax. I suspect this is also a problem for 2.5, when
people use that syntax; hence the cross-post. There's no unittest for
modulefinder.py, b
-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
Do I even have to say -1?
Regular expressions shouldn't become the front and central of Python's
text processing tools.
--Guido
On 8/29/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> i can't say i'm too fond of this, but i thought of bringing this up. most
> scripting
> languages (perl, ruby, and
i can't say i'm too fond of this, but i thought of bringing this up. most scriptinglanguages (perl, ruby, and boo, to name some) have regular expressions aslanguage literals. since such languages are heavily used for string
manipulation, it might seem like a good idea to add them at the syntax lev
"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
Guido van Rossum wrote:
> On 8/28/06, Georg Brandl <[EMAIL PROTECTED]> wrote:
>> At python.org/sf/1547796, there is a preliminary patch for Py3k set literals
>> as specified in PEP 3100.
>
> Very cool! This is now checked in.
>
> Georg, can you do something about repr() of an empty set? This
> cu
33 matches
Mail list logo
