On 07/10/2011 09:13 PM Laura Creighton wrote:
What do we want to happen when somebody -- say in a C extension -- takes the id
of an object
that is scheduled to be removed when the gc next runs?
IMO taking the id should increment the object ref counter
and prevent the garbage collection, until t
On 9 July 2011 18:17, Armin Rigo wrote:
> Hi,
>
> On Sat, Jul 9, 2011 at 5:20 AM, William ML Leslie
> wrote:
>> My point about small integers (...)
>
> I think that your point about small integers is broken (even assuming
> that smallints are enabled by default, which is not the case). It
> mean
On 11 July 2011 20:29, Bengt Richter wrote:
> On 07/10/2011 09:13 PM Laura Creighton wrote:
>>
>> What do we want to happen when somebody -- say in a C extension -- takes
>> the id of an object
>> that is scheduled to be removed when the gc next runs?
>
> IMO taking the id should increment the obj
On 07/11/2011 01:36 PM William ML Leslie wrote:
On 11 July 2011 20:29, Bengt Richter wrote:
On 07/10/2011 09:13 PM Laura Creighton wrote:
What do we want to happen when somebody -- say in a C extension -- takes
the id of an object
that is scheduled to be removed when the gc next runs?
IMO t
On 11 July 2011 23:21, Bengt Richter wrote:
> On 07/11/2011 01:36 PM William ML Leslie wrote:
>>
>> On 11 July 2011 20:29, Bengt Richter wrote:
>>>
>>> On 07/10/2011 09:13 PM Laura Creighton wrote:
What do we want to happen when somebody -- say in a C extension -- takes
the id of a
On 12 July 2011 00:21, William ML Leslie wrote:
> Referential equivalence, which is a slightly more complicated (yet
> much better defined) idea says that x and y are equivalent when no
> operation can tell the difference between the two objects.
Ack, sorry. I meant Referential Transparency; whic
Hi
I'm a bit worried with our current benchmarks state. We have around 4
benchmarks that had reasonable slowdowns recently and we keep putting
new features that speed up other things. How can we even say we have
actually fixed the original issue? Can we have a policy of not merging
new performance
On 12/07/11 01:20, Maciej Fijalkowski wrote:
> Hi
>
> I'm a bit worried with our current benchmarks state. We have around 4
> benchmarks that had reasonable slowdowns recently and we keep putting
> new features that speed up other things. How can we even say we have
> actually fixed the original i
On Mon, Jul 11, 2011 at 4:29 PM, Antonio Cuni wrote:
> On 12/07/11 01:20, Maciej Fijalkowski wrote:
> > Hi
> >
> > I'm a bit worried with our current benchmarks state. We have around 4
> > benchmarks that had reasonable slowdowns recently and we keep putting
> > new features that speed up other t
+1 as well, but we need to make sure we can actually identify performance
regressions. I don't know if currently we can draw any conclusions from
significant drops in benchmark performance.
+100 for benchmarking branches. I think there's a tangentially related GSoC
(moving toward speed.python.org
10 matches
Mail list logo
