> Looks about equivalent, but "survivors" may mean two different things
> depending on if it removes deleted survivors or not. Splitting that
> up, we get this form:
>
> old <= survivors * 2.0 + deleted * 1.0
What precisely would be the "deleted" count? If it counts deallocations,
is it relevant
On Sat, Jun 28, 2008 at 5:39 PM, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Nick Coghlan wrote:
>
>> It's a fact of Python development: __del__ methods cannot safely reference
>> module globals, because those globals may be gone by the time that method is
>> invoked.
>
> Speaking of this, has there be
On Sat, Jun 28, 2008 at 2:42 PM, "Martin v. Löwis" <[EMAIL PROTECTED]> wrote:
>> The effect is similar for the "batch allocation" case, but opposite
>> for the "long-running program" case.
>
> I don't understand. Where is the difference?
>
>> My proposal can be made equivalent to Martin's proposal
On Sat, Jun 28, 2008 at 4:46 PM, Raymond Hettinger <[EMAIL PROTECTED]> wrote:
> From: "Mark Dickinson" <[EMAIL PROTECTED]>
>>
>> There's one other major difference between the C99 notation and the
>> current patch: the C99 notation includes a (hexa)decimal point. The
>> advantages of this include
Nick Coghlan wrote:
It's a fact of Python development: __del__ methods cannot safely
reference module globals, because those globals may be gone by the time
that method is invoked.
Speaking of this, has there been any more thought given
to the idea of dropping the module clearing and just
rel
From: "Mark Dickinson" <[EMAIL PROTECTED]>
There's one other major difference between the C99 notation and the
current patch: the C99 notation includes a (hexa)decimal point. The
advantages of this include:
- the exponent gives a rough idea of the magnitude of the number, and
- the exponent do
> The effect is similar for the "batch allocation" case, but opposite
> for the "long-running program" case.
I don't understand. Where is the difference?
> My proposal can be made equivalent to Martin's proposal by removing
> all of its pending traces when an untraced object is deleted. We
> cou
On Sat, Jun 28, 2008 at 12:47 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Adam Olsen gmail.com> writes:
>>
>> We need two counters: one is the total number of traceable objects
>> (those we would inspect if we did a full collection) and a number of
>> "pending" trace operations. Every time an
> It sounds rather similar to Martin's proposal, except with different
> coefficients and slightly different definitions (but the "total number
> of traceable objects" should be roughly equal to the number of objects
> in the oldest generation, and the "number of pending trace operations"
> roughly
Adam Olsen gmail.com> writes:
>
> We need two counters: one is the total number of traceable objects
> (those we would inspect if we did a full collection) and a number of
> "pending" trace operations. Every time an object is moved into the
> last generation, we increase "pending" by two - once
> I hope this the correct place to report this...
Hi, Roger.
Please file a bug report at http://bugs.python.org/, and assign it to
me. Please attach a patch for the change you made to the unit test
suite to send >16K.
Thanks!
Bill
___
Python-Dev mail
On Sat, Jun 28, 2008 at 1:30 AM, tomer filiba <[EMAIL PROTECTED]> wrote:
> On Jun 28, 12:56 am, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
>> No, it could just be a harmless typo in a long argument list.
>
> to elaborate on this point a little, i came across this error when i
> ported my code to
> Example:
>
> import os
> class RunningFile(object):
> filename = '/tmp/running'
> def __init__(self):
> open(self.filename, 'wb')
> def __del__(self):
> os.unlink(self.filename)
> running_file = RunningFile()
>
> The deller object is in a cycle as described above [as
Roger, can you show us the relevant code?
On Sat, Jun 28, 2008 at 5:59 AM, Roger wenham <[EMAIL PROTECTED]> wrote:
> HI,
>
> I have used the SSL lib to wrap sockets in existing client server code, but I
> find that
> the max send size is 16K. In other words I send 20K, the write call returns
> 2
Eyal Lotem wrote:
Example:
import os
class RunningFile(object):
filename = '/tmp/running'
def __init__(self):
open(self.filename, 'wb')
def __del__(self):
os.unlink(self.filename)
running_file = RunningFile()
The deller object is in a cycle as described above [as wel
I see why a cycle that has multiple objects with a __del__ method is a problem.
Once you call __del__ on one of the objects, its no longer usable by
the others, and its not clear which order is correct.
My question regards the case where a cycle of objects only has 1
object which has a __del__.
HI,
I have used the SSL lib to wrap sockets in existing client server code, but I
find that
the max send size is 16K. In other words I send 20K, the write call returns 20K
but the receiving end only gets 16K.
I remove the wraper and everything worksagain.
I even modified the unit test to send >
> Perhaps they should be backported to the maintenance as warnings? Then
> users can decide on a case-by-case basis if they want to make that
> particularly warning trigger an exception.
No. There will likely be one more 2.5 release. This entire issue never
came up in the lifetime of 2.5, so it ca
> i'd be in favor of fixing this in 2.5, just to eliminate possibly hard-
> to-debug runtime errors. since it's a syntax error, it would be early-
> noticed when the code is first run/imported, and it wouldn't require
> the original author of the code to fix.
As release manager for Python 2.5, I'd
Guido van Rossum wrote:
In such cases I think it's better not to introduce new exceptions in
point-point releases.
Perhaps they should be backported to the maintenance as warnings? Then
users can decide on a case-by-case basis if they want to make that
particularly warning trigger an exceptio
On Jun 28, 12:56 am, "Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> No, it could just be a harmless typo in a long argument list.
to elaborate on this point a little, i came across this error when i
ported my code to 2.4. i used the optparse class which takes 10's of
kwargs, and it turned out i'd
> I didn't see any recent discussion about this so I thought I'd ask
> here: do you think this would make a good addition to the new urllib
> package?
Just in case that isn't clear: any such change must be delayed for
2.7/3.1. That is not to say that you couldn't start implementing it
now, of cour
Jeff Hall wrote:
> That's all fine and good but in this case there may be "stealth errors".
That is fully understood, in all of its consequences.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/p
23 matches
Mail list logo
