Brett Cannon wrote:
> I still remember when Tim proposed
> this and said there was something slightly off with the way weakrefs
> worked for it to be the perfect solution.
If that's true, it might be better to concentrate on
fixing this problem so that weakrefs can be used,
rather than trying to
Chermside, Michael wrote:
> I don't seem to have gotten anyone one board with the bold proposal
> to just rip __del__ out and tell people to learn to use weakrefs.
Well, I'd be in favour of it. I've argued something
similar in the past, without much success then either.
--
Greg
__
On 9/22/06, Aahz <[EMAIL PROTECTED]> wrote:
> On Sat, Sep 23, 2006, Giovanni Bajo wrote:
> >
> > Did you actually read my posts where I have shown some legitimate use
> > cases of __del__ which can't be substituted with short and elegant
> > enough code?
>
> The question is whether those use cases
On Sat, Sep 23, 2006, Giovanni Bajo wrote:
>
> Did you actually read my posts where I have shown some legitimate use
> cases of __del__ which can't be substituted with short and elegant
> enough code?
The question is whether those use cases are frequent enough -- especially
for less-than-wizard pr
Giovanni Bajo wrote:
>I don't use __del__ much. I use it only in leaf classes, where it surely can't
>be part of loops. In those rare cases, it's very useful to me. For instance, I
>have a small classes which wraps an existing handle-based C API exported to
>Python. Something along the lines of:
>
Jim Jewett wrote:
> On 9/22/06, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote:
>> I still think a rather nice solution would be to guarantee to call
>> __del__ (or __close__ or whatever) only once, as was discussed earlier:
>
> How does this help?
It helps by removing many corner cases in the GC t
Raymond Hettinger wrote:
> Is there anything vital that could be done with a __close__ method
> that can't already be done with a weakref callback? We aren't going
> to need it.
It can't be done with the same cleaness and easyness. It will require more
convoluted and complex code. It will requir
On 9/22/06, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
[Michael Chermside]> I don't seem to have gotten anyone one board with the bold> proposal to just rip __del__ out and tell people to learn> to use weakrefs. But I'm hearing general agreement (at least
> among those contributing to this threa
On 9/22/06, Thomas Heller <[EMAIL PROTECTED]> wrote:
> Bob Ippolito schrieb:
> > On 9/22/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> >> On Friday 22 September 2006 13:05, Christian Tanzer wrote:
> >> > It is useful in some situations, though. In particular, I use a
> >> > metaclass that s
Bob Ippolito schrieb:
> On 9/22/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
>> On Friday 22 September 2006 13:05, Christian Tanzer wrote:
>> > It is useful in some situations, though. In particular, I use a
>> > metaclass that sets `__super` to the right value. This wouldn't work
>> > with
On 9/22/06, Fred L. Drake, Jr. <[EMAIL PROTECTED]> wrote:
> On Friday 22 September 2006 13:05, Christian Tanzer wrote:
> > It is useful in some situations, though. In particular, I use a
> > metaclass that sets `__super` to the right value. This wouldn't work
> > without name mangling.
>
> This
On 9/22/06, Carl Friedrich Bolz <[EMAIL PROTECTED]> wrote:
> I still think a rather nice solution would be to guarantee to call
> __del__ (or __close__ or whatever) only once, as was discussed earlier:
How does this help?
It doesn't say how to resolve cycles. This cycle problem is the cause
of m
On Friday 22 September 2006 13:05, Christian Tanzer wrote:
> It is useful in some situations, though. In particular, I use a
> metaclass that sets `__super` to the right value. This wouldn't work
> without name mangling.
This also doesn't work if two classes in the inheritance hierarchy have th
"Raymond Hettinger" <[EMAIL PROTECTED]> wrote:
> I propose dropping the __var private name mangling trick for
> double-underscores.
>
> It is rarely used; it smells like a hack; it complicates instrospection
> tools; it's not beautiful; and it is not in line with Python's spirit of
> "we're all c
Chermside, Michael wrote:
[snip]
> The other problem I discussed is illustrated by the following
> malicious code:
>
> evil_list = []
>
> class MyEvilClass(object):
> def __close__(self):
> evil_list.append(self)
>
>
>
> Do the proponents of __close__ propose a way of prohibiting
> this
Raymond Hettinger wrote:
> FWIW, don't despair on your original bold proposal. While it's fun to
> free associate and generate ideas for new atrocities, I think most of
> your respondants are just kicking ideas around.
Who, us? ;)
> In the spirit of Py3k development, I recommend being quick to r
Raymond Hettinger wrote:
> I'm on-board for just ripping out __del__. [...]
> In the spirit of Py3k development, I recommend being quick to remove and
> slow to add. Let 3.0 emerge without __del__ and if strong use cases
> emerge, there can be a 3.1 PEP for a new magic method. I think Py3k
> shou
Raymond Hettinger wrote:
> I propose dropping the __var private name mangling trick for
> double-underscores.
+1.
--
Ivan Krstić <[EMAIL PROTECTED]> | GPG: 0x147C722D
___
Python-3000 mailing list
Python-3000@python.org
http://mail.python.org/mailman/li
[Michael Chermside]
> I don't seem to have gotten anyone one board with the bold
> proposal to just rip __del__ out and tell people to learn
> to use weakrefs. But I'm hearing general agreement (at least
> among those contributing to this thread) that it might be
> wise to change the status quo
I propose dropping the __var private name mangling trick for
double-underscores.
It is rarely used; it smells like a hack; it complicates instrospection
tools; it's not beautiful; and it is not in line with Python's spirit of
"we're all consenting adults".
Raymond
___
On 9/22/06, Chermside, Michael <[EMAIL PROTECTED]> wrote:
> the code in your __close__ method (or
> __del__) must assume that it might have been in a reference loop
> which was broken in some arbitrary place. As a result, it cannot
> assume that all references it holds are still valid.
Most close
I don't seem to have gotten anyone one board with the bold proposal
to just rip __del__ out and tell people to learn to use weakrefs.
But I'm hearing general agreement (at least among those contributing
to this thread) that it might be wise to change the status quo.
The two kinds of solutions I'm
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sep 22, 2006, at 7:54 AM, Marcin 'Qrczak' Kowalczyk wrote:
> Greg Ewing <[EMAIL PROTECTED]> writes:
>
>> I know. What I mean to say, I think, is can it be designed so that
>> there cannot be any pauses longer than there would have been if
>> freein
Greg Ewing <[EMAIL PROTECTED]> writes:
> I know. What I mean to say, I think, is can it be designed so that
> there cannot be any pauses longer than there would have been if
> freeing had been performed as early as possible by refcounting.
The question is misleading: refcounting also causes pause
Marcin 'Qrczak' Kowalczyk wrote:
> "Giovanni Bajo" <[EMAIL PROTECTED]> writes:
>
>> What if the "self" passed to __del__ was instead a weakref.proxy,
>> or a similar wrapper object which does not give you access to the
>> object itself but lets you access its attributes?
>
> weakref.proxy will fi
25 matches
Mail list logo
