Tim Peters wrote:
> Python-style refcounting isn't generally a good approach either when
> real-time constraints must be met: when a refcount on an object P
> falls to 0, not only does the interpreter "pause" to reclaim P, but
> also to reclaim all the objects that were reachable only from P.
Sur
[EMAIL PROTECTED] wrote:
> Paul> In the old days, it was possible to post stuff to Python's
> Paul> sourceforge pages without logging in. That was turned off for
> Paul> various reasons that weren't bogus, but that didn't strike me as
> Paul> overwhelmingly compelling. Maybe that
[EMAIL PROTECTED] wrote:
> Fine with me. Is it ready to go though? If not, what more needs to be
> done? I was under the assumption that it wasn't ready for prime time and
> solicited inputs on c.l.py in a couple messages yesterday and today.
Primarily, it needs a dedicated operator. Somebody w
Passing along from c.l.py. I think ElementTree is the poster child for
best-of-breed code belonging in the standard distribution. Its API is so
much better than what we have there now that assuming any non-technical
issues can be solved (licensing, duplicate copies of the source code) that
Eleme
[Tim Peters]
>> Python-style refcounting isn't generally a good approach either when
>> real-time constraints must be met: when a refcount on an object P
>> falls to 0, not only does the interpreter "pause" to reclaim P, but
>> also to reclaim all the objects that were reachable only from P.
[Mar
[EMAIL PROTECTED] wrote:
> Passing along from c.l.py. I think ElementTree is the poster child for
> best-of-breed code belonging in the standard distribution.
That's primarily for the author of the software to decide, at this
point. Fredrik Lundh would have to offer it for contribution first.
I
Martin> [EMAIL PROTECTED] wrote:
>> Passing along from c.l.py. I think ElementTree is the poster child
>> for best-of-breed code belonging in the standard distribution.
Martin> That's primarily for the author of the software to decide, at
Martin> this point. Fredrik Lundh wou
Tim Peters <[EMAIL PROTECTED]> wrote:
> > ...
>
> > In a specific program, analysis is much brighter. You *know* what
> > variables carry references to huge data structures, and you *know*
> > where these variables are assigned to.
>
> > ...
>
> Most people work with countless lines of library
[Josiah Carlson]
> I believe this particular argument is specious.
Not at all, but it's not compelling on its own.
> Using Python won't change requirements for knowing what is or is
> not referenced during program execution for "real time" development.
> Further, "real time" developers won't be
Martin v. Löwis wrote:
> [EMAIL PROTECTED] wrote:
>
>>Passing along from c.l.py. I think ElementTree is the poster child for
>>best-of-breed code belonging in the standard distribution.
>
>
> That's primarily for the author of the software to decide, at this
> point. Fredrik Lundh would have to
Jim Fulton wrote:
[...]
>
> I hope that packaging progress will someday make it matter much less
> whether something is in the standard library.
>
For which we need a *mechanism* that all package providers can
implement, rather than a repository to which all package providers must
contribute.
Steve Holden wrote:
> Jim Fulton wrote:
> [...]
>
>>I hope that packaging progress will someday make it matter much less
>>whether something is in the standard library.
>>
>
> For which we need a *mechanism* that all package providers can
> implement, rather than a repository to which all packag
Jim> I hope that packaging progress will someday make it matter much
Jim> less whether something is in the standard library.
It undoubtedly will. The point I was trying to raise here is that
ElementTree is so much better than the stuff we currently distribute (*)
that it should be includ
[EMAIL PROTECTED] wrote:
> Jim> I hope that packaging progress will someday make it matter much
> Jim> less whether something is in the standard library.
>
> It undoubtedly will. The point I was trying to raise here is that
> ElementTree is so much better than the stuff we currently distr
At 04:45 PM 12/8/2005 -0500, Jim Fulton wrote:
>I think we need both. We need the mechanism and repositories, although
>non necessarily one repository. Phillip Eby and others seem to be making
>wonderful progress on the mechanism.
And FYI, it does not depend on a single repository. TurboGears,
Le Vendredi 25 Novembre 2005 15:54, Aahz a écrit :
> On Fri, Nov 25, 2005, Victor STINNER wrote:
> > I found a bug in bz2 python module. Example:
> >
> > Details and *patch* at:
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1366000&group_id
> >=5470&atid=105470
>
> Thanks! Particula
Tim Peters <[EMAIL PROTECTED]> wrote:
>
> [Josiah Carlson]
> > I believe this particular argument is specious.
>
> Not at all, but it's not compelling on its own.
I like that better.
> > Using Python won't change requirements for knowing what is or is
> > not referenced during program executio
Title: Documentation about Python's GC, python-dev list messages referenced in Modules/gcmodule.c not reachable anymore
Hi All,
Hi Neil,
While searching documentation about Pythons GC and it's behaviour I found references to the python-dev list in ``Modules/gcmodule.c``.
But unfortunatel
Guido van Rossum wrote:
> Um, that does't work for types which customize __getattribute__ or
> __getattr__ in various ways.
There could be a __hasattr__ slot in the class itself for
that purpose.
> IMO a property that has a side effect (other than updating a cache or
> statistics or perhaps logg
Calvin Spealman wrote:
> I will have to disagree with you there. If hasattr(a,b) returns True,
> one should be able to expect a.b will work properly. Otherwise, the
> majority of use cases for hasattr will be completely thrown out the
> window. How can hasattr work properly with properties if it d
Gregoire> But unfortunately the links to the list do not work
Gregoire> anymore. May someone give me a hint how to find the messages
Gregoire> (2. to 4. below).
Gregoire> 2.
http://www.python.org/pipermail/python-dev/2000-March/003869.html
Gregoire> 3.
http://www.python.
21 matches
Mail list logo
