Adding PyGC_CollectIfEnabled() and calling it in Py_Finalize is probably
fine. I don't think the contract of PyGC_Collect itself (or gc.collect()
for that matter) should be changed. You might want to disable GC but
invoke it yourself.
On Mon, May 9, 2016, at 19:13, Łukasz Langa wrote:
> Is this de
Is this deliberate? Could we change it for 3.6 so PyGC_Collect does take
`enabled` into account?
Context: we’re experimenting with disabling the gc entirely for some workloads
because it doesn’t fare too well with Copy-on-Write on Linux. What ends up
happening is that disabling the gc actually
> On May 09 , 2016, at 11:03 AM, Chris Barker wrote:
>
> I installed OSX Python 3.5.1, created a virtual environment using the pyvenv
> command from that newly installed Python 3.5.1, and sourced its bin/activate.
> Then when running pip install ZODB, the compiler would be passed the
> -isysro
Thanks Joseph,
I say this isn't worth pursuing until someone else reports the issue, as I
couldn't replicate it with a "clean" system.
I had the old 10.6 SDK in /Developer/SDKs, it could have been ‘special’ in
> that I did alot of weird things for a former project and I just don’t
> recall.
>
I
On Sun, May 8, 2016 at 7:52 PM, Nick Coghlan wrote:
> On 9 May 2016 at 08:50, Guido van Rossum wrote:
> > On Sun, May 8, 2016 at 4:49 AM, Nick Coghlan wrote:
> >> P.S. The potential complexity of that is one of the reasons the design
> >> philosophy of "prefer composition to inheritance" has em
On 9 May 2016 at 12:39, Ethan Furman wrote:
> On 05/08/2016 07:15 PM, Nick Coghlan wrote:
>> Needing to use a PyPI alternative to a stdlib module for increased
>> cross-version consistency is a pretty common experience these days, so
>> I think that's OK - end users can choose for themselves betwe
