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 and
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 mailing
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 methods
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. or maybe
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)).
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
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).
/F
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
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
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
-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
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 cleaned-up for
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.)
-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
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.
16 matches
Mail list logo
