So, here's some info about how to see what's going on with Python's
memory allocation: https://docs.python.org/3/library/tracemalloc.html
. I haven't looked into this in a long time, but it used to be the
case that you needed to compile native modules (and probably Python
itself?) so that
On 2024-01-17 3:01 AM, Greg Ewing via Python-list wrote:
On 17/01/24 1:01 am, Frank Millman wrote:
I sometimes need to keep a reference from a transient object to a more
permanent structure in my app. To save myself the extra step of
removing all these references when the transient object is
On 17/01/24 1:01 am, Frank Millman wrote:
I sometimes need to keep a reference from a
transient object to a more permanent structure in my app. To save myself
the extra step of removing all these references when the transient
object is deleted, I make them weak references.
I don't see how
On 17/01/24 4:00 am, Chris Angelico wrote:
class Form:
def __init__(self):
self.elements = []
class Element:
def __init__(self, form):
self.form = form
form.elements.append(self)
If you make the reference from Element to Form a weak reference,
it won't
> On 16 Jan 2024, at 12:10, Frank Millman via Python-list
> wrote:
>
> My problem is that my app is quite complex, and it is easy to leave a
> reference dangling somewhere which prevents an object from being gc'd.
What I do to track these problems down is use gc.get_objects() then
> On 16 Jan 2024, at 13:17, Thomas Passin via Python-list
> wrote:
>
> The usual advice is to call deleteLater() on objects derived from PyQt
> classes. I don't know enough about PyQt to know if this takes care of all
> dangling reference problems, though.
It works well and robustly.
On Wed, 17 Jan 2024 at 01:45, Frank Millman via Python-list
wrote:
>
> On 2024-01-16 2:15 PM, Chris Angelico via Python-list wrote:
> >
> > Where do you tend to "leave a reference dangling somewhere"? How is
> > this occurring? Is it a result of an incomplete transaction (like an
> > HTTP request
On 2024-01-16 2:15 PM, Chris Angelico via Python-list wrote:
Where do you tend to "leave a reference dangling somewhere"? How is
this occurring? Is it a result of an incomplete transaction (like an
HTTP request that never finishes), or a regular part of the operation
of the server?
I have a
On 1/16/2024 4:17 AM, Barry wrote:
On 16 Jan 2024, at 03:49, Thomas Passin via Python-list
wrote:
This kind of thing can happen with PyQt, also. There are ways to minimize it
but I don't know if you can ever be sure all Qt C++ objects will get deleted.
It depends on the type of object
On Tue, 16 Jan 2024 at 23:08, Frank Millman via Python-list
wrote:
>
> On 2024-01-15 3:51 PM, Frank Millman via Python-list wrote:
> > Hi all
> >
> > I have read that one should not have to worry about garbage collection
> > in modern versions of Python - it 'just works'.
> >
> > I don't want to
On 2024-01-15 3:51 PM, Frank Millman via Python-list wrote:
Hi all
I have read that one should not have to worry about garbage collection
in modern versions of Python - it 'just works'.
I don't want to rely on that. My app is a long-running server, with
multiple clients logging on, doing
> On 16 Jan 2024, at 03:49, Thomas Passin via Python-list
> wrote:
>
> This kind of thing can happen with PyQt, also. There are ways to minimize it
> but I don't know if you can ever be sure all Qt C++ objects will get deleted.
> It depends on the type of object and the circumstances.
On 1/15/2024 9:47 PM, Akkana Peck via Python-list wrote:
I wrote:
Also be warned that some modules (particularly if they're based on libraries
not written in Python) might not garbage collect, so you may need to use other
methods of cleaning up after those objects.
Chris Angelico writes:
On Tue, 16 Jan 2024 at 13:49, Akkana Peck via Python-list
wrote:
>
> I wrote:
> > > Also be warned that some modules (particularly if they're based on
> > > libraries not written in Python) might not garbage collect, so you may
> > > need to use other methods of cleaning up after those objects.
I wrote:
> > Also be warned that some modules (particularly if they're based on
> > libraries not written in Python) might not garbage collect, so you may need
> > to use other methods of cleaning up after those objects.
Chris Angelico writes:
> Got any examples of that?
The big one for me was
On Tue, 16 Jan 2024 at 06:32, Akkana Peck via Python-list
wrote:
>
> > Frank Millman wrote at 2024-1-15 15:51 +0200:
> > >I have read that one should not have to worry about garbage collection
> > >in modern versions of Python - it 'just works'.
>
> Dieter Maurer via Python-list writes:
> > There
> Frank Millman wrote at 2024-1-15 15:51 +0200:
> >I have read that one should not have to worry about garbage collection
> >in modern versions of Python - it 'just works'.
Dieter Maurer via Python-list writes:
> There are still some isolated cases when not all objects
> in an unreachable cycle
Frank Millman wrote at 2024-1-15 15:51 +0200:
>I have read that one should not have to worry about garbage collection
>in modern versions of Python - it 'just works'.
There are still some isolated cases when not all objects
in an unreachable cycle are destroyed
(see e.g. step 2 of
> I do have several circular references. My experience is that if I do not
> take some action to break the references when closing the session, the
> objects remain alive. Below is a very simple program to illustrate this.
>
> Am I missing something? All comments appreciated.
Python has normal
Hi all
I have read that one should not have to worry about garbage collection
in modern versions of Python - it 'just works'.
I don't want to rely on that. My app is a long-running server, with
multiple clients logging on, doing stuff, and logging off. They can
create many objects, some of
20 matches
Mail list logo
