Le dimanche 2 octobre 2011 15:25:21, Antoine Pitrou a écrit :
> I don't know why you're saying that. The concatenation optimization
> worked in 2.x where the "str" type also used only one memory block. You
> just have to check that the refcount is about to drop to zero.
> Of course, resizing only w
On Sun, Oct 2, 2011 at 7:23 PM, Simon Cross
wrote:
> I'm -1 on hacking += to be fast again because having the two loops
> below perform wildly differently is *very* surprising to me:
>
> s = ''
> for x in loops:
> s += x
>
> s = ''
> for x in loops:
> s = s + x
Erk. Bad example. Second exam
On Sat, Oct 1, 2011 at 7:17 PM, Victor Stinner
wrote:
> I'm writing this email to ask you if this type solves a real issue, or if we
> can just prove the super-fast str.join(list of str).
I'm -1 on hacking += to be fast again because having the two loops
below perform wildly differently is *very*
Thanks to you both, I have made some progress on introducing my own keywords
to python interpreter. I think it is very kind of you to answer my question.
I think I can take it from here. Thanks again :)
02 Ekim 2011 05:42 tarihinde Nick Coghlan yazdı:
> 2011/10/1 "Martin v. Löwis" :
> >> First o
Great tips. Can we add them to the developer guide somewhere?
Thank you,
Vlad
On Thu, Sep 29, 2011 at 12:54 AM, Ezio Melotti wrote:
> Tip 1 -- merging heads:
>
> A while ago Éric suggested a nice tip to make merges easier and since I
> haven't seen many people using it and now I got a chance to
Antoine Pitrou writes:
> I'm not sure why "StringStream" or "StringBuffer" would be more
> discoverable, unless you're coming from a language where these names are
> well-known.
I think they are, but it doesn't really matter, since both are a bit
lame, and I doubt either is sufficiently sugges
There are a number of issues that are being conflated by this thread.
1) Should str += str be fast. In my opinion, the answer is an obvious and
resounding no. Strings are immutable, thus repeated string addition is
O(n**2). This is a natural and obvious conclusion. Attempts to change this
On Sun, 02 Oct 2011 16:41:16 +0200
Antoine Pitrou wrote:
> Le dimanche 02 octobre 2011 à 23:39 +0900, Stephen J. Turnbull a écrit :
> > Antoine Pitrou writes:
> >
> > > StringIO is an in-memory file-like object, like in 2.x (where it lived
> > > in the "cStringIO" module). I don't think it's a
2011/10/2 Georg Brandl :
> On 10/02/11 01:14, victor.stinner wrote:
>> http://hg.python.org/cpython/rev/9124a00df142
>> changeset: 72573:9124a00df142
>> parent: 72571:fa0b1e50270f
>> user: Victor Stinner
>> date: Sat Oct 01 23:48:37 2011 +0200
>> summary:
>> PyUnicode_FromKi
On 10/02/11 16:21, Georg Brandl wrote:
> On 10/02/11 01:14, victor.stinner wrote:
>> http://hg.python.org/cpython/rev/9124a00df142
>> changeset: 72573:9124a00df142
>> parent: 72571:fa0b1e50270f
>> user:Victor Stinner
>> date:Sat Oct 01 23:48:37 2011 +0200
>> summary:
>> Py
Le dimanche 02 octobre 2011 à 23:39 +0900, Stephen J. Turnbull a écrit :
> Antoine Pitrou writes:
>
> > StringIO is an in-memory file-like object, like in 2.x (where it lived
> > in the "cStringIO" module). I don't think it's a novel thing.
>
> The problem is the name "StringIO". Something lik
Antoine Pitrou writes:
> StringIO is an in-memory file-like object, like in 2.x (where it lived
> in the "cStringIO" module). I don't think it's a novel thing.
The problem is the name "StringIO". Something like "StringStream" or
"StringBuffer" might be more discoverable. I personally didn't h
On 10/02/11 01:14, victor.stinner wrote:
> http://hg.python.org/cpython/rev/9124a00df142
> changeset: 72573:9124a00df142
> parent: 72571:fa0b1e50270f
> user:Victor Stinner
> date:Sat Oct 01 23:48:37 2011 +0200
> summary:
> PyUnicode_FromKindAndData() raises a ValueError if
On Sun, 2 Oct 2011 15:00:01 +0200
Victor Stinner wrote:
>
> > I don't understand why StringIO couldn't simply be optimized a little
> > more, if it needs to.
>
> Honestly, I didn't know that StringIO.write() is more efficient than
> str+=str,
> and it is surprising to use the io module (which
Le samedi 1 octobre 2011 22:21:01, Antoine Pitrou a écrit :
> So, since people are confused at the number of possible options, you
> propose to add a new option and therefore increase the confusion?
The idea is to provide an API very close to the str type. So if your program
becomes slow in some
On Sun, Oct 2, 2011 at 8:05 AM, Maciej Fijalkowski wrote:
> On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik wrote:
>> Hello,
>>
>> I've stumbled upon Dave Beazley's article [1] about trying ancient GIL
>> removal patch at
>> http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of
"Martin v. Löwis" wrote:
> > longobject.c still used PyUnicode_EncodeDecimal() until 10 months
> > ago (8304bd765bcf). I missed the PyUnicode_TransformDecimalToASCII()
> > commit, probably because #10557 is still open.
> >
> > That's why I wouldn't like to implement the function myself at least
>
On Sun, Oct 2, 2011 at 5:02 AM, anatoly techtonik wrote:
> Hello,
>
> I've stumbled upon Dave Beazley's article [1] about trying ancient GIL
> removal patch at
> http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html
> and looking at the output of Python dis module thought tha
Hello,
I've stumbled upon Dave Beazley's article [1] about trying ancient GIL
removal patch at
http://dabeaz.blogspot.com/2011/08/inside-look-at-gil-removal-patch-of.html
and looking at the output of Python dis module thought that it would
be cool if there were tools to inspect, explain and play w
On Wed, Sep 28, 2011 at 8:41 AM, Guido van Rossum wrote:
> Congrats! Python 3.3 will be better because of this.
>
> On Wed, Sep 28, 2011 at 12:48 AM, "Martin v. Löwis"
> wrote:
> > I have now merged the PEP 393 implementation into default.
> > The main missing piece is the documentation; contrib
20 matches
Mail list logo
