On 9/18/2017 11:37 AM, Ethan Furman wrote:
On 09/11/2017 03:28 PM, Guido van Rossum wrote:
Oddly I don't like the enum (flag names get too long that way), but I
do agree with everything else Barry said (it
should be a trivalue flag and please don't name it cmp).
Hmmm, named constants are one
On Mon, 18 Sep 2017 13:25:47 -0700
Nathaniel Smith wrote:
> >> If it is then it might make sense to look at the cycle collection
> >> heuristics; IIRC they're based on a fairly naive count of how many
> >> allocations have been made, without regard to their size.
> >
> > Yes... But just because
On Mon, Sep 18, 2017 at 10:59 AM, Antoine Pitrou wrote:
> Le 18/09/2017 à 19:53, Nathaniel Smith a écrit :
>>>
Why are reference cycles a problem that needs solving?
>>>
>>> Because sometimes they are holding up costly resources in memory when
>>> people don't expect them to. Such as large N
Thanks for working on this and writing up the details Victor.
For those confused about why this matters, routinely having every
object in your application participating in one (or more) giant
reference cycles makes reasoning about and fixing resource issues very
difficult.
For instance, a while b
On 09/11/2017 03:28 PM, Guido van Rossum wrote:
Oddly I don't like the enum (flag names get too long that way), but I do agree
with everything else Barry said (it
should be a trivalue flag and please don't name it cmp).
Hmmm, named constants are one of the motivating factors for having an Enu
Le 18/09/2017 à 19:53, Nathaniel Smith a écrit :
>>
>>> Why are reference cycles a problem that needs solving?
>>
>> Because sometimes they are holding up costly resources in memory when
>> people don't expect them to. Such as large Numpy arrays :-)
>
> Do we have any reason to believe that this
On Mon, Sep 18, 2017 at 9:50 AM, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 09:42:45 -0700
> Nathaniel Smith wrote:
>>
>> Obviously it's nice when the refcount system is able to implicitly clean
>> things up in a prompt and deterministic way, but there are already tools to
>> handle the cases wh
On Mon, 18 Sep 2017 09:42:45 -0700
Nathaniel Smith wrote:
>
> Obviously it's nice when the refcount system is able to implicitly clean
> things up in a prompt and deterministic way, but there are already tools to
> handle the cases where it doesn't (ResourceWarning, context managers, ...),
> and
On Sep 18, 2017 07:58, "Antoine Pitrou" wrote:
Le 18/09/2017 à 16:52, Guido van Rossum a écrit :
>
> In Python 2 the traceback was not part of the exception object because
> there was (originally) no cycle GC. In Python GC we changed the awkward
> interface to something more useful, because we c
Hello,
Le 2017-09-16 à 07:22, Serhiy Storchaka a écrit :
> 16.09.17 12:39, Larry Hastings пише:
>> So why don't decorators allow arbitrary expressions? [...]
>
> Actually I remember somebody raised this question a year or two ago,> but
> don't remember details.
The discussion I remember wa
Le 18/09/2017 à 16:52, Guido van Rossum a écrit :
>
> In Python 2 the traceback was not part of the exception object because
> there was (originally) no cycle GC. In Python GC we changed the awkward
> interface to something more useful, because we could depend on GC. Why
> are we now trying to ro
On Mon, Sep 18, 2017 at 2:48 AM, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 11:31:12 +0200
> Victor Stinner wrote:
> >
> > Ideally, CPython 3.x should never create reference cycles. Removing
> > Exception.__traceback__ is the obvious "fix" for the issue. But I
> > expect that slowly, a lot of c
On 18 September 2017 at 09:31, Victor Stinner wrote:
> Last years, I fixed many reference cycles in various parts of the
> Python 3 standard library. Sometimes, it takes years to become aware
> of the reference cycle and finally fix it.
>
> For example, recently, I worked on fixing all "dangling t
On 18 September 2017 at 20:52, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 20:35:02 +1000
> Nick Coghlan wrote:
>> Rather than being thread local or context local state, whether or not
>> to keep the full frames in the traceback could be a yet another
>> setting on the *exception* object, whereby
On Mon, 18 Sep 2017 20:35:02 +1000
Nick Coghlan wrote:
> On 18 September 2017 at 20:18, Victor Stinner
> wrote:
> > 2017-09-18 12:07 GMT+02:00 Nick Coghlan :
> >> I wonder if it might be reasonable to have tracebacks only hold a weak
> >> reference to their frame objects when "__debug__ == Fal
On Mon, 18 Sep 2017 20:07:42 +1000
Nick Coghlan wrote:
> On 18 September 2017 at 19:48, Antoine Pitrou wrote:
> > On Mon, 18 Sep 2017 11:31:12 +0200
> > Victor Stinner wrote:
> >>
> >> Ideally, CPython 3.x should never create reference cycles. Removing
> >> Exception.__traceback__ is the obvi
Hi,
First my high-level opinion about the PEP: the CSP model can probably
be already implemented using Queues. To me, the interesting promise of
subinterpreters is if they allow to remove the GIL while sharing memory
for big objects (such as Numpy arrays). This means the PEP should
probably foc
On 18 September 2017 at 20:18, Victor Stinner wrote:
> 2017-09-18 12:07 GMT+02:00 Nick Coghlan :
>> I wonder if it might be reasonable to have tracebacks only hold a weak
>> reference to their frame objects when "__debug__ == False".
>
> Please don't change the Python behaviour depending on __debu
2017-09-18 12:07 GMT+02:00 Nick Coghlan :
> I wonder if it might be reasonable to have tracebacks only hold a weak
> reference to their frame objects when "__debug__ == False".
Please don't change the Python behaviour depending on __debug__, or it
will be a nightmare to debug it :-( ("Why does it
On 18 September 2017 at 19:48, Antoine Pitrou wrote:
> On Mon, 18 Sep 2017 11:31:12 +0200
> Victor Stinner wrote:
>>
>> Ideally, CPython 3.x should never create reference cycles. Removing
>> Exception.__traceback__ is the obvious "fix" for the issue. But I
>> expect that slowly, a lot of code sta
Hum, my email is long. Maybe an short example is simpler to understand:
---
import gc
class VerboseDestructor:
# Imagine an object using many limited resources like memory,
# sockets and/or files
def __del__(self):
print("VerboseDestructor")
def create_ref_cycle():
obj = V
On Mon, 18 Sep 2017 11:31:12 +0200
Victor Stinner wrote:
>
> Ideally, CPython 3.x should never create reference cycles. Removing
> Exception.__traceback__ is the obvious "fix" for the issue. But I
> expect that slowly, a lot of code started to rely on the attribute,
> maybe even for good reasons
Hi,
Python 3 added a __traceback__ attribute to exception objects. I guess
that it was added to be able to get the original traceback when an
exception is re-raised. Artifical example (real code is more complex
with subfunctions and conditional code):
try:
...
except Exception as exc:
...
23 matches
Mail list logo