Larry Hastings wrote:
> I knocked out a prototype of this last week, emailed Mr. Lundh about it,
> then forgot about it.
It's on my TODO list, so I haven't forgotten about it, but I've been (as
usual) busy with other stuff. I'll get there, sooner or later.
Posting this to the patch tracker an
Fredrik Lundh wrote:
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension has implemented, and
code on the other side that builds a properly initialized type descriptor from that
set, using fallback functions
Hi Fredrik,
On Fri, Oct 13, 2006 at 11:22:09AM +0200, Fredrik Lundh wrote:
> > > static PyTypeObject NoddyType;
> > static PyTypeObject *NoddyType;
>
> yeah, that's a silly typo.
Ah, then ignore my previous remark.
Armin
___
Python-Dev maili
Nick Coghlan wrote:
> > would collapse to
> >
> > static PyTypeObject NoddyType;
>
> Wouldn't that have to be a pointer to allow the Python runtime complete
> control of the structure size without recompiling the extension?:
>
> static PyTypeObject *NoddyType;
yeah, that's a silly typo.
Fredrik Lundh wrote:
> Martin v. Löwis wrote:
>
>> Of course, if everybody would always recompile all extension modules
>> for a new Python feature release, those flags weren't necessary.
>
> a dynamic registration approach would be even better, with a single entry
> point
> used to register all
Armin Rigo wrote:
>> NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy));
>
> It doesn't address the problem Martin explained (you can put neither
> NULLs nor stubs in tp_xxx fields that are beyond the C extension
> module's sizeof(Nobby)). But I imagine it could with a bit more
> tweaking
Hi Fredrik,
On Wed, Oct 11, 2006 at 12:35:23PM +0200, Fredrik Lundh wrote:
> NoddyType = PyType_Setup("noddy.Noddy", sizeof(Noddy));
It doesn't address the problem Martin explained (you can put neither
NULLs nor stubs in tp_xxx fields that are beyond the C extension
module's sizeof(Nobby)).
On 10/11/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
Martin v. Löwis wrote:> Of course, if everybody would always recompile all extension modules> for a new Python feature release, those flags weren't necessary.a dynamic registration approach would be even better, with a single entry point
used to
I wrote:
>PyType_Register(NoddyType, PY_TP_METHODS, Noddy_methods);
methods and members could of course be registered to, so the implementation can
chose
how to store them (e.g. short lists for smaller method lists, dictionaries for
others).
___
Martin v. Löwis wrote:
> Of course, if everybody would always recompile all extension modules
> for a new Python feature release, those flags weren't necessary.
a dynamic registration approach would be even better, with a single entry point
used to register all methods and hooks your C extension
Raymond Hettinger schrieb:
>> the slightly obscure bit that requires some getting used to is
>> that all these flags don't really mean "I have such and such
>> feature" but just "I could have such and such
>> feature, if the corresponding tp_xxx field were set".
>
> I would like to see that clea
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Oct 10, 2006, at 5:47 PM, Raymond Hettinger wrote:
>> the slightly obscure bit that requires some getting used to is
>> that all these flags don't really mean "I have such and such
>> feature" but just "I could have such and such
>> feature, if the
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it easier on
> the brain when verifying code that checks the weakref flag.
> I don't understand why you added this flag here;
Perhaps my other post wasn't clear. The
Hi Raymond,
On Fri, Oct 06, 2006 at 08:48:15AM -0700, Raymond Hettinger wrote:
> No need to backport. Py_TPFLAGS_DEFAULT implies
> Py_TPFLAGS_HAVE_WEAKREFS.
>
>
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it
On Fri, Oct 06, 2006 at 08:48:15AM -0700, Raymond Hettinger wrote:
> The change was for clarity -- most things that have the weakref slots
> filled-in will also make the flag explicit -- that makes it easier on
> the brain when verifying code that checks the weakref flag.
OK; I won't backport this
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of A.M. Kuchling
Sent: Friday, October 06, 2006 6:41 AM
To: python-dev@python.org
Subject: [Python-Dev] 2.4.4: backport classobject.c HAVE_WEAKREFS?
I was looking at the logs for classobject.c and noticed this commit
I was looking at the logs for classobject.c and noticed this commit
that adds Py_TPFLAGS_HAVE_WEAKREFS to the instance type. Should it be
backported to 2.4? (It looks to me like it should, but I don't know
anything about weakref implementation and want to get approval from
someone who knows.)
--
17 matches
Mail list logo
