anatoly techtonik writes:
> Fernando clearly showed that IPython rocks, because CPython suxx.
No, IPython rocks because it focuses on doing one thing well:
providing an interactive environment that takes advantage of the many
features that Python provides in support. CPython should do the sam
On 12/20/2011 11:15 AM, Benjamin Peterson wrote:
2011/12/20 Antoine Pitrou:
Le mardi 20 décembre 2011 à 10:57 -0500, Benjamin Peterson a écrit :
In that case, I would rather speak of "fast" functions rather than
"implemented in C" functions (a la the itertools docs). Would that be
acceptable?
On Tue, Dec 20, 2011 at 12:14 PM, Dirkjan Ochtman wrote:
> On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou wrote:
>>> If this documentation is to be used by other python implementations,
>>> then mentions of performance are outright harmful, since the
>>> performance characteristics differ quite dr
On 20/12/2011 09:54, Antoine Pitrou wrote:
Hello,
The include file (unicodeobject.h) seems to imply that some pure ASCII
strings can be non-compact, but I don't understand how that can happen.
If you create a string from Py_UNICODE* or wchar_t* (using the legacy
API), PyUnicode_READY() may c
On Mon, Dec 19, 2011 at 7:47 AM, Stephen J. Turnbull wrote:
> Fernando Perez writes:
>
> > Apology for the advertising,
>
> If there's any apologizing to be done, it's on Anatoly's part. Your
> post was short, to the point, information-packed, and should put a big
> fat open-centered ideographic
2011/12/20 Antoine Pitrou :
> Le mardi 20 décembre 2011 à 10:57 -0500, Benjamin Peterson a écrit :
>> In that case, I would rather speak of "fast" functions rather than
>> "implemented in C" functions (a la the itertools docs). Would that be
>> acceptable?
>
> Definitely.
Done.
--
Regards,
Ben
Le mardi 20 décembre 2011 à 10:57 -0500, Benjamin Peterson a écrit :
> 2011/12/20 Antoine Pitrou :
> > On Mon, 19 Dec 2011 22:42:43 +0100
> > benjamin.peterson wrote:
> >> http://hg.python.org/cpython/rev/d85efd73b0e1
> >> changeset: 74088:d85efd73b0e1
> >> branch: 3.2
> >> parent: 740
2011/12/20 Antoine Pitrou :
> On Mon, 19 Dec 2011 22:42:43 +0100
> benjamin.peterson wrote:
>> http://hg.python.org/cpython/rev/d85efd73b0e1
>> changeset: 74088:d85efd73b0e1
>> branch: 3.2
>> parent: 74082:71e5a083f9b1
>> user: Benjamin Peterson
>> date: Mon Dec 19 16:41
On Tue, Dec 20, 2011 at 6:24 AM, Dirkjan Ochtman wrote:
> On Tue, Dec 20, 2011 at 11:27, Terry Reedy wrote:
>> And I remember that Guido has
>> asked that the manual not discuss big O()
>> behavior of the methods of builtin classes.
>
> Do you know when/where he did that? It seems useful to know
Wiadomość napisana przez Dirkjan Ochtman w dniu 20 gru 2011, o godz. 12:24:
> On Tue, Dec 20, 2011 at 11:27, Terry Reedy wrote:
>> And I remember that Guido has
>> asked that the manual not discuss big O()
>> behavior of the methods of builtin classes.
>
> Do you know when/where he did that?
ht
Wiadomość napisana przez Antoine Pitrou w dniu 20 gru 2011, o godz. 11:57:
> Why you think we should leave users in the dark rather than inform them
> is beyond me. While we certainly should find a good compromise between
> readability and completeness, and should certainly tweak the doc's
> word
On Tue, Dec 20, 2011 at 11:27, Terry Reedy wrote:
> And I remember that Guido has
> asked that the manual not discuss big O()
> behavior of the methods of builtin classes.
Do you know when/where he did that? It seems useful to know that on
CPython, list.insert(0, x) will become slow as the list g
On Tue, 20 Dec 2011 05:27:41 -0500
Terry Reedy wrote:
> >
> > I disagree with this change. Knowing that they are written in C is
> > important when deciding to pass them to e.g. sort() or sorted(),
> > because you know it will be faster than an arbitrary pure Python
> > function.
> >
> > You could
On 12/20/2011 3:51 AM, Antoine Pitrou wrote:
On Mon, 19 Dec 2011 22:42:43 +0100
benjamin.peterson wrote:
http://hg.python.org/cpython/rev/d85efd73b0e1
changeset: 74088:d85efd73b0e1
branch: 3.2
parent: 74082:71e5a083f9b1
user:Benjamin Peterson
date:Mon Dec 19 16:41:11
On 2011-12-20, at 11:08 , Antoine Pitrou wrote:
> But that's basically the only reason to invoke the
> `operator.attrgetter("foo")` ugliness, instead of writing the explicit
> and obvious `lambda x: x.foo`.
I don't agree with this, an attrgetter in the current namespace can be clearer
than an expl
On Tue, 20 Dec 2011 11:14:15 +0100
Dirkjan Ochtman wrote:
> On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou wrote:
> >> If this documentation is to be used by other python implementations,
> >> then mentions of performance are outright harmful, since the
> >> performance characteristics differ quit
On Tue, Dec 20, 2011 at 11:08, Antoine Pitrou wrote:
>> If this documentation is to be used by other python implementations,
>> then mentions of performance are outright harmful, since the
>> performance characteristics differ quite drastically. Written in C is
>> also not a part of specification
Le mardi 20 décembre 2011 à 12:01 +0200, Maciej Fijalkowski a écrit :
>
> If this documentation is to be used by other python implementations,
> then mentions of performance are outright harmful, since the
> performance characteristics differ quite drastically. Written in C is
> also not a part o
On Tue, Dec 20, 2011 at 10:51 AM, Antoine Pitrou wrote:
> On Mon, 19 Dec 2011 22:42:43 +0100
> benjamin.peterson wrote:
>> http://hg.python.org/cpython/rev/d85efd73b0e1
>> changeset: 74088:d85efd73b0e1
>> branch: 3.2
>> parent: 74082:71e5a083f9b1
>> user: Benjamin Peterson
>>
Hello,
The include file (unicodeobject.h) seems to imply that some pure ASCII
strings can be non-compact, but I don't understand how that can happen.
Besides, the following comment also seems wrong:
- compact:
* structure = PyCompactUnicodeObject
* test: PyUnicode_IS_A
On Mon, 19 Dec 2011 22:42:43 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/d85efd73b0e1
> changeset: 74088:d85efd73b0e1
> branch: 3.2
> parent: 74082:71e5a083f9b1
> user:Benjamin Peterson
> date:Mon Dec 19 16:41:11 2011 -0500
> summary:
> don't me
21 matches
Mail list logo
