Marcin 'Qrczak' Kowalczyk wrote:
> Why do you want to free memory at a particular point of time?
I don't. However, I *do* want it freed by the time I
need it again, and I *don't* want unpredictable pauses
to catch up on backed-up memory-freeing, so that my
animations run smoothly.
--
Greg
__
Martin v. Löwis wrote:
> Nick Coghlan schrieb:
>> I was thinking it would be easier to split out the Global Interpreter Lock
>> and
>> a per-interpreter Local Interpreter Lock, rather than trying to go to a full
>> free-threading model. Anyone sharing other objects between interpreters
>> would
Greg Ewing <[EMAIL PROTECTED]> writes:
>> Why do you want to free memory at a particular point of time?
>
> I don't. However, I *do* want it freed by the time I need it again,
As I said, the rate of GC depends on the rate of allocation.
Unreachable objects are collected when memory is needed for
Michael Chermside wrote:
> The following comments got me thinking:
>
> Raymond:
>> Statistics incontrovertibly prove that people who habitually
>> avoid __del__ lead happier lives and spend fewer hours in therapy ;-)
>
> Adam Olsen:
>> I agree here. I think an executor approach is much better; k
Before we can decide on the internal representation of our unicode
objects, we need to decide on their external interface. My thoughts
so far:
* Most transformation and testing methods (.lower(), .islower(), etc)
can be copied directly from 2.x. They require no special
implementation to perform
Martin v. Löwis wrote:
> The only exception would be if somebody offered a reasonable
> solution, which "we" would just have to incorporate (and possibly
> maintain, although it would be good if the original author would
> be around for a year or so).
I am interested in doing just this. I'm loathe
Nick Coghlan writes:
[...proposes revision of __del__ rather than removal...]
> The only way for __del__ to receive a reference to self is if the
> finalizer argument had a reference to it - but that would mean the
> object itself was not
> collectable, so __del__ wouldn't be called in the
Jim Jewett wrote:
>> > Ivan: why don't you write a PEP about this?
>
>> I'd like to hear Guido's overarching thoughts on the matter, if any, and
>> would afterwards be happy to write a PEP.
The `this` and `the matter` referred not to removing the GIL, but
providing some form of sane multiprocessi
Jean-Paul Calderone wrote:
>>> Since we're apparently still in "propose wild ideas" mode for Py3K
>>> I'd like to propose that for Py3K we remove __del__. Not "fix" it,
>>> not "tweak" it, just remove it and perhaps add a note in the manual
>>> pointing people to the weakref module.
>>
>>
>> I don
Ivan Krstić wrote:
> The `this` and `the matter` referred not to removing the GIL, but
> providing some form of sane multiprocessing support that doesn't require
> everyone interested in MP to reinvent the wheel.
no need to wait for Guido for this: adding library support for shared-
memory dictio
Fredrik Lundh wrote:
> no need to wait for Guido for this: adding library support for shared-
> memory dictionaries/lists is a no-brainer. if you have experience in
> this field, start hacking. I'll take care of the rest ;-)
and no need to wait for Python 3000 either, of course -- I see no rea
Fredrik Lundh wrote:
> no need to wait for Guido for this: adding library support for shared-
> memory dictionaries/lists is a no-brainer. if you have experience in
> this field, start hacking. I'll take care of the rest ;-)
and you don't need to wait for Python 3000 either, of course -- if
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> Before we can decide on the internal representation of our unicode
> objects, we need to decide on their external interface. My thoughts
> so far:
I believe the only options up for actual decision is what the internal
representation of a unicode object w
Giovanni Bajo writes:
> I believe my example is a good use case for __del__ with no good
> enough workaround, which was requested by Micheal in the original post. I
> believe that it would be a mistake to remove __del__ unless we provide a
> graceful alternative (and I don't consider the code above
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Before we can decide on the internal representation of our unicode
> objects, we need to decide on their external interface. My thoughts
> so far:
Let me cut this short. The external string API in Py3k should not
change or only very marginally s
Greg Ewing writes:
> A worry about that is whether the architecture required to
> allow pluggable GC implementations introduces inefficiencies
> of its own that would skew the results.
Bob Ippolito
> There's no need to worry about that in the case of PyPy. Those kinds
> of choices are made way bef
On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
> > so far:
> I believe the only options up for actual de
On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
> > so far:
>
> I believe the only options up for actual
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
> > so far:
>
> Let me cut this short. The exte
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:> > Before we can decide on the internal representation of our unicode
> > objects, we need to decide on their external interface. My thoughts
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > Before we can decide on the internal representation of our unicode
> > > objects, we need to decide on their external interface. M
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > Before we can decide on the internal representation of our unicode
On 9/20/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> Giovanni Bajo writes:
> > I believe my example is a good use case for __del__ with no good
> > enough workaround, ... I still like the __close__ method being proposed.
[Michael asks about this alternative]
...
> def on_del_invoke(obj, func
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > Let me cut this short. The external string API in Py3k should not
> > > change or only very marginally so (like removing rar
"Jim Jewett" <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > > Before we can decide on the internal representation of our unicode
> > > objects, we need to decide on their external interface. My thoughts
> > > s
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
>
> On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > > Before we can decide on the internal representation of our unicode
> > > objects, we need to decide on their external interface. My thoughts
> >
Josiah Carlson <[EMAIL PROTECTED]> writes:
> Regardless of our choice, *some platform* is going to be angry. Why?
> GTK takes utf-8 encoded strings. (I don't know what Qt or linux system
> calls take) Windows takes utf-16.
The representation of QChar in Qt-3.3.5:
ushort ucs;
#if defined(Q
Michael Chermside <[EMAIL PROTECTED]> wrote:
>from deletions import on_del_invoke
>
>class Wrapper:
>def __init__(self, *args):
>self.handle = CAPI.init(*args)
>on_del_invoke(self, CAPI.close, self.handle)
>
>def foo(self):
>CAPI.foo(self
Guido writes:
> > As far as I can tell, CPython on windows uses UTF-16 with code units.
> > Perhaps not intentionally, but by default (not throwing an error on
> > surrogates).
>
> This is intentional, to be compatible with the rest of that platform.
> Jython and IronPython do this too I believe.
I wrote:
>>> msg = u'The ancient greeks used the letter "\U00010143" for the number 5.'
>>> msg[35:-18]
u'"\U00010143"'
>>> greek_five = msg[36:-19]
>>> len(greek_five)
2
After posting, I realized that it's worse than that. I suspect that if
I tried this on a CPython compiled with wide characters
On 9/20/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> I wrote:
> >>> msg = u'The ancient greeks used the letter "\U00010143" for the number 5.'
> >>> msg[35:-18]
> u'"\U00010143"'
> >>> greek_five = msg[36:-19]
> >>> len(greek_five)
> 2
>
>
> After posting, I realized that it's worse than that
On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
>
> "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> >
> > On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > >
> > > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
[snip token stuff]
Withdrawn. Blake Winston pointed me to some problems in private a
Jim Jewett <[EMAIL PROTECTED]> wrote:
>>> I believe my example is a good use case for __del__ with no good
>>> enough workaround, ... I still like the __close__ method being
>>> proposed.
>
> [Michael asks about this alternative]
> ...
>> def on_del_invoke(obj, func, *args, **kwargs):
> ...
>>
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Michael Chermside <[EMAIL PROTECTED]> wrote:
> > I wrote:
> > >>> msg = u'The ancient greeks used the letter "\U00010143" for the number
> > >>> 5.'
> > >>> msg[35:-18]
> > u'"\U00010143"'
> > >>> greek_five = msg[36:-19]
> > >>
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> Wow, you really did mean code units. In that case I'm very tempted to
> support UTF-8, with byte indexing (which is what code units are in its
> case). It's ugly, but it technically works fine, and it's the de
> facto standard on Linux. No more
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Even if CPython 3.0 supports a dynamic choice (which some are
> proposing) then the *language* will still make it implementation
> dependent because of Jython and IronPython, where the only choice
> is UTF-16 (or UCS-2, depending the attitude toward
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > Wow, you really did mean code units. In that case I'm very tempted to
> > support UTF-8, with byte indexing (which is what code units are in its
> > case). It's ugly, but it technically
"Adam Olsen" <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> >
> > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
> > >
> > > On 9/20/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > > >
> > > > "Adam Olsen" <[EMAIL PROTECTED]> wrote:
>
> [snip token stuff]
>
> Wit
Marcin 'Qrczak' Kowalczyk wrote:
> Incremental GC (e.g. in OCaml) has short pauses. It doesn't scan all
> memory at once, but distributes the work among GC cycles.
Can it be made to guarantee that no pause will
be longer than some small amount, such as 20ms?
Because that's what is needed to ensur
Michael Chermside wrote:
>* Programmers no longer have the ability to allow __del__
> to resurect the object being finalized.
I've never even considered trying to write such code,
and can't think of any reason why I ever would, so
I wouldn't miss this ability at all.
--
Greg
___
Brett Cannon wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
>> > >
>> > > Before we can decide on the internal representation of our unicode
>> > > objects, we need to decid
Jim Jewett wrote:
> How do you feel about the __del__ in stdlib subprocess.Popen (about line 615)?
>
> This resurrects itself, in order to finish waiting for the child
> process.
I don't see a need for resurrection here. Why can't it
create another object holding the necessary info for
doing the
David Hopwood <[EMAIL PROTECTED]> wrote:
> Brett Cannon wrote:
[snip]
> > If you want that kind of
> > exposure, use the bytes type. Otherwise assume the usage will be by people
> > ignorant of Unicode and thus want something that will work the way they are
> > used to when compared to working in
On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > Wow, you really did mean code units. In that case I'm very tempted to
> > > support UTF-8, with byte indexing (which is what code
On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > On 9/20/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > On 9/20/06, Adam Olsen <[EMAIL PROTECTED]> wrote:
> > > > Wow, you really did mean code units. In that case I'm very tempted
45 matches
Mail list logo
