[Python-Dev] The docstring hack for signature information has to go

[Gregory P. Smith]

On Mon, Feb 3, 2014 at 8:04 AM, Larry Hastings <larry at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20140203/2677b6bd/attachment.html>