On 19 June 2018 at 16:12, INADA Naoki wrote:
>
> On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:
>>
>> On 2018-06-18 16:55, INADA Naoki wrote:
>> > Speeding up most python function and some bultin functions was very
>> > significant.
>> > But I doubt making some 3rd party call 20% faster ca
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 why
I chose to abandon my idea.
FASTCALL is cute on tiny
On 19 June 2018 at 13:02, Nick Coghlan wrote:
> On 19 June 2018 at 16:12, INADA Naoki wrote:
> >
> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer
> wrote:
> >>
> >> On 2018-06-18 16:55, INADA Naoki wrote:
> >> > Speeding up most python function and some bultin functions was very
> >> > signif
That's why I suggested to add new benchmark.
2018年6月19日(火) 22:22 Ivan Levkivskyi :
> On 19 June 2018 at 13:02, Nick Coghlan wrote:
>
>> On 19 June 2018 at 16:12, INADA Naoki wrote:
>> >
>> > On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer
>> wrote:
>> >>
>> >> On 2018-06-18 16:55, INADA Naoki w
On 19 June 2018 at 16:12, INADA Naoki wrote:
>
> On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:
>>
>> On 2018-06-18 16:55, INADA Naoki wrote:
>> > Speeding up most python function and some bultin functions was very
>> > significant.
>> > But I doubt making some 3rd party call 20% faster ca
On 2018-06-18 15:09, Victor Stinner wrote:
There are multiple issues with tp_fastcall:
Personally, I think that you are exaggerating these issues.
Below, I'm writing the word FASTCALL to refer to tp_fastcall in your
patch as well as my C call protocol in the PEP-in-progress.
* ABI issue: i
On Mon, 18 Jun 2018 19:49:28 +0200
Stefan Behnel wrote:
> 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
On Tue, Jun 19, 2018 at 2:56 PM Jeroen Demeyer wrote:
> On 2018-06-18 16:55, INADA Naoki wrote:
> > Speeding up most python function and some bultin functions was very
> > significant.
> > But I doubt making some 3rd party call 20% faster can make real
> > applications significant faster.
>
> The
On 2018-06-18 16:55, INADA Naoki wrote:
Speeding up most python function and some bultin functions was very
significant.
But I doubt making some 3rd party call 20% faster can make real
applications significant faster.
These two sentences are almost contradictory. I find it strange to claim
tha
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 tp_fastca
Like Inada-san, I would like to see the implementation first.
On Mon, Jun 18, 2018, 07:33 Jeroen Demeyer wrote:
> On 2018-06-18 15:09, Victor Stinner wrote:
> > 2) we implemented a lot of other optimizations which made calls faster
> > without having to touch tp_call nor tp_fastcall.
>
> And tha
On Mon, Jun 18, 2018 at 11:33 PM Jeroen Demeyer wrote:
> On 2018-06-18 15:09, Victor Stinner wrote:
> > 2) we implemented a lot of other optimizations which made calls faster
> > without having to touch tp_call nor tp_fastcall.
>
> And that's a problem because these optimizations typically only w
On 2018-06-18 15:09, Victor Stinner wrote:
2) we implemented a lot of other optimizations which made calls faster
without having to touch tp_call nor tp_fastcall.
And that's a problem because these optimizations typically only work for
specific classes. My PEP wants to replace those by somethi
Hi,
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 tp_fastcall:
* ABI issue: it's possible to load a C extensio
I didn't meant comparing tp_fastcall and your PEP.
I just meant we need to compare complexity and benefit (performance),
and we need reference implementation for comparing.
On Mon, Jun 18, 2018 at 3:03 PM Jeroen Demeyer wrote:
> On 2018-06-18 03:34, INADA Naoki wrote:
> > Victor had tried to a
On 2018-06-18 03:34, INADA Naoki wrote:
Victor had tried to add `tp_fastcall` slot, but he suspended his effort
because
it's benefit is not enough for it's complexity.
https://bugs.python.org/issue29259
I has a quick look at that patch and it's really orthogonal to what I'm
proposing. I'm prop
Hi Jeroen.
It's interesting, but I think we need reference implementation to compare
it's benefit with it's complexity.
Victor had tried to add `tp_fastcall` slot, but he suspended his effort
because
it's benefit is not enough for it's complexity.
https://bugs.python.org/issue29259
I think if yo
> On 17 Jun 2018, at 16:31, Stefan Behnel wrote:
>
> Ronald Oussoren schrieb am 17.06.2018 um 14:50:
>> Why did you add a tp_ccalloffset slot to the type with the actual
>> information in instances instead of storing the information in a slot?
>
> If the configuration of the callable was in
On 2018-06-17 14:50, Ronald Oussoren wrote:
This looks interesting. Why did you add a tp_ccalloffset slot to the type with
the actual information in instances instead of storing the information in a
slot?
Think of built-in functions. Every built-in function is a different
callable and calls
Ronald Oussoren schrieb am 17.06.2018 um 14:50:
> Why did you add a tp_ccalloffset slot to the type with the actual information
> in instances instead of storing the information in a slot?
If the configuration of the callable was in the type, you would need a
separate type for each kind of calla
> On 17 Jun 2018, at 11:00, Jeroen Demeyer wrote:
>
> Hello,
>
> I have been working on a slightly different PEP to use a new type slot
> tp_ccalloffset instead the base_function base class. You can see the work in
> progress here:
>
> https://github.com/jdemeyer/PEP-ccall
>
> By creating
On 17 June 2018 at 19:00, Jeroen Demeyer wrote:
> Hello,
>
> I have been working on a slightly different PEP to use a new type slot
> tp_ccalloffset instead the base_function base class. You can see the work in
> progress here:
>
> https://github.com/jdemeyer/PEP-ccall
>
> By creating a new protoc
Hello,
I have been working on a slightly different PEP to use a new type slot
tp_ccalloffset instead the base_function base class. You can see the
work in progress here:
https://github.com/jdemeyer/PEP-ccall
By creating a new protocol that each class can implement, there is a
full decouplin
Having had some time to let this settle for a bit, I hope it doesn't
get abandoned just because it was to complicated to come to a
conclusion.
I'd like to attempt to summarize the main ideas as follows.
1) Currently the "fast call" optimization is implemented by by
checking explicitly for a set o
On 2018-05-19 15:29, Nick Coghlan wrote:
That's not how code reviews work, as their complexity is governed by the
number of lines changed (added/removed/modified), not just the number of
lines that are left at the end.
Of course, you are right. I didn't mean literally that only the end
result
On 17 May 2018 at 06:34, Jeroen Demeyer wrote:
> On 2018-05-16 17:31, Petr Viktorin wrote:
>
>> The larger a change is, the harder it is to understand
>>
>
> I already disagree here...
>
> I'm afraid that you are still confusing the largeness of the *change* with
> the complexity of the *result*
On 2018-05-16 17:31, Petr Viktorin wrote:
Less disruptive changes tend to have a better backwards compatibility story.
A less intertwined change makes it easier to revert just a single part,
in case that becomes necessary.
I'll just repeat what I said in a different post on this thread: we can
On 2018-05-16 17:31, Petr Viktorin wrote:
The larger a change is, the harder it is to understand
I already disagree here...
I'm afraid that you are still confusing the largeness of the *change*
with the complexity of the *result* after the change was implemented.
A change that *removes* compl
Petr Viktorin schrieb am 15.05.2018 um 18:36:
> On 05/15/18 05:15, Jeroen Demeyer wrote:
>> An important note is that it was never my goal to create a minimal PEP. I
>> did not aim for changing as little as possible. I was thinking: we are
>> changing functions, what would be the best way to implem
On 05/15/18 17:55, Jeroen Demeyer wrote:
On 2018-05-15 18:36, Petr Viktorin wrote:
Naturally, large-scale
changes have less of a chance there.
Does it really matter that much how large the change is? I think you are
focusing too much on the change instead of the end result.
As I said in my
On 2018-05-15 18:36, Petr Viktorin wrote:
Naturally, large-scale
changes have less of a chance there.
Does it really matter that much how large the change is? I think you are
focusing too much on the change instead of the end result.
As I said in my previous post, I could certainly make less
On 2018-05-15 18:36, Petr Viktorin wrote:
What is your ultimate use case?
(I'll just answer this one question now and reply to the more technical
comments in another thread)
My ultimate use case is being able to implement functions and methods
which are
(A) equally fast as the existing bu
On 05/15/18 05:15, Jeroen Demeyer wrote:
On 2018-05-14 19:56, Petr Viktorin wrote:
It does quite a lot of things, and the changes are all intertwined,
which will make it hard to get reviewed and accepted.
The problem is that many things *are* already intertwined currently. You
cannot deal wit
On 2018-05-14 22:38, Petr Viktorin wrote:
Why are these flags added?
I made a minor edit to the PEP to remove those flags:
https://github.com/python/peps/pull/649
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listin
On 2018-05-14 19:56, Petr Viktorin wrote:
It does quite a lot of things, and the changes are all intertwined,
which will make it hard to get reviewed and accepted.
The problem is that many things *are* already intertwined currently. You
cannot deal with functions without involving methods for
On 2018-05-14 22:38, Petr Viktorin wrote:
Why are these flags added?
They aren't free – the space of available flags is not infinite. If
something (Cython?) needs eight of them, it would be nice to mention the
use case, at least as an example.
What should Python do with a m_methods entry that ha
On 05/05/18 04:55, Jeroen Demeyer wrote:
Hello all,
I have updated PEP 575 in response to some posts on this mailing list
and to some discussions in person with the core Cython developers.
See https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version
On 05/05/18 04:55, Jeroen Demeyer wrote:
Hello all,
I have updated PEP 575 in response to some posts on this mailing list
and to some discussions in person with the core Cython developers.
See https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version
On Tue, 8 May 2018, 16:33 Jeroen Demeyer, wrote:
> On 2018-05-06 09:35, Nick Coghlan wrote:
> > Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try
> > to claim one of the lightning talk slots at the Language Summit to
> > discuss this with folks in person :)
>
> Sounds great
On 2018-05-06 09:35, Nick Coghlan wrote:
Thanks for this update Jeroen! If it doesn't come up otherwise, I'll try
to claim one of the lightning talk slots at the Language Summit to
discuss this with folks in person :)
Sounds great! I'd love to hear what people think.
As an example of how the n
On 5 May 2018 at 18:55, Jeroen Demeyer wrote:
> Hello all,
>
> I have updated PEP 575 in response to some posts on this mailing list and
> to some discussions in person with the core Cython developers.
> See https://www.python.org/dev/peps/pep-0575/
>
> The main differences with respect to the pr
Hello all,
I have updated PEP 575 in response to some posts on this mailing list
and to some discussions in person with the core Cython developers.
See https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version are:
* "builtin_function" was renamed to
On 5/3/2018 6:22 AM, Jeroen Demeyer wrote:
On 2018-05-03 11:30, Victor Stinner wrote:
Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.
I don't really see how that can be done here. As Stefan said
The problem is that this
change
On 2018-05-03 11:30, Victor Stinner wrote:
Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.
I don't really see how that can be done here. As Stefan said
The problem is that this
change does not really fit into the deprecation cyc
2018-05-03 11:22 GMT+02:00 Stefan Behnel :
> The final split could then be done later, e.g. for Py4.0, where people
> would be less surprised about minor breakages.
Please don't queue backward incompatible changes for Python 4.0. You
should use the regular deprecation process.
(I didn't read the
Hi,
let me start by saying that I'm much in favour of this change. It cleans up
a lot of the function implementation and makes it much easier to integrate
efficiently with external wrapper tools.
Guido van Rossum schrieb am 14.04.2018 um 23:14:
> On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer w
This would be really useful for Cython, as well as a nice cleanup in
general (e.g. replacing 4 special cases with one check).
It seems the main concern is the user-visible change in types. If this is
determined to be too backwards incompatible (I would be surprised if many
projects are impacted, b
On 2018-04-30 15:38, Mark Shannon wrote:
While a unified *interface* makes sense, a unified class hierarchy and
implementation, IMO, do not.
The main reason for the common base class is performance: in the
bytecode interpreter, when we call an object, CPython currently has a
special case for
On 30 April 2018 at 23:38, Mark Shannon wrote:
>
> On 12/04/18 17:12, Jeroen Demeyer wrote:
>
>> Dear Python developers,
>>
>> I would like to request a review of PEP 575, which is about changing the
>> classes used for built-in functions and Python functions and methods. The
>> text of the PEP c
On 12/04/18 17:12, Jeroen Demeyer wrote:
Dear Python developers,
I would like to request a review of PEP 575, which is about changing the
classes used for built-in functions and Python functions and methods.
The text of the PEP can be found at
The motivation of PEP 575 is to allow introspe
Hello all,
I have updated PEP 575 and its reference implementation. See
https://www.python.org/dev/peps/pep-0575/
The main differences with respect to the previous version are:
* METH_PASS_FUNCTION now passes the function *in addition* to self
(previously, it was passed *instead* of self).
*
On 2018-04-20 12:02, Jeroen Demeyer wrote:
One solution to improve backwards compatibility would be to duplicate
some classes. For example, make a separate class for bound methods in
extension types, which would be literally a duplicate of the existing
types.MethodType class (possibly with a diff
On 2018-04-14 23:14, Guido van Rossum wrote:
That actually sounds like a pretty big problem. I'm sure there is lots
of code that doesn't *just* duck-type nor calls inspect but uses
isinstance() to decide how to extract the desired information.
I have been thinking about this some more...
One s
On 2018-04-16 02:32, Raymond Hettinger wrote:
I don't think that confidence is warranted. The world of Python is very large.
When public APIs (such as that in the venerable types module) get changed, is
virtually assured that some code will break.
Yes, *some* code will break, I never denied
> On Apr 15, 2018, at 5:50 AM, Jeroen Demeyer wrote:
>
> On 2018-04-14 23:14, Guido van Rossum wrote:
>> That actually sounds like a pretty big problem. I'm sure there is lots
>> of code that doesn't *just* duck-type nor calls inspect but uses
>> isinstance() to decide how to extract the desire
15.04.18 16:09, Nick Coghlan пише:
On 15 April 2018 at 22:50, Jeroen Demeyer wrote:
I've been told that there might also be a problem with Random._randbelow,
even though it doesn't cause test failures.
From Raymond's description (and from an initial reading of the code),
the _randbelow case
On 15 April 2018 at 22:50, Jeroen Demeyer wrote:
> On 2018-04-14 23:14, Guido van Rossum wrote:
>>
>> That actually sounds like a pretty big problem. I'm sure there is lots
>> of code that doesn't *just* duck-type nor calls inspect but uses
>> isinstance() to decide how to extract the desired info
On 2018-04-14 23:14, Guido van Rossum wrote:
That actually sounds like a pretty big problem. I'm sure there is lots
of code that doesn't *just* duck-type nor calls inspect but uses
isinstance() to decide how to extract the desired information.
In the CPython standard library, the *only* fixes t
On Sat, Apr 14, 2018 at 2:17 AM, Jeroen Demeyer wrote:
> On 2018-04-13 21:30, Raymond Hettinger wrote:
>
>> It would be nice to have a section that specifically discusses the
>> implications with respect to other existing function-like tooling:
>> classmethod, staticmethod, partial, itemgetter, a
On 2018-04-13 15:23, Nick Coghlan wrote:
There's also a section in the rationale which refers to METH_USRx
flags, which I'm guessing from context are an idea you were
considering proposing, but eventually dropped from the rest of the
PEP.
No, I actually still want to propose it. In my latest up
On 2018-04-13 21:30, Raymond Hettinger wrote:
It would be nice to have a section that specifically discusses the implications
with respect to other existing function-like tooling: classmethod,
staticmethod, partial, itemgetter, attrgetter, methodgetter, etc.
My hope is that there are no such
> On Apr 12, 2018, at 9:12 AM, Jeroen Demeyer wrote:
>
> I would like to request a review of PEP 575, which is about changing the
> classes used for built-in functions and Python functions and methods. The
> text of the PEP can be found at
>
> https://www.python.org/dev/peps/pep-0575/
Thanks
To make it easier to test and try out PEP 575, I created a binder repo:
https://mybinder.org/v2/gh/jdemeyer/pep575binder.git
/master?filepath=index.ipynb
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-d
On 13 April 2018 at 02:12, Jeroen Demeyer wrote:
> Dear Python developers,
>
> I would like to request a review of PEP 575, which is about changing the
> classes used for built-in functions and Python functions and methods. The
> text of the PEP can be found at
>
> https://www.python.org/dev/peps/
Dear Python developers,
I would like to request a review of PEP 575, which is about changing the
classes used for built-in functions and Python functions and methods.
The text of the PEP can be found at
https://www.python.org/dev/peps/pep-0575/
No substantial changes to the contents of the P
65 matches
Mail list logo
