Sorry for late post.
On 2010/09/29 20:01, Antoine Pitrou wrote:
Furthermore, it can produce real bugs, especially under Windows when
coupled with refererence cycles created by traceback objects
I think this can be relaxed with the patch in #9815. ;-)
___
On 29 September 2010 22:25, Nick Coghlan wrote:
> On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw wrote:
>> I don't think it should be in the gc module, but I would prefer it be enabled
>> and controlled through a separate module, rather than something Python does
>> automatically for your conveni
On Wed, Sep 29, 2010 at 11:40 PM, Barry Warsaw wrote:
> I don't think it should be in the gc module, but I would prefer it be enabled
> and controlled through a separate module, rather than something Python does
> automatically for your convenience.
The os module would seem to be the place to ena
On Wed, Sep 29, 2010 at 9:31 AM, Brett Cannon wrote:
> On Wed, Sep 29, 2010 at 05:42, Antoine Pitrou wrote:
>>
>> Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
>>> >
>>> > I would like to piggy-back on this discussion to suggest further
>>> > warnings (either by default
On Wed, Sep 29, 2010 at 05:42, Antoine Pitrou wrote:
>
> Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
>> >
>> > I would like to piggy-back on this discussion to suggest further
>> > warnings (either by default, or switchable).
>> >
>> > One feature I've often considered
On Sep 29, 2010, at 11:11 PM, Steven D'Aprano wrote:
>On Wed, 29 Sep 2010 10:42:27 pm Antoine Pitrou wrote:
>
>> My assumption is/was that the benefit of warning against leaks in
>> real applications (or even - sigh - the standard library) would
>> outweigh the inconvenience when hacking together
On 09/29/2010 02:42 PM, Antoine Pitrou wrote:
It seems like a slippery slope. Sometimes you really don't care like
when you're just hacking together a quick script.
Isn't the "with" statement appropriate in these cases?
A hacked-together quick script might contain code like:
parse(open(bla
On Wed, 29 Sep 2010 10:42:27 pm Antoine Pitrou wrote:
> My assumption is/was that the benefit of warning against leaks in
> real applications (or even - sigh - the standard library) would
> outweigh the inconvenience when hacking together a quick script.
>
> But if it doesn't, what about enabling
Le mercredi 29 septembre 2010 à 07:27 -0500, Benjamin Peterson a écrit :
> >
> > I would like to piggy-back on this discussion to suggest further
> > warnings (either by default, or switchable).
> >
> > One feature I've often considered would be to add a warning in FileIO
> > and socket dealloc if
On Wed, Sep 29, 2010 at 14:27, Benjamin Peterson wrote:
> It seems like a slippery slope. Sometimes you really don't care like
> when you're just hacking together a quick script.
Yeah, I often don't close files in scripts that I know are short
running or only ever open one or two files, and I don
2010/9/29 Antoine Pitrou :
>
> Hello,
>
>> I'd like to ask your opinion on this change; I think it should be reverted
>> or at least made silent by default. Basically, it prints a warning like
>>
>> gc: 2 uncollectable objects at shutdown:
>> Use gc.set_debug(gc.DEBUG_UNCOLLECTABLE
Hello,
> I'd like to ask your opinion on this change; I think it should be reverted
> or at least made silent by default. Basically, it prints a warning like
>
> gc: 2 uncollectable objects at shutdown:
> Use gc.set_debug(gc.DEBUG_UNCOLLECTABLE) to list them.
>
> at interpreter
12 matches
Mail list logo
