Am 05.02.14 17:04, schrieb Georg Brandl:
> Mostly unrelated question while seeing the "char *" here: do we (or do we
> want to) support non-ASCII names for functions implemented in C?
I didn't try, but I think it should work.
methodobject.c:meth_get__name__ uses PyUnicode_FromString, which in turn
On 02/05/2014 05:52 AM, "Martin v. Löwis" wrote:
D: Add a new type slot for method signatures. This would be a
tp_signature field, along with a new slot id Py_tp_signature. The
signature field itself could be
struct PyMethodSignature {
char *method_name;
char *method_signature;
};
Tha
On Wed, Feb 5, 2014 at 11:04 AM, Georg Brandl wrote:
> Am 05.02.2014 14:52, schrieb "Martin v. Löwis":
> > Am 03.02.14 15:43, schrieb Larry Hastings:
> >> A: We create a PyMethodDefEx structure with an extra field: "const char
> >> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?)
Am 05.02.2014 14:52, schrieb "Martin v. Löwis":
> Am 03.02.14 15:43, schrieb Larry Hastings:
>> A: We create a PyMethodDefEx structure with an extra field: "const char
>> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
>> the flags, indicating that this is an extended struc
Am 03.02.14 15:43, schrieb Larry Hastings:
> A: We create a PyMethodDefEx structure with an extra field: "const char
> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
> the flags, indicating that this is an extended structure. When
> iterating over the PyMethodDefs, we kno
Am 04.02.2014 13:14, schrieb Antoine Pitrou:
> On Tue, 04 Feb 2014 02:21:51 -0800
> Larry Hastings wrote:
>> On 02/04/2014 01:41 AM, Georg Brandl wrote:
>> > Clever, but due to the "hidden" space it also increases the frustration
>> > factor
>> > for people trying to find out "why is this accepte
On 4 February 2014 02:04, Larry Hastings 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: h
Georg Brandl writes:
> I don't think a well-chosen visible separator is worse off, such as "--\n".
Don't you mean "-- \n"?
L'Ancien Mail-guique-ly y'rs,
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python
On Tue, 04 Feb 2014 02:21:51 -0800
Larry Hastings wrote:
> On 02/04/2014 01:41 AM, Georg Brandl wrote:
> > Clever, but due to the "hidden" space it also increases the frustration
> > factor
> > for people trying to find out "why is this accepted as a signature and not
> > this".
> >
> > I don't
On 02/03/2014 08:05 AM, Stefan Krah wrote:
I think we may slowly get into PEP territory here. Just imagine that
we settle on X, then decide at a later point to have a standard way of
adding type annotations, then find that X does not work because of (unknown).
I'm mentioning this because signat
On 02/04/2014 01:41 AM, Georg Brandl wrote:
Clever, but due to the "hidden" space it also increases the frustration factor
for people trying to find out "why is this accepted as a signature and not
this".
I don't think a well-chosen visible separator is worse off, such as "--\n".
I could live
On 02/03/2014 02:26 PM, Antoine Pitrou wrote:
How do you create an array that mixes PyMethodDefs and PyMethodDefExs
together?
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.
It sounds like METH_SIGNATURE is th
On 02/03/2014 02:06 PM, Gregory P. Smith wrote:
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?
It might use #
On 02/03/2014 01:10 PM, Zachary Ware wrote:
What about just choosing a marker value that is somewhat less
unsightly? "signature = (", or "parameters: (", or something (better)
to that effect? It may not be beautiful in 3.3, but we can at least
make it make sense.
It's a reasonable enough idea
On 02/03/2014 12:55 PM, Terry Reedy wrote:
I think the solution adopted should be future-oriented (ie, clean in
the future) even if the cost is slight awkwardness in 3.3.
Just a minor point: I keep saying 3.3, but I kind of mean "3.2 through
3.3". I believe the binary ABI shipped with 3.2.
Am 04.02.2014 10:12, schrieb Larry Hastings:
> If you won't let me have a flag, can I at least have a more-clever marker?
> How
> about this:
>
> (...)\n \n
>
> Yes, the last four characters are right-parenthesis, newline, space, and
> newline. Benefits:
>
> * The odds of finding *that
On 02/03/2014 08:19 PM, Guido van Rossum wrote:
But why do you even need a flag? Reading issue 20075 where the
complaint started, it really feels that the change was an overreaction
to a very minimal problem.
I'll cop to that. I'm pretty anxious about trying to "get it right".
My worry wa
Larry Hastings writes:
> In the second attempt, the signature looked like this:
>
>sig=(arguments)\n
>
[...]
> This all has caused no problems so far. But my panicky email last
> night was me realizing a problem we may see down the road. To recap:
> if a programmer writes a module using the
Hmm... I liked the original scheme because it doesn't come out so badly if
some tool doesn't special-case the first line of the docstring at all. (I
have to fess up that I wrote such a tool for a limited case not too long
ago, and I wrote it to search for a blank line if the docstring starts with
On 02/03/2014 09:46 AM, Guido van Rossum wrote:
Can you summarize why neither of the two schemes you tried so far worked?
Certainly.
In the first attempt, the signature looked like this:
(arguments)\n
The "(arguments)" part of the string was 100% compatible with Python
syntax. So much
On Mon, 03 Feb 2014 06:43:31 -0800
Larry Hastings wrote:
>
> A: We create a PyMethodDefEx structure with an extra field: "const char
> *signature". We add a new METH_SIGNATURE (maybe just METH_SIG?) flag to
> the flags, indicating that this is an extended structure. When
> iterating over the
On Mon, Feb 3, 2014 at 8:04 AM, Larry Hastings 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
On Mon, Feb 3, 2014 at 8:43 AM, Larry Hastings wrote:
>
>
> A quick summary of the context: currently in CPython 3.4, a builtin function
> can publish its "signature" as a specially encoded line at the top of its
> docstring. CPython internally detects this line inside
> PyCFunctionObject.__doc__
On 2/3/2014 9:43 AM, Larry Hastings wrote:
A quick summary of the context: currently in CPython 3.4, a builtin
function can publish its "signature" as a specially encoded line at the
top of its docstring. CPython internally detects this line inside
PyCFunctionObject.__doc__ and skips past it,
Larry,
Can you summarize why neither of the two schemes you tried so far worked?
AFAIR the original scheme was to support the 3.3-compatible syntax; there
was some kind of corner-case problem with this, so you switched to the new
"sig=..." syntax, but obviously this has poor compatibility with 3.3
Larry Hastings wrote:
> So here's the problem. Let's say you want to write an extension that will
> work
> with Python 3.3 and 3.4, using the stable ABI. If you don't add this line,
> then in 3.4 you won't have introspection information, drat. But if you *do*
> add this line, your docstring wi
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 PyMethod
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.
28 matches
Mail list logo
