A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from http://mail.python.org/pipermail/python-dev/attachments/20140204/79c79582/attachment.html below:

<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      <br>
      On 02/03/2014 02:26 PM, Antoine Pitrou wrote:<br>
    </div>
    <blockquote cite="mid:20140203232605.71dd64f6@fsol" type="cite">
      <pre wrap="">How do you create an array that mixes PyMethodDefs and PyMethodDefExs
together?</pre>
    </blockquote>
    <br>
    You're right, you wouldn't be able to.  For my PyMethodDefEx
    proposal, the entire array would have to be one way or the other.<br>
    <br>
    <br>
    <blockquote cite="mid:20140203232605.71dd64f6@fsol" type="cite">
      <pre wrap="">It sounds like METH_SIGNATURE is the wrong mechanism.
Instead, you may want a tp_methods_ex as well as as a
Py_TPFLAGS_HAVE_METHODS_EX.</pre>
    </blockquote>
    <br>
    You may well be right.  We'd already need a flag on the type object
    anyway, to indicate "tp_doc start with a signature".  So if we had
    such a flag, it could do double-duty to also indicate "tp_methods
    points to PyMethodDefEx structures".<br>
    <br>
    My only concern here: __text_signature__ is supported on five
    internal objects: PyCFunctionObject, PyTypeObject,
    PyMethodDescr_Type, _PyMethodWrapper_Type, and PyWrapperDescr_Type. 
    I'm not certain that all of those carry around their own pointer
    back to their original type object.<br>
    <br>
    If you went off the "self" parameter, you wouldn't have one if you
    were an unbound method.  And you might get the wrong answer if the
    user bound you to a different class, or if you were accessed through
    a subclass.  (I say "might" not to mean "it could happen sometimes",
    but rather "I don't know what the correct answer is".)<br>
    <br>
    <br>
    <blockquote cite="mid:20140203232605.71dd64f6@fsol" type="cite">
      <pre wrap="">Note that this constrains future growth to only add pointer fields,
unless you also add a couple of long fields. But at least it sounds
workable.</pre>
    </blockquote>
    <br>
    Ah, in the back of my mind I meant to say "add some unused union
    {void *p; long i;} fields".  Though in practice I don't think we
    support any platforms where sizeof(long) > sizeof(void *).<br>
    <br>
    <br>
    <blockquote cite="mid:20140203232605.71dd64f6@fsol" type="cite">
      <pre wrap="">Uh... If you write a "conversion function", you may as well make it so
it converts the "sig=" line to a plain signature line in 3.3, which
avoids the issue entirely.</pre>
    </blockquote>
    <br>
    Yeah, that's an improvement, though it makes the conversion function
    a lot more complicated, and presumably uses more memory.<br>
    <br>
    <br>
    <blockquote cite="mid:20140203232605.71dd64f6@fsol" type="cite">
      <pre wrap="">(and how would that conversion function be shipped to the user anyway?
Python 3.3 and the stable ABI don't have it)
</pre>
    </blockquote>
    <br>
    As a C function in a text file, that they'd have to copy into their
    program.  I know it's ugly.<br>
    <br>
    <br>
    <i>/arry</i><br>
  </body>
</html>

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4