> When you take a text string and create a string literal to represent
> it, sometimes you have to modify it to become syntactically valid.
Even simpler: use r""" instead of """
The only case where that won't work is when you need actual escape
sequences. But I find this very rare in practice
On 2019-07-17 02:34, Brett Cannon wrote:
I prefer removal for ease of maintenance (people always want to update code
even if it's deprecated), and to help make sure people who don't read the docs
but discover something via the REPL or something and don't run with warnings on
do not
On 2019-07-16 15:33, Inada Naoki wrote:
We currently have a deprecation policy saying that functions deprecated
in version N cannot be removed before version N+2. That's a reasonable
policy but some deprecation purists insist that it MUST (instead of MAY)
be removed in version N+2. Following
I have seen multiple discussions where somebody wants to deprecate a
useless function but somebody else complains that we cannot do that
because the function in question cannot be removed (because of backwards
compatibility). See https://bugs.python.org/issue29548 for an example.
We currently
I realized something that makes this even more tricky: dicts are
mutable. So even if the dict contains only string keys at call time, it
could theoretically be changed by the time that keywords are parsed. So
for calling conventions passing dicts, I would leave it to the callee to
sanity check
Thanks for the pointer, but that's more about allowing strings which are
not valid identifiers. I'm talking about passing non-strings and more
specifically about the C protocol. For Python functions, non-string
keyword arguments are already disallowed, but that's because of the
implementation
On 2019-07-09 14:36, Jeroen Demeyer wrote:
So this leads to the question: should the interpreter check the keys of
a **kwargs dict?
Some pointers:
- https://bugs.python.org/issue8419
- https://bugs.python.org/issue29360
___
Python-Dev mailing list
When passing **kwargs to a callable, the expectation is that kwargs is a
dict with string keys. The interpreter enforces that it's a dict, but it
does NOT check the types of the keys. It's currently the job of the
called function to check that. In some cases, this check is not applied:
>>>
On 2019-07-02 23:29, Brett Cannon wrote:
But two, this would be a semantic shift of what classes directly inherit from
`BaseException`.
It depends how you interpret that. I always interpreted classes
inheriting directly from BaseException as exceptions that you almost
never want to catch in
A SystemError is typically raised from C to indicate serious bugs in the
application which shouldn't normally be caught and handled. It's used
for example for NULL arguments where a Python object is expected. So in
some sense, SystemError is the Python equivalent of a segmentation fault.
On 2019-06-13 18:03, Inada Naoki wrote:
We don't provide method calling API which uses optimization same to
LOAD_METHOD. Which may be like this:
/* methname is Unicode, nargs > 0, and args[0] is self. */
PyObject_VectorCallMethod(PyObject *methname, PyObject **args,
Py_ssize_t nargs, PyObject
On 2019-06-13 17:11, Steve Dower wrote:
The cost of that convenience is that
we can never optimise internals because they are now public API.
I think that the opposite is true actually: the reason that people
access internals is because there is no public API doing what they want.
Having
On 2019-06-13 15:36, Victor Stinner wrote:
The main risk is that people start to use it
If people use it, it should be taken as a sign that the function is
useful and deserves to be public API.
___
Python-Dev mailing list -- python-dev@python.org
On 2019-06-13 14:21, Victor Stinner wrote:
We may deprecate it and document that VECTORCALL should be
preferred.
Not really. Vectorcall and METH_FASTCALL solve different problems on
different levels.
METH_FASTCALL is used specifically in PythonMethodDef, in other words
for instances of
Hello,
has the time come to document METH_FASTCALL? This was introduced in
Python 3.6 for positional arguments only and extended in Python 3.7 to
support also keyword arguments. No changes have been made since then.
The vectorcall protocol (PEP 590) uses a calling convention based on
On 2019-06-07 20:42, Terry Reedy wrote:
On 6/7/2019 6:41 AM, Jeroen Demeyer wrote:
Hello,
I'm starting this thread to brainstorm for using vectorcall to speed
up creating instances of Python classes.
Currently the following happens when creating an instance of a Python
class X using X
Hello,
I'm starting this thread to brainstorm for using vectorcall to speed up
creating instances of Python classes.
Currently the following happens when creating an instance of a Python
class X using X(.) and assuming that __new__ and __init__ are Python
functions and that the
On 2019-05-29 16:00, Christian Heimes wrote:
You could add a check to PyType_Ready() and have it either return an
error or fix tp_call.
Yes, but the question is: which of these two alternatives? I would vote
for fixing tp_call but Petr voted for an error.
On 2019-05-29 15:29, Petr Viktorin wrote:
That sounds like a good idea for PyType_FromSpec.
I don't think we're planning to support vectorcall in PyType_FromSpec
for now. That's maybe for 3.9 when vectorcall is no longer provisional.
For static types I either wouldn't bother at all, or
Hello,
I have one implementation question about vectorcall which is not
specified in PEP 590: what should happen if a type implements vectorcall
(i.e. _Py_TPFLAGS_HAVE_VECTORCALL is set) but doesn't set tp_call (i.e.
tp_call == NULL)? I see the following possibilities:
1. Ignore this
Could somebody please merge https://github.com/python/cpython/pull/13461
It adds a missing testcase for bpo-34125. This is testing code which is
affected by PEP 590, so missing this test might accidentally break
CPython if we screw up with implementing PEP 590.
Thanks,
Jeroen.
On 2019-05-10 00:07, Petr Viktorin wrote:
METH_FASTCALL is currently not documented, and it should be renamed
before it's documented. Names with "fast" or "new" generally don't age
well.
Just to make sure that we're understanding correctly, is your proposal
to do the following:
- remove the
On 2019-05-09 20:30, Petr Viktorin wrote:
But, if you apply the robustness principle to vectorcallfunc, it
should accept empty tuples.
Sure, if the callee wants to accept empty tuples anyway, it can do that.
That's the robustness principle. But us *forcing* the callee to accept
empty tuples
On 2019-05-09 20:30, Petr Viktorin wrote:
The underlying C function should not need to know how to extract
"self" from the function object, or how to handle the argument
offsetting.
Those should be implementation details.
Maybe you misunderstood my proposal. I want to allow both for extra
On 2019-05-09 23:09, Brett Cannon wrote:
Any reason the above are all "Vectorcall" and not "VectorCall"? You seem
to potentially have that capitalization for "PyCall_MakeVectorCall" as
mentioned below which seems to be asking for typos if there's going to
be two ways to do it. :)
On 2019-05-09 20:30, Petr Viktorin wrote:
### Making things private
For Python 3.8, the public API should be private, so the API can get
some contact with the real world. I'd especially like to be able to
learn from
Cython's experience using it.
That would mean:
* _PyObject_Vectorcall
*
Hello,
I have a simple question for which there doesn't seem to be a good
answer: is the layout of PyTypeObject considered to be part of the
stable ABI?
Officially, the answer is certainly "no" (see PEP 384).
However, unofficially the answer might be "yes". At least, the last time
that an
Hello Petr,
Thanks for your time. I suggest you (or somebody else) to officially
reject PEP 580.
I start working on reformulating PEP 590, adding some elements from PEP
580. At the same time, I work on the implementation of PEP 590. I want
to implement Mark's idea of having a separate
On 2019-05-06 00:04, Petr Viktorin wrote:
- Single bound method class for all kinds of function classes: This
would be a cleaner design, yes, but I don't see a pressing need. As
PEP 579 says, "this is a compounding issue", not a goal. As I recall,
that is the only major reason for CCALL_DEFARG.
On 2019-05-03 14:24, Victor Stinner wrote:
Hi Srinivas,
I merged your obvious doc fix, thanks.
Can you please do the same for
https://github.com/python/cpython/pull/12784
___
Python-Dev mailing list
Python-Dev@python.org
Hello all,
If we want to have a chance of implementing PEP 580/590 in Python 3.8,
we shouldn't wait too long to make a decision on which proposal to accept.
As a summary, below I'll write the four proposals together with a star
"score" for 3 criteria (there is no obvious best proposal, all
On 2019-04-27 11:26, Mark Shannon wrote:
Performance improvements include, but aren't limited to:
1. Much faster calls to common classes: range(), set(), type(), list(),
etc.
That's not specific to PEP 590. It can be done with any proposal. I know
that there is the ABI issue with PEP 580,
On 2019-04-27 11:26, Mark Shannon wrote:
Specifically, and this is important, PEP 580 cannot implement efficient
calls to class objects without breaking the ABI.
First of all, the layout of PyTypeObject isn't actually part of the
stable ABI (see PEP 384). So, we wouldn't be breaking anything
On 2019-04-27 14:07, Mark Shannon wrote:
class D(C):
__call__(self, ...):
...
and then create an instance `d = D()` then calling d will have two
contradictory behaviours; the one installed by C in the function pointer
and the one specified by D.__call__
It's true that the
On 2019-04-25 23:11, Petr Viktorin wrote:
My thoughts are not the roadmap, of course :)
I asked about methods because we should aware of the consequences when
choosing between PEP 580 and PEP 590 (or some compromise). There are
basically 3 different ways of dealing with bound methods:
(A)
Hello,
after reading the various comments and thinking about it more, let me
propose a real compromise between PEP 580 and PEP 590.
My proposal is: take the general framework of PEP 580 but support only a
single calling convention like PEP 590. The single calling convention
supported would
On 2019-04-25 00:24, Petr Viktorin wrote:
I believe we can achieve
that by having PEP 590's (o+offset) point not just to function pointer,
but to a {function pointer; flags} struct with flags defined for two
optimizations:
What's the rationale for putting the flags in the instance? Do you
On 2019-04-25 00:24, Petr Viktorin wrote:
PEP 590 defines a new simple/fast protocol for its users, and instead of
making existing complexity faster and easier to use, it's left to be
deprecated/phased out (or kept in existing classes for backwards
compatibility). It makes it possible for future
On 2019-04-24 01:44, Victor Stinner wrote:
I would like to
be able to run C extensions compiled in release mode on a Python
compiled in debug mode
That seems like a very good idea. I would certainly use the debug mode
while developing CPython or C extensions.
On 2019-04-03 07:33, Jeroen Demeyer wrote:
Access to the class isn't possible currently and also not with PEP 590.
But it's easy enough to fix that: PEP 573 adds a new METH_METHOD flag to
change the signature of the C function (not the vectorcall wrapper). PEP
580 supports this "out of th
On 2019-04-14 13:30, Mark Shannon wrote:
PY_VECTORCALL_ARGUMENTS_OFFSET exists so that callables that make onward
calls with an additional argument can do so efficiently. The obvious
example is bound-methods, but classes are at least as important.
cls(*args) -> cls.new(cls, *args) ->
On 2019-04-14 13:34, Mark Shannon wrote:
I'll address capability first.
I don't think that comparing "capability" makes a lot of sense since
neither PEP 580 nor PEP 590 adds any new capabilities to CPython. They
are meant to allow doing things faster, not to allow more things.
And yes, the
The signal handler (that receives signals from the OS) in Python starts
with a check
if (getpid() == main_pid)
Looking at the comments, the intent was to do a check for the main
*thread* but this is checking the *process* id. So this condition is
basically always true. Therefore, I
Petr,
I realize that you are in a difficult position. You'll end up
disappointing either me or Mark...
I don't know if the steering council or somebody else has a good idea to
deal with this situation.
Jeroen has time
Speaking of time, maybe I should clarify that I have time until the
On 2019-04-10 18:25, Petr Viktorin wrote:
Hello!
I've had time for a more thorough reading of PEP 590 and the reference
implementation. Thank you for the work!
And thank you for the review!
I'd now describe the fundamental
difference between PEP 580 and PEP 590 as:
- PEP 580 tries to
On 2019-04-08 17:08, Robert White wrote:
So we're making pretty heavy use of PyInstanceMethod_New in our python
binding library that we've written for a bunch of in house tools.
If this isn't the best / correct way to go about adding methods to
objects, what should we be using instead?
First
On 2019-04-07 09:48, Serhiy Storchaka wrote:
total_ordering monkeypatches the decorated class. I'm planning to
implement in C methods that implement __gt__ in terms of __lt__ etc.
Yes, I understood that. I'm just saying: if you want to make it fast,
that's not the best solution. The fastest
On 2019-04-05 21:58, Brett Cannon wrote:
Then we can consider improving the documentation if there are
performance implications.
Sure, we could write in the docs something like "Don't use this, this is
not what you want. It's slow and there are better alternatives like
method descriptors".
On 2019-04-05 17:46, Guido van Rossum wrote:
This API is doing no harm, it's not a maintenance
burden
What if the following happens?
1. For some reason (possibly because of this thread), people discover
instancemethod and start using it.
2. People realize that it's slow.
3. It needs to be
On 2019-04-05 19:53, Serhiy Storchaka wrote:
At Python level we can monkeypatch __gt__, but not tp_richcompare.
Sure, but you're planning to use C anyway so that's not really an argument.
___
Python-Dev mailing list
Python-Dev@python.org
On 2019-04-05 15:13, Serhiy Storchaka wrote:
It is easy to implement a function in C.
Why does it need to be a PyCFunction? You could put an actual method
descriptor in the class. In other words, use PyDescr_NewMethod() instead
of PyCFunction_New() + PyInstanceMethod_New(). It's probably
On 2019-04-05 14:10, Serhiy Storchaka wrote:
it can be used to
implement accelerated versions of separate methods instead of the whole
class.
Could you elaborate? I'm curious what you mean.
I'm going to use it to further optimize total_ordering.
There are so many ways in which
On 2019-04-05 00:57, Greg Ewing wrote:
If it's designed for use by things outside of CPython, how
can you be sure nothing is using it?
Of course I'm not sure. However:
1. So far, nobody in this thread knows of any code using it.
2. So far, nobody in this thread knows any use case for it.
On 2019-04-04 14:09, Christian Heimes wrote:
I couldn't find any current code that uses PyInstanceMethod_New. Let's
deprecate the feature and schedule it for removal in 3.10.
Done at https://github.com/python/cpython/pull/12685
___
Python-Dev mailing
During my investigations related to low-level function/method classes, I
came across the "instance method" class. There is a C API for it:
https://docs.python.org/3.7/c-api/method.html
However, it's not used/exposed anywhere in CPython, except as
_testcapi.instancemethod (for testing its
As I'm reading the PEP 590 reference implementation, it strikes me how
similar it is to https://bugs.python.org/issue29259
The main difference is that bpo-29259 has a per-class pointer
tp_fastcall instead of a per-object pointer. But actually, the PEP 590
reference implementation does not
On 2019-04-02 21:38, Mark Shannon wrote:
Hi,
On 01/04/2019 6:31 am, Jeroen Demeyer wrote:
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
Thanks. As expected for calls to C function for both PEPs and master
perform about the same
In one of the ways to call C functions in PEP 580, the function gets
access to:
- the arguments,
- "self", the object
- the class that the method was found in (which is not necessarily
type(self))
I still have to read the details, but when combined with
LOAD_METHOD/CALL_METHOD optimization
I added benchmarks for PEP 590:
https://gist.github.com/jdemeyer/f0d63be8f30dc34cc989cd11d43df248
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 2019-03-30 17:30, Mark Shannon wrote:
2. The claim that PEP 580 allows "certain optimizations because other
code can make assumptions" is flawed. In general, the caller cannot make
assumptions about the callee or vice-versa. Python is a dynamic language.
PEP 580 is meant for extension
On 2019-03-29 04:08, Stephen J. Turnbull wrote:
In this case, it's here:
> https://discuss.python.org/t/pep-570-Python-Positional-Only-Parameters/1078
So, are we supposed to discuss PEPs on discuss.python.org now? That's
fine for me, should I create a thread like that for PEP 580 too?
On 2019-03-28 01:38, Tim Peters wrote:
The bad news is that the traschcan mechanism is excruciating, a
long-time source of subtle bugs of its own :-(
It just happens that I created a PR to fix some of the trashcan
problems: see https://bugs.python.org/issue35983 and
On 2019-03-27 14:50, Petr Viktorin wrote:
The pre-PEP claims speedups of 2% in initial experiments, with
expected overall performance gain of 4% for the standard benchmark
suite. That's pretty big.
I re-did my earlier benchmarks for PEP 580 and these are the results:
By lack of a better name, I'm using the name PEP 576bis to refer to
https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst
(This is why this should get a PEP number soon, even if the PEP is not
completely done yet).
On 2019-03-27 14:50, Petr Viktorin wrote:
The pre-PEP
Now that the discussion on PEP 576/580 has been opened again, let me
write something about the complexity of function calls (*), which is
probably the most frequently given reason against PEP 580.
An important fact is the following: *the status-quo is complex*.
Over time, many performance
On 2019-03-24 16:22, Mark Shannon wrote:
The draft can be found here:
https://github.com/markshannon/peps/blob/new-calling-convention/pep-.rst
I think that this is basically a better version of PEP 576. The idea is
the same as PEP 576, but the details are better. Since it's not
On 2019-03-24 16:22, Mark Shannon wrote:
Hi Petr,
Regarding PEPs 576 and 580.
Over the new year, I did a thorough analysis of possible approaches to
possible calling conventions for use in the CPython ecosystems and came
up with a new PEP.
The draft can be found here:
On 2019-03-22 11:33, Serhiy Storchaka wrote:
What is wrong with PendingDeprecationWarning?
It serves the same purpose as DeprecationWarning: it indicates that a
feature is planned to be removed in the future. There is no point in
having two warnings with exactly the same meaning.
What
On 2019-03-20 12:45, Victor Stinner wrote:
You can watch the /tmp directory using inotify and "discover"
immediately the "secret" filename, it doesn't depend on the amount of
entropy used to generate the filename.
That's not the problem. The security issue here is guessing the filename
On 2019-03-08 09:29, Victor Stinner wrote:
I would like to suggest to add URLs to the first messages of all
threads about a PEP...
Like this?
https://www.python.org/dev/peps/pep-0580/#discussion
___
Python-Dev mailing list
Python-Dev@python.org
On 2019-03-05 18:14, Steve Dower wrote:
However, if you don't have
*a single* core developer on board from python-ideas, chances are the
whole team is going to reject the proposal.
Sure, I couldn't agree more. But this is something that a PEP mentor
(instead of sponsor) also could deal with.
On 2019-03-05 14:05, Calvin Spealman wrote:
I'm worried this creates a gatekeeping perception that will scare away
contributors.
+1
I also expressed this worry at https://github.com/python/peps/pull/903
You could keep the positive part of the sponsoring idea (somebody acting
as mentor) but
Does this apply to existing draft PEPs or only new ones?
___
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
Let me just say that the code for METH_FASTCALL function/method calls is
optimized for a stack layout: a piece of the stack is used directly for
calling METH_FASTCALL functions (without any copying any PyObject*
pointers). So this would probably be slower with a register-based VM
(which
On 2019-02-21 12:18, Victor Stinner wrote:
What I also would like to see is the creation of a group of people who
work on the C API to discuss each change and test these changes
properly.
I don't think that we should "discuss each change", we should first have
an overall plan. It doesn't make
On 2019-02-19 04:04, Steve Dower wrote:
On 18Feb.2019 1324, Jeroen Demeyer wrote:
For a very concrete example, was it really necessary to put
_PyTuple_ITEMS in (4)? That's used in _functoolsmodule.c. Especially
given that the very similar PySequence_Fast_ITEMS is in (2), that seems
like
On 2019-02-19 04:04, Steve Dower wrote:
Otherwise, the
internal memory layout becomes part of the public ABI
Of course, the ABI (not API) depends on the internal memory layout. Why
is this considered a problem? If you want a fixed ABI, use API level (1)
from my last post. If you want a fixed
On 2019-02-18 21:17, Eric Snow wrote:
Historically our approach to keeping API private was to use underscore
prefixes and to leave them out of the documentation (along with
guarding with "#ifndef Py_LIMITED_API"). However, this has lead to
occasional confusion and breakage, and even to leaking
On 2019-02-16 00:37, Eric Snow wrote:
One thing that would help simplify changes
in this area is if PyInterpreterState were defined in
Include/internal.
How would that help anything? I don't like the idea (in general, I'm not
talking about PyInterpreterState specifically) that external
Hello,
I would like to propose to the new steering council to review PEP 580.
Is there already a process for that?
Thanks,
Jeroen.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
Can somebody please review https://github.com/python/cpython/pull/880
That addresses a severe problem on Windows making it impossible to build
any C++ extension module with some compilers.
___
Python-Dev mailing list
Python-Dev@python.org
On 2018-11-14 04:06, Raymond Hettinger wrote:
With cross module function calls, I'm less confident about what is happening
If the functions are "static inline" (as opposed to plain "inline"),
those aren't really cross-module function calls. Because the functions
are "static" and defined in a
On 2018-10-26 19:17, Brett Cannon wrote:
But since you're asking about wanting to "review PEPs", you can review
them now.
Unfortunately not everybody agrees on that...
See
https://mail.python.org/pipermail/python-dev/2018-October/155441.html in
particular
I really hope that I won't have
What is the timeframe for the installation of the new governance? In
other words, when will it be possible to review PEPs?
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
On 2018-10-03 23:27, Guido van Rossum wrote:
IMO changes to the C API should be taken just as seriously -- the
potential for breaking the world is just about the same (since most
serious Python applications use C extensions that risk breaking).
Of course we are taking this seriously. I want
On 2018-10-03 18:55, Barry Warsaw wrote:
Correct. It’s entirely possible that the different governance models will have
different ways to pick delegates.
And how does that affect *today*'s decision? The new governance model
will only take effect 1 January (assuming that everything goes as
On 2018-10-03 17:06, Łukasz Langa wrote:
That's the only
reason why PEP 544 is not yet accepted for example.
Did you actually try to get PEP 544 accepted or to appoint a
BDFL-Delegate? I don't find any discussions about PEP 544 after the
stepping down of the BDFL.
On 2018-10-03 17:12, Wes Turner wrote:
> AFAIU, there is not yet a documented process for BDFL-delegate assignment.
PEP 1 says:
"""
However, whenever a new PEP is put forward, any core developer that
believes they are suitably experienced to make the final decision on
that PEP may offer to serve
github.com/python/peps/pull/797
Cheers,
Jeroen Demeyer.
___
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
On 2018-09-25 16:01, Barry Warsaw wrote:
Maybe this is better off discussed in doc-sig but I think we need to consider
documenting the private C API.
Even the *public* C API is not fully documented. For example, none of
the PyCFunction_... functions appears in the documentation.
that conflict
after GH-8416 has been decided.
Links:
https://bugs.python.org/issue34125
https://github.com/python/cpython/pull/8416
Thanks,
Jeroen Demeyer.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/l
On 2018-09-13 02:26, Petr Viktorin wrote:
The reference to PEP 573 is premature.
It seems to me that PEP 580 helps with the use case of PEP 573. In fact,
it implements part of what PEP 573 proposes. So I don't see the problem
with the reference to PEP 573. Even if the implementation of PEP
On 2018-08-23 07:36, Antoine Pitrou wrote:
- the bootstrap problem (Cython self-compiles with CPython)
This is not a big problem: we can make sure that all stdlib dependencies
of Cython either have PEP 399 pure Python implementations or we keep
them in pure C.
- the dependency /
> Would this be better than a flag + raising an error on init?
Exactly. PEP 489 only says "Extensions using the new initialization
scheme are expected to support subinterpreters". What's wrong with
raising an exception when the module is initialized the second time?
Jeroen.
On 2018-07-30 17:28, Nick Coghlan wrote:
I would, and I think it would make sense for the PEP to cite improving
consistency (and reducing code duplication?) in that regard as an
advantage of the PEP.
I'm not sure to which PEP you are referring (PEP 580 or a new PEP?).
After thinking a bit
Actually, scratch that, I posted too soon.
There is also a block
/*[clinic input]
class list "PyListObject *" "_Type"
[clinic start generated code]*/
So it could work.
___
Python-Dev mailing list
Python-Dev@python.org
Actually, I just realized that it's not really possible to fix the error
messages for built-in methods. The problem is that Argument Clinic does
not know whether a function or method is being handled. For example,
there is no indication at all that this is a method (note that the name
On 2018-07-31 11:12, INADA Naoki wrote:
Any PEP won't be accepted in few month, because we don't have flow to
accept PEPs for now.
Is that certain? I haven't been following the process discussions, so
I'm just asking the question. For example, given that you are already
looking at PEP 580,
On 2018-07-31 15:34, Victor Stinner wrote:
But I never used Cython nor cffi, so I'm not sure which one is the
most appropriate depending on the use case.
Cython is a build-time tool, while cffi is a run-time tool.
But Cython does a lot more than just FFI. It is a Python->C compiler
which can
On 2018-07-31 12:10, INADA Naoki wrote:
After spent several days to read PEP 580 and your implementation, I think
I can implement it. I think it's not easy, but it's not impossible too.
The signature of "extended_call_ptr" in PEP 576 is almost the same as
the signature of a
1 - 100 of 205 matches
Mail list logo
