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
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 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
"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 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
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, 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
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
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
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
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
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 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
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
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
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
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
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*
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
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
20 matches
Mail list logo
