h.vetin...@gmx.com schrieb am 18.07.22 um 18:04:
One of the comments in the retro was:
Searching the archives is much easier and have found me many old threads that I
probably would have problem finding before since I haven’t been subscribed for
that long.
I'm actually reading python-dev,
Petr Viktorin schrieb am 15.07.22 um 13:18:
The discuss.python.org experiment has been going on for quite a while, and
while the platform is not without its issues, we consider it a success. The
Core Development category is busier than python-dev. According to staff,
discuss.python.org is much
Petr Viktorin schrieb am 10.02.22 um 11:22:
So, should there be a mechanism to set source/lineno/position on
tracebacks/exceptions, rather than always requiring a frame for it?
There's "_PyTraceback_Add()" currently, but it's incomplete in terms of
what Cython would need.
As it stands,
Andrew Svetlov schrieb am 09.02.22 um 19:40:
Stefan, do you really need to emulate call stack with positions?
Could the __note__ string with generated Cython part of exception traceback
solve your needs (https://www.python.org/dev/peps/pep-0678/) ?
Thanks for the link, but I think it would be
Guido van Rossum schrieb am 09.02.22 um 19:36:
On Wed, Feb 9, 2022 at 9:41 AM Pablo Galindo Salgado wrote:
On Wed, 9 Feb 2022 at 17:38, Stefan Behnel wrote:
Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
Should there be a getter/setter for co_positions?
We consider the representation
Pablo Galindo Salgado schrieb am 09.02.22 um 17:40:
Should there be a getter/setter for co_positions?
We consider the representation of co_postions private
Yes, and that's the issue.
so we don't want (for now) to ad
getters/setters. If you want to get the position of a instruction, you
Inada Naoki schrieb am 08.02.22 um 06:15:
On Tue, Feb 8, 2022 at 1:47 PM Guido van Rossum wrote:
Thanks for trying it! I'm curious why it would be slower (perhaps less
locality? perhaps the ...Id... APIs have some other trick up their sleeve?) but
since it's also messier and less backwards
Eric Snow schrieb am 04.02.22 um 17:35:
On Fri, Feb 4, 2022 at 8:21 AM Stefan Behnel wrote:
Correct. We (intentionally) have our own way to intern strings and do not
depend on CPython's identifier framework.
You're talking about __Pyx_StringTabEntry (and __Pyx_InitString())?
Yes, that's
Ronald Oussoren via Python-Dev schrieb am 03.02.22 um 14:46:
On 2 Feb 2022, at 23:41, Eric Snow wrote:
* a little less convenient: adding a global string requires modifying
a separate file from the one where you actually want to use the string
* strings can get "orphaned" (I'm planning on
Petr Viktorin schrieb am 03.02.22 um 13:47:
On 02. 02. 22 11:50, Stefan Behnel wrote:
Maybe we should advertise the two modes more. And make sure that both
work. There are certainly issues with the current state of the "limited
API" implementation, but that just needs work and te
Victor Stinner schrieb am 03.02.22 um 22:46:
Oh right, Cython seems to be a false positive.
A code search found 3 references to __Pyx_PyObject_LookupSpecial():
PYPI-2022-01-26-TOP-5000/Cython-0.29.26.tar.gz:
Cython-0.29.26/Cython/Compiler/ExprNodes.py: lookup_func_name =
Victor Stinner schrieb am 02.02.22 um 23:23:
On Wed, Feb 2, 2022 at 3:54 PM Stefan Behnel wrote:
So people using stable Python versions like Python 3.10 would not need
Cython, but people testing the "next Python" (Python 3.11) would not
have to manually removed generated C code.
T
Ronald Oussoren via Python-Dev schrieb am 02.02.22 um 16:44:
On 2 Feb 2022, at 11:50, Stefan Behnel wrote:
Petr Viktorin schrieb am 02.02.22 um 10:22:
- "normal" public API, covered by the backwards compatibility policy (users
need to recompile for every minor release,
Petr Viktorin schrieb am 02.02.22 um 10:22:
Moving off the internal (unstable) API would be great, but I don't think
Cython needs to move all the way to the limited API.
There are three "levels" in the C API:
- limited API, with long-term ABI compatibility guarantees
That's what
Victor Stinner schrieb am 02.02.22 um 11:35:
I wish that there would be a 3rd option: ship C code generated by
Cython *but* run Cython if this C code "looks" outdated, for example
if building the C code fails with a compiler error.
So, one thing I did yesterday was to make sure that .c files
.
On Tue, Feb 1, 2022 at 4:14 PM Stefan Behnel wrote:
I'd rather make it more obvious to users what their intentions are. And
there is already a way to do that – the Limited API. (and similarly, HPy)
Your grammar confuses me. Do you want users to be clearer in expressing
their intentions
Thomas Caswell schrieb am 01.02.22 um 23:15:
I think it would be better to discourage projects from including the output
of cython in their sdists. They should either have cython as a build-time
requirement or provide built wheels (which are specific a platform and
CPython version). The middle
Guido van Rossum schrieb am 02.02.22 um 00:21:
On Tue, Feb 1, 2022 at 3:07 David wrote:
Greg Ewing wrote:
To address this there could be an option to choose between
"compatible code" and "fast code", with the former restricting
itself to the stable API.
To some extent, that exists at the
Hi Irit,
Irit Katriel via Python-Dev schrieb am 01.02.22 um 23:04:
There two separate issues here. One is the timing of committing changes into
cython, and the other is the process by which the cython devs learn about
cpython development.
On the first issue, you wrote:
I'm reluctant to
Greg Ewing schrieb am 01.02.22 um 23:33:
On 2/02/22 8:48 am, Guido van Rossum wrote:
It seems to me that a big part of the problem is that Cython feels
entitled to use arbitrary CPython internals.
I think the reason for this is that Cython is trying to be two
things at once: (1) an interface
Christian Heimes schrieb am 01.02.22 um 16:42:
On 01/02/2022 16.08, Victor Stinner wrote:
I would prefer to introduce C API incompatible changes differently:
first fix Cython, and *then* introduce the change.
- (1) Propose a Cython PR and get it merged
- (2) Wait until a new Cython version is
Guido van Rossum schrieb am 07.09.21 um 00:44:
In addition, I just heard from the SC that they've approved the exception.
So we will remove these two APIs from 3.11 without deprecation.
Erm, hang on – when I wrote that I'm fine with *changing* them, I wasn't
thinking of actually *removing*
Guido van Rossum schrieb am 13.08.21 um 19:24:
In 3.11 we're changing a lot of details about code objects. Part of this is
the "Faster CPython" work, part of it is other things (e.g. PEP 657 -- Fine
Grained Error Locations in Tracebacks).
As a result, the set of fields of the code object is
Victor Stinner schrieb am 05.10.20 um 12:25:
> Would you mind reporting the issue to
> https://github.com/python/core-workflow/issues so we can aggregate
> information about this issue?
Done.
Stefan
___
Python-Dev mailing list -- python-dev@python.org
Ned Deily schrieb am 05.10.20 um 01:19:
> On Oct 4, 2020, at 15:55, Terry Reedy wrote:
>>
>> On 10/4/2020 2:32 PM, Mariatta wrote:
>>> This is a known issue and I have brought it up in GitHub OS Maintainers
>>> Feedback Group. It happens to other projects as well.
>>> Currently we have branch
Hi devs,
I have a trivial documentation PR
https://github.com/python/cpython/pull/22464
for which travis (unsurprisingly) had a successful run,
https://travis-ci.com/github/python/cpython/builds/187435578
but github lists the travis build as "created" instead of "passed".
Victor Stinner schrieb am 02.07.20 um 00:07:
> Le mer. 1 juil. 2020 à 23:43, Eric V. Smith a écrit :
>>
>> On 7/1/2020 3:43 PM, Stefan Behnel wrote:
>>> Petr Viktorin schrieb am 30.06.20 um 14:51:
>>>> For example, could we only deprecate the bad p
Petr Viktorin schrieb am 30.06.20 um 14:51:
> For example, could we only deprecate the bad parts, but not remove them
> until the experiments actually show that they are preventing a beneficial
> change?
Big nod on this one.
Stefan
___
Python-Dev
Victor Stinner schrieb am 26.06.20 um 14:39:
> Well, the general problem is to track when the caller ends using a resource.
Although that is less of a problem if you only allow exposing the internal
data representation and nothing else. In that case, you can tie the
lifetime of the data access to
Gustavo Carneiro schrieb am 24.06.20 um 19:19:
> On Wed, 24 Jun 2020 at 17:22, Victor Stinner wrote:
>> The question becomes: how to promote the limited C API? Should it
>> become the default, rather than an opt-in option?
>
> It would be interesting to find out what is the performance impact of
Victor Stinner schrieb am 24.06.20 um 17:40:
> My practical problem is how to prevent C extensions accessing the
> PyFloatObject.ob_fval member directly.
Do extensions really do that in their code? I mean, there *is* a macro for
doing exactly this thing, which suggests that users should exactly
Victor Stinner schrieb am 24.06.20 um 02:14:
> Le mar. 23 juin 2020 à 16:56, Stefan Behnel a écrit :
>>> Members of ``PyObject`` and ``PyTupleObject`` structures have not
>>> changed since the "Initial revision" commit (1990)
>>
>> While I see an
Hi Victor,
thanks for your continued work on improving the C-API.
I'll comment on the PEP inline.
Victor Stinner schrieb am 22.06.20 um 14:10:
> PEP available at: https://www.python.org/dev/peps/pep-0620/
> [...]
> Motivation
> ==
>
> The C API blocks CPython evolutions
>
Victor Stinner schrieb am 23.06.20 um 11:18:
> Maybe an object can
> generate a temporary PyObject** view which requires to allocate
> resources (like memory) and the release function would release these
> resources.
I agree that this is more explicit when it comes to resource management,
but
Victor Stinner schrieb am 17.06.20 um 13:25:
> Le mer. 17 juin 2020 à 12:38, Petr Viktorin a écrit :
>>> There is an ongoing discussion about always requiring to run Cython
>>> when installing a C extension which uses Cython.
>>
>> Do you have a link to that discussion?
Yeah, I was wondering,
Paul Moore schrieb am 13.04.20 um 14:25:
> On a related but different note, what is the recommended policy
> (assuming it's not to use the C API) for embedding Python, and for
> exposing the embedding app to Python as a C extension? My standard
> example of this is the Vim interface to Python -
André Malo schrieb am 14.04.20 um 13:39:
> I think, it does not serve well as a policy for CPython. Since we're talking
> hypotheticals right now, if Cython vanishes tomorrow, we're kind of left
> empty
> handed. Such kind of a runtime, if considered part of the compatibility
> "promise",
Steve Dower schrieb am 14.04.20 um 00:27:
> On 13Apr2020 2308, André Malo wrote:
>> For one thing, if you open up APIs for Cython, they're open for everybody
>> (Cython being "just" another C extension).
>> More to the point: The ABIs have the same problem as they have now,
>> regardless
>> how
As (first-time) BDFL delegate, I accept PEP 573 for Python 3.9,
"Module State Access from C Extension Methods"
https://www.python.org/dev/peps/pep-0573/
Petr, Nick, Eric and Marcel, thank you for your work and intensive
discussions on this PEP, and also to everyone else who got involved on
Hi Petr!
Petr Viktorin schrieb am 14.01.20 um 14:37:
> It also includes a more drastic change: it removes the MRO walker from the
> proposal.
> Reflecting on the feedback, it became clear to me that a MRO walker, as it
> was described, won't give correct results in all cases: specifically, is a
>
Hi all,
I think that PEP 573 is ready to be accepted, to greatly improve the state
of extension modules in CPython 3.9.
https://www.python.org/dev/peps/pep-0573/
It has come a long way since the original proposal and went through several
iterations and discussions by various interested people,
Victor Stinner schrieb am 12.11.19 um 23:03:
> Are you ok to modify internal C functions to pass explicitly tstate?
FWIW, I started doing the same internally in Cython a while back, because
like others, I also considered it wasteful to look it up all over the
place, often multiple times inside of
Ned Batchelder schrieb am 10.09.19 um 16:54:
> this seems confusing to me
> What does the "official EOL date" mean if there's a release in April?
Also, what day in April? For example, planning the release for the 1st
could possibly add further to the confusion.
Stefan
Kristian Klette schrieb am 23.07.19 um 22:59:
> During the sprints after EuroPython, I made an attempt at adding support for
> comparing the results from `.values()` of two dicts.
>
> Currently the following works as expected:
>
> ```
> d = {'a': 1234}
>
> d.keys() == d.keys()
> d.items() ==
Victor Stinner schrieb am 12.06.19 um 00:09:
> So yeah, the PyCode_New() change is very annoying in practical, since
> every single project using Cython requires a new release in practice.
I think Cython's deal with regard to this is:
"""
If you use Cython, we will try hard to cover up the
Neil Schemenauer schrieb am 08.06.19 um 22:46:
> It would be great if we had a system that did CI testing with the
> top PyPI modules. E.g. pull the latest versions of the top 100 PyPI
> modules and test them with the latest CPython branch.
FWIW, travis-ci provides the latest CPython master
Serhiy Storchaka schrieb am 01.06.19 um 09:02:
> I have a related proposition. Yesterday I have reported two bugs (and Pablo
> quickly fixed them) related to handling positional-only arguments. These
> bugs were occurred due to subtle changing the meaning of co_argcount. When
> we make some
Petr Viktorin schrieb am 10.05.19 um 00:07:
> On 5/9/19 5:33 PM, Jeroen Demeyer wrote:
>> Maybe you misunderstood my proposal. I want to allow both for extra
>> flexibility:
>>
>> - METH_FASTCALL (possibly combined with METH_KEYWORDS) continues to work
>> as before. If you don't want to care about
Matthias Klose schrieb am 25.04.19 um 13:48:
> Are there use cases where you only want to load *some*
> debug extensions, even if more are installed?
Not sure if there are _important_ use cases (that could justify certain
design decisions), but I can certainly imagine using a non-debug (and
Berker Peksağ schrieb am 26.04.19 um 01:15:
> Note that this year's core dev sprint will be held in London. See
> https://discuss.python.org/t/2019-core-dev-sprint-location-date/489
> for the previous discussion. There are only two months between both
> events, so perhaps we can leave things like
Hi core devs,
there are several core dev events happening at the US PyCon this year, so I
was wondering if we could organise something similar at EuroPython. Does
anyone have any plans or ideas already? And, how many of us are planning to
attend EP19 in Basel this year? Unless there's something
Jeroen Demeyer schrieb am 24.04.19 um 09:24:
> 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
Serhiy Storchaka schrieb am 11.04.19 um 17:30:
> If reducing the Python memory footprint is an argument for disabling
> Py_TRACE_REFS, it is a weak argument because there is larger overhead in
> the debug build.
I think what Victor is argueing is rather that we have better ways to debug
memory
Antoine Pitrou schrieb am 22.03.19 um 11:39:
> On Fri, 22 Mar 2019 20:31:33 +1300 Greg Ewing wrote:
>> A poster on comp.lang.python is asking about array.array('u').
>> He wants an efficient mutable collection of unicode characters
>> that can be initialised from a string.
>
> TBH, I think anyone
Victor Stinner schrieb am 21.03.19 um 01:22:
> Alternatives have been proposed like a recipe to sort node attributes
> before serialization, but honestly, it's way too complex.
Hm, really? Five lines of simple and obvious Python code, that provide a
fast and completely Python-version agnostic
Ned Batchelder schrieb am 19.03.19 um 12:53:
> I need to re-engineer my tests.
… or sort the attributes before serialisation, or use C14N always, or
change your code to create the attributes in sorted-by-name order. The new
behaviour allows for a couple of ways to deal with the issue of backwards
Nathaniel Smith schrieb am 19.03.19 um 00:15:
> That seems potentially simpler to implement than canonical XML
> serialization
C14N is already implemented for ElementTree, just needs to be ported to
Py3.8 and merged.
https://bugs.python.org/issue13611
Stefan
Steve Dower schrieb am 19.02.19 um 21:40:
> On 19Feb2019 1212, Stefan Behnel wrote:
>> Then it's up to the users to decide
>> how much work they want to invest into keeping up with C-API changes vs.
>> potentially sub-optimal but stable C-API usage.
> [...]
> And it's no
Nick Coghlan schrieb am 19.02.19 um 15:00:
> On Tue, 19 Feb 2019 at 20:41, Antoine Pitrou wrote:
>> On Mon, 18 Feb 2019 19:04:31 -0800 Steve Dower wrote:
>>> If you always rebuild your extension for every micro version (3.x.y) of
>>> CPython, then sure, go ahead and use this.
>>
>> Usually we
MRAB schrieb am 29.01.19 um 19:55:
> On 2019-01-29 13:44, Nick Coghlan wrote:
>> FWIW, we have pretty decent evidence that error messages don't have to
>> provide a wonderful explanation on their own in order to be helpful:
>> they just need to be distinctive enough that a web search will
>>
Armin Rigo schrieb am 26.11.18 um 06:37:
> On Sun, 25 Nov 2018 at 10:15, Stefan Behnel wrote:
>> Overall, this seems like something that PyPy could try out as an
>> experiment, by just taking a simple extension module and replacing all
>> increfs with newref assignments. And o
Hi Armin,
Armin Rigo schrieb am 25.11.18 um 06:15:
> On Sat, 24 Nov 2018 at 22:17, Stefan Behnel wrote:
>> Couldn't this also be achieved via reference counting? Count only in C
>> space, and delete the "open object" when the refcount goes to 0?
>
> The point
Armin Rigo schrieb am 23.11.18 um 14:15:
> In PyPy we'd have a global table of
> "open objects", and a handle would be an index in that table; closing
> a handle means writing NULL into that table entry. No emulated
> reference counting needed: we simply use the existing GC to keep alive
>
Gregory P. Smith schrieb am 15.11.18 um 01:03:
> From my point of view: A static inline function is a much nicer modern code
> style than a C preprocessor macro.
It's also slower to compile, given that function inlining happens at a much
later point in the compiler pipeline than macro expansion.
Neil Schemenauer schrieb am 17.11.18 um 00:10:
> I think making PyObject an opaque pointer would help.
... well, as long as type checks are still as fast as with "ob_type", and
visible to the C compiler so that it can eliminate redundant ones, I
wouldn't mind. :)
> - Borrowed references are a
Serhiy Storchaka schrieb am 20.10.2018 um 13:06:
> Currently the PyUnicode object contains two caches: for UTF-8
> representation and for wchar_t representation. They are needed not for
> optimization but for supporting C API which returns borrowed references for
> such representations.
>
> The
Guido van Rossum schrieb am 21.09.2018 um 19:35:
> Though now I start worrying about interned strings. That's a concept that's
> a little closer to being a feature.
True. While there's the general '"ab"+"cd" is (not) "abcd"' caveat, I'm
sure quite a bit of code out there assumes that parsed
Larry Hastings schrieb am 14.09.2018 um 23:27:
> What the patch does: it takes all the Python modules that are loaded as
> part of interpreter startup and deserializes the marshalled .pyc file into
> precreated objects stored as static C data.
What about the small integers cache? The C
Carl Shapiro schrieb am 20.09.2018 um 20:21:
> On Wed, Sep 19, 2018 at 12:32 AM, Stefan Behnel wrote:
>
>> Also, one thing that would be interesting to find out is whether constant
>> Python data structures can actually be pre-allocated in the data segment
>> (and I m
Carl Shapiro schrieb am 18.09.2018 um 22:44:
> How might people feel about using the linker to bundle a list of pre-loaded
> modules into a single-file executable?
One way to do that would be to compile Python modules with Cython and link
them in statically, instead of compiling them to .pyc
Yury Selivanov schrieb am 04.09.2018 um 18:19:
> On Sat, Sep 1, 2018 at 6:12 PM Stefan Behnel wrote:
>> Yury Selivanov schrieb am 07.08.2018 um 19:34:
>>> The first goal is to compile mypy with it to make it faster, so I hope
>>> that the project will be completed.
>&
Yury,
given that people are starting to quote enthusiastically the comments you
made below, let me set a couple of things straight.
Yury Selivanov schrieb am 07.08.2018 um 19:34:
> On Mon, Aug 6, 2018 at 11:49 AM Ronald Oussoren via Python-Dev wrote:
>
>> I have no strong opinion on using
Greg Ewing schrieb am 23.08.2018 um 03:34:
> Neil Schemenauer wrote:
>> Perhaps a "argument clinic on steroids" would be the proper
>> approach. So, extensions would mostly be written in C. However, we
>> would have a pre-processor that does some "magic" to make using the
>> Python API cleaner.
Antoine Pitrou schrieb am 23.08.2018 um 09:04:
> On Thu, 23 Aug 2018 08:07:08 +0200
> Jeroen Demeyer wrote:
>>> - the maintenance problem (how do ensure we can change small things in
>>>the C API, especially semi-private ones, without having to submit PRs
>>>to Cython as well)
>>
>> Why
Petr Viktorin schrieb am 10.08.2018 um 13:48:
> Would this be better than a flag + raising an error on init?
Ok, I've implemented this in Cython for now, to finally move the PEP-489
support forward. The somewhat annoying drawback is that module reloading
previously *seemed* to work, simply
Antoine Pitrou schrieb am 11.08.2018 um 15:19:
> On Fri, 10 Aug 2018 19:15:11 +0200 Armin Rigo wrote:
>> Currently, the C API only allows Psyco-style JITting (much slower than
>> PyPy). All three other points might not be possible at all without a
>> seriously modified C API. Why? I have no
Petr Viktorin schrieb am 10.08.2018 um 11:51:
> On 08/10/18 11:21, Stefan Behnel wrote:
>> coming back to PEP 489 [1], the multi-phase extension module
>> initialization. We originally designed it as an "all or nothing" feature,
>> but as it turns out, the "
Hi,
coming back to PEP 489 [1], the multi-phase extension module
initialization. We originally designed it as an "all or nothing" feature,
but as it turns out, the "all" part is so difficult to achieve that most
potential users end up with "nothing". So, my question is: could we split
it up so
Hi,
this is getting a bit out of scope for this list. I propose to move further
questions about general Cython usage to he cython-users mailing list.
Matěj Cepl schrieb am 08.08.2018 um 12:44:
> On 2018-08-06, 15:13 GMT, Stefan Behnel wrote:
>> Not sure I understand this correctly, bu
Ronald Oussoren via Python-Dev schrieb am 06.08.2018 um 15:25:
>> On 5 Aug 2018, at 18:14, Nick Coghlan wrote:
>> On 5 August 2018 at 18:06, Ronald Oussoren wrote:
>>> I’m not sure if I understand this, ctypes and cffi are used to access C APIs
>>> without writing C code including the CPython API
Antoine Pitrou schrieb am 04.08.2018 um 15:57:
> Le 04/08/2018 à 15:13, Nick Coghlan a écrit :
>>
>> It'd be *really* nice to at least be able to write some of the C API
>> tests directly in Cython rather than having to fiddle about with
>> splitting the test between the regrtest parts that
Brett Cannon schrieb am 01.08.2018 um 18:17:
> On Tue, 31 Jul 2018 at 13:42 Stefan Behnel wrote:
>> Antoine Pitrou schrieb am 31.07.2018 um 09:45:
>>> Also, a C extension can be built-in (linked statically into the
>>> interpreter), which I think would be hard to do
Jeroen Demeyer schrieb am 31.07.2018 um 14:01:
> On 2018-07-31 12:56, Victor Stinner wrote:
>> I would be nice to be able to use something to "generate" C
>> extensions, maybe even from pure Python code.
>
> Cython has a "pure Python mode" which does exactly that. There are several
> ways to
Antoine Pitrou schrieb am 31.07.2018 um 09:45:
> On Tue, 31 Jul 2018 09:27:03 +0200
> Jeroen Demeyer wrote:
>> On 2018-07-31 08:58, Antoine Pitrou wrote:
>>> I think Stefan is right that we
>>> should push people towards Cython and alternatives, rather than direct
>>> use of the C API (which
Jeroen Demeyer schrieb am 30.07.2018 um 16:40:
> On 2018-07-30 15:35, INADA Naoki wrote:
>> As repeatedly said, PEP 580 is very complicated protocol
>> when just implementing callable object.
>
> Can you be more concrete what you find complicated? Maybe I can improve the
> PEP to explain it more.
Jeroen Demeyer schrieb am 22.07.2018 um 22:54:
> On 2018-07-22 22:32, Antoine Pitrou wrote:
>> - more importantly, issue26110 is entirely internal changes, while you
>> are proposing to add a new protocol (which is like a new API)
>
> Just to make sure I understand you: your point is that it's
Guido van Rossum schrieb am 22.07.2018 um 01:14:
> The cost would be if we were to end up maintaining all that code and it
> wouldn’t make much difference.
Well, this is exactly my point. Someone has to maintain the *existing* code
base and help newcomers to get into it and understand it. This is
Guido van Rossum schrieb am 21.07.2018 um 22:46:
> Given the cost of a mistake here I recommend a higher standard.
May I ask what you think the "cost of a mistake" is here?
Jeroen has already implemented most of this, and is willing to provide
essentially a shrink-wrapped implementation. He has
INADA Naoki schrieb am 11.07.2018 um 02:01:
> On Wed, Jul 11, 2018 at 7:47 AM Victor Stinner wrote:
>> I proposed something simpler, but nobody tried to implement it.
>> Instead of calling the long and complex PyArg_Parse...() functions,
>> why not generating C code to parse arguments instead? The
INADA Naoki schrieb am 11.07.2018 um 02:12:
> On Tue, Jul 10, 2018 at 10:20 PM Antoine Pitrou wrote:
>> On Tue, 10 Jul 2018 21:59:28 +0900
>> INADA Naoki wrote:
>>>
>>> Then, the function is called from another C extension like this:
>>>
>>> PyObject_CallFunction(func, "n", 42);
>>>
>>> Currently,
Jeroen Demeyer schrieb am 08.07.2018 um 09:07:
> On 2018-07-07 10:55, Serhiy Storchaka wrote:
>> The first part of
>> handling arguments can be made outside of the C function, by the calling
>> API.
>
> Sure, it could be done but I don't see the advantage. I don't think you
> will gain
INADA Naoki schrieb am 07.07.2018 um 17:16:
>> 2. The new API should be used internally so that 3rd party extensions
>> are not second class citizens in term of call performance.
>
> These PEPs proposes new public protocol which can be implemented
> by 3rd party extensions, especially Cython.
>
Nick Coghlan schrieb am 07.07.2018 um 16:14:
> when the new calling
> convention is tied to a protocol that any type can implement (as PEP
> 580 proposes), the concern doesn't even arise.
Nick, +1 to all of what you said in your reply, and I also really like the
fact that this proposal is
Hi Serhiy!
Serhiy Storchaka schrieb am 07.07.2018 um 10:55:
> There is my idea. Split every of keyword argument parsing functions on two
> parts. The first part linearize keyword arguments, it converts positional
> and keyword arguments (in whatever form they were presented) into a linear
> array
INADA Naoki schrieb am 07.07.2018 um 10:08:
> Thank you. Do you plan to make it default when PEP 580 is accepted
> and implemented?
It will become the default at some point, I'm sure. Note that we will still
have to support older Python versions, though, currently 2.6+, which would
not have the
INADA Naoki schrieb am 07.07.2018 um 06:10:
> How often "custom method type" are used?
>
> I thought Cython use it by default.
> But when I read code generated by Cython, I can't find it.
> It uses normal PyMethodDef and tp_methods.
>
> I found CyFunction in Cython repository, but I can't find
>
Jeroen Demeyer schrieb am 05.07.2018 um 16:53:
> The only case when this handling of keywords is suboptimal is when using
> **kwargs. In that case, a dict must be converted to a tuple. It looks hard
> to me to support efficiently both the case of fixed keyword arguments
> (f(foo=x)) and a keyword
Serhiy Storchaka schrieb am 20.06.2018 um 18:56:
> 20.06.18 18:42, INADA Naoki пише:
>> I don't have any idea about changing METH_FASTCALL more.
>> If Victor and Serhiy think so, and PyPy maintainers like it too, I want
>> to make it public as soon as possible.
>
> I don't have objections against
Victor Stinner schrieb am 19.06.2018 um 16:59:
> 2018-06-19 13:58 GMT+02:00 Jeroen Demeyer :
>> Personally, I think that you are exaggerating these issues.
>
> I'm not trying to convince you to abandon the idea. I would be happy
> to be able to use FASTCALL in more cases! I just tried to explain
Victor Stinner schrieb am 18.06.2018 um 15:09:
> I tried two options to add support for FASTCALL on calling an object:
> add a flag in tp_flags and reuse tp_call, or add a new tp_fastcall
> slot. I failed to implement correctly any of these two options.
>
> There are multiple issues with
1 - 100 of 622 matches
Mail list logo
