[Python-Dev] Re: 2.1a2 release issues; mail.python.org still down

[Fred L. Drake, Jr.]

M.-A. Lemburg writes:
 > I've only tested these using my mx tools compiled against 1.5 --
 > really old, I know, but I still actively use that version. tp_xxx7/8
 > were added in Python 1.5.2, I think, so writing to them causes
 > the core dump.

  Yep.

I said:
 >   For the specific problem you mention, we could add a type flag
 > (Py_TPFLAGS_HAVE_WEAKREFS) that could be tested; it would be set in
 > Py_TPFLAGS_DEFAULT.

M-A replied:
 > That would work, but is it really worth it ? The APIs have changed
 > considerably, so the fact that I got away with a warning in Python2.0

  No, which is why I'm happy to tell you to recomple your extensions.

 > doesn't really mean anything -- I do have a problem now, though,
 > since maintaining versions for 1.5, 1.5.2, 2.0 and 2.1 will
 > be a pain :-/

  Unless you're using PyCode_New() or PyFrame_New(), recompiling the
extension should be all you'll need -- unless you're pulling stunts
like ExtensionClass does (defining a type-like object using an old
definition of PyTypeObject).  If any of the functions you're calling
have changed signatures, you'll need to update them anyway.  The
weakref support will not cause you to change your code unless you want
to be able to refer to your extension types via weak refs.

 > Py_FatalError() is a bit too harsh, I guess. Wouldn't it
 > suffice to raise an ImportError exception and have Py_InitModule()
 > return NULL in case a module with an incompatible API version is 
 > encountered ?

  I suppose we could do that, but it'll take more than my agreement to
make that happen.  Guido seemed to think that few modules will be
calling PyCode_New() and PyFrame_New() directly (pyexpat being the
exception).


  -Fred

-- 
Fred L. Drake, Jr.  <fdrake at acm.org>
PythonLabs at Digital Creations