On 24/09/2011 00:32, Guido van Rossum wrote:
The interactive console is optimized for people entering code by
typing, not by copying and pasting large gobs of text.
If you think you can have it both, show us the code.
Anatoly wants ipython's new qtconsole.
This "does the right thing" because
>> Do we really need a new file? Why not pyport.h where other compiler stuff
>> goes?
>
> I'm not sure that pyport.h is the right place to add Py_MIN, Py_MAX,
> Py_ARRAY_LENGTH. pyport.h looks to be related to all things specific to the
> platform like INT_MAX, Py_VA_COPY, ... pymacro.h contains
Hello,
the subject says it all. PyUnicode_EncodeDecimal() is listed among
the deprecated functions. In cdecimal, I'm relying on this function
for a number of reasons:
* It is not trivial to implement.
* With the Unicode implementation constantly changing, it is nearly
impossible to know
Am 29.09.2011 01:21, schrieb Eric V. Smith:
> Is there some reason str.format had such major surgery done to it?
Yes: I couldn't figure out how to do it any other way. The formatting
code had a few basic assumptions which now break (unless you keep using
the legacy API). Primarily, the assumption
> the subject says it all. PyUnicode_EncodeDecimal() is listed among
> the deprecated functions.
Please see the section on deprecation. None of the deprecated functions
will be removed for a period of five years, and afterwards, they will
be kept until usage outside of the core is low. Most likely
"Martin v. Löwis" wrote:
> > the subject says it all. PyUnicode_EncodeDecimal() is listed among
> > the deprecated functions.
>
> Please see the section on deprecation. None of the deprecated functions
> will be removed for a period of five years, and afterwards, they will
> be kept until usage o
On Sat, 01 Oct 2011 16:53:44 +0200
victor.stinner wrote:
> http://hg.python.org/cpython/rev/4afab01f5374
> changeset: 72565:4afab01f5374
> user:Victor Stinner
> date:Sat Oct 01 16:48:13 2011 +0200
> summary:
> Add _PyUnicode_UTF8() and _PyUnicode_UTF8_LENGTH() macros
>
> * R
> 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
> until the API is settled.
I don't
Am 01.10.2011 17:18, schrieb Antoine Pitrou:
> On Sat, 01 Oct 2011 16:53:44 +0200
> victor.stinner wrote:
>> http://hg.python.org/cpython/rev/4afab01f5374
>> changeset: 72565:4afab01f5374
>> user:Victor Stinner
>> date:Sat Oct 01 16:48:13 2011 +0200
>> summary:
>> Add _PyUnico
On Sat, 01 Oct 2011 17:47:26 +0200
"Martin v. Löwis" wrote:
> Am 01.10.2011 17:18, schrieb Antoine Pitrou:
> > On Sat, 01 Oct 2011 16:53:44 +0200
> > victor.stinner wrote:
> >> http://hg.python.org/cpython/rev/4afab01f5374
> >> changeset: 72565:4afab01f5374
> >> user:Victor Stinner
> >
> First of all, I am sincerely sorry if this is wrong mailing list to ask
> this question. I checked out definitions of couple other mailing list,
> and this one seemed most suitable. Here is my question:
In principle, python-list would be more appropriate, but this really
is a border case. So wel
Hi,
Since the integration of the PEP 393, str += str is not more super-fast (but
just fast). For example, adding a single character to a string has to copy all
characters to a new string. I suppose that performances of a lot of
applications manipulating text may be affected by this issue, espec
Le samedi 1 octobre 2011 17:18:42, Antoine Pitrou a écrit :
> On Sat, 01 Oct 2011 16:53:44 +0200
>
> victor.stinner wrote:
> > http://hg.python.org/cpython/rev/4afab01f5374
> > changeset: 72565:4afab01f5374
> > user:Victor Stinner
> > date:Sat Oct 01 16:48:13 2011 +0200
> >
>
Le samedi 1 octobre 2011 14:52:03, vous avez écrit :
> >> Do we really need a new file? Why not pyport.h where other compiler
> >> stuff goes?
> >
> > I'm not sure that pyport.h is the right place to add Py_MIN, Py_MAX,
> > Py_ARRAY_LENGTH. pyport.h looks to be related to all things specific to
>
> Since the integration of the PEP 393, str += str is not more super-fast
> (but just fast).
Oh oh. str+=str is now *1450x* slower than ''.join() pattern. Here is a
benchmark (see attached script, bench_build_str.py):
Python 3.3
str += str: 14548 ms
''.join() : 10 ms
StringIO.write: 12
On 10/1/2011 9:26 AM, "Martin v. Löwis" wrote:
> Am 29.09.2011 01:21, schrieb Eric V. Smith:
>> Is there some reason str.format had such major surgery done to it?
>
> Yes: I couldn't figure out how to do it any other way. The formatting
> code had a few basic assumptions which now break (unless yo
On Sat, 1 Oct 2011 22:06:11 +0200
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).
>
> Hum, it looks like "What is the most efficient string concatenation method in
> python?" in a f
On 10/01/2011 09:06 PM, Victor Stinner wrote:
Another alternative is a "string-join" object. It is discussed (and
implemented) in the following issue, and PyPy has also an optional
implementation:
http://bugs.python.org/issue1569040
http://codespeak.net/pypy/dist/pypy/doc/interpreter-optimizati
On Sat, Oct 1, 2011 at 5:21 PM, Antoine Pitrou wrote:
> On Sat, 1 Oct 2011 22:06:11 +0200
> 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).
>>
>> Hum, it looks like "What is the mo
2011/10/1 "Martin v. Löwis" :
>> First of all, I am sincerely sorry if this is wrong mailing list to ask
>> this question. I checked out definitions of couple other mailing list,
>> and this one seemed most suitable. Here is my question:
>
> In principle, python-list would be more appropriate, but
On Sat, Oct 1, 2011 at 4:07 PM, Eric V. Smith wrote:
> On the other hand, not having this code in stringlib would certainly be
> liberating! Maybe I'll take this opportunity to clean it up and simplify
> it now that it's free of the stringlib constraints.
Yeah, don't sacrifice speed in str.format
On Sat, Oct 1, 2011 at 8:33 PM, Maciej Fijalkowski wrote:
> StringIO is bytes only I think, which might be a bit of an issue if
> you want a unicode at the end.
I'm not sure why you would think that (aside from a 2.x holdover).
StringIO handles Unicode text, BytesIO handles bytes.
Cheers,
Nick.
On Sat, Oct 1, 2011 at 1:17 PM, Victor Stinner
wrote:
> Most bytearray methods return a new object in most cases. I don't understand
> why, it's not efficient. I don't know if we can do in-place operations for
> strarray methods having the same name than bytearray methods (which are not
> in-place
23 matches
Mail list logo
