On Mon, Feb 3, 2014 at 8:04 AM, Larry Hastings <la...@hastings.org> wrote:
> On 02/03/2014 07:08 AM, Barry Warsaw wrote: > > On Feb 03, 2014, at 06:43 AM, Larry Hastings wrote: > > > But that only fixes part of the problem. Our theoretical extension that > wants to be binary-compatible with 3.3 and 3.4 still has a problem: how can > they support signatures? They can't give PyMethodDefEx structures to 3.3, it > will blow up. But if they don't use PyMethodDefEx, they can't have > signatures. > > Can't an extension writer #ifdef around this? Yeah, it's ugly, but it's a > pretty standard approach for making C extensions multi-version compatible. > > > For source compatibility, yes. But I thought the point of the binary ABI > was to allow compiling a single extension that worked unmodified with > multiple versions of Python. If we simply don't support that, then an > ifdef would be fine. > Wouldn't your proposal to extend the PyMethodDef structure would require ifdef's and make it impossible to include the type information in something compiled against the 3.3 headers that you want to use in 3.4 without recompiling? If you don't like seeing an sig= at the front of the docstring couldn't you just move it to the end of the docstring. I don't think messiness in docstrings when running something read for 3.4 under 3.3 is a big deal. [side note] I consider it CRAZY for anyone to load a binary extension module compiled for one version in a later version of Python. People do it, I know, but they're insane. I wish we didn't bother trying to support that crap. I know this isn't going to change in 3.4. Just ranting. [/side note] -gps
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
