On 1 April 2018 at 00:48, Jeroen Demeyer wrote:
> I have prepared a PEP draft for unifying function/method classes. You can
> find it at
>
> https://github.com/jdemeyer/PEP-functions
>
> This has not officially been submitted as PEP yet, I want to hear your
> comments first.
I've only read the de
I want to support this work. I can't promise your PEP will be accepted, but
it looks like you've done your homework, and you're getting feedback from
core devs who care about this area. (One of them may end up BDFL-delegate.)
It will be a long road to success, but I recommend that you start with a
31.03.18 17:48, Jeroen Demeyer пише:
I have prepared a PEP draft for unifying function/method classes. You
can find it at
https://github.com/jdemeyer/PEP-functions
This has not officially been submitted as PEP yet, I want to hear your
comments first.
I once tried to move in this direction (
On Tue, Apr 3, 2018 at 12:46 AM, Jeroen Demeyer wrote:
> On 2018-04-02 12:39, INADA Naoki wrote:
>>
>> Thanks for writing such hard PEP.
>>
>> At first glance, it new type hierarchy seems OK.
>> But I can't understand rational for new flags.
>
>
> Which flags in particular do you mean? I just push
On 2018-04-02 12:39, INADA Naoki wrote:
Thanks for writing such hard PEP.
At first glance, it new type hierarchy seems OK.
But I can't understand rational for new flags.
Which flags in particular do you mean? I just pushed an update
explaining the rationale of METH_ARG0_FUNCTION:
https://gi
Thanks for writing such hard PEP.
At first glance, it new type hierarchy seems OK.
But I can't understand rational for new flags.
And it's very difficult to estimate runtime and maintenance cost of
the PEP, without draft implementation.
FASTCALL is introduced in recently version, and it make imp
On 1 April 2018 at 02:58, Jeroen Demeyer wrote:
> On 2018-03-31 18:09, Steven D'Aprano wrote:
>> Seems to me that if you want a fast, exact (no subclasses) check, you
>> should use "type(obj) is Class" rather than isinstance. If the *only*
>> reason to prohibit subclassing is to make isinstance a
On Sat, Mar 31, 2018 at 06:58:19PM +0200, Jeroen Demeyer wrote:
> On 2018-03-31 18:09, Steven D'Aprano wrote:
> >It seems like a huge amount of work
>
> What is a huge amount of work? Writing the PEP? Implementing the PEP?
> Using the PEP? Adapting existing Python code to the PEP?
Any or all of
On 2018-03-31 21:12, Terry Reedy wrote:
I would be all for more of the builtins and stdlib being converted.
Can't 3rd-party C code use ArgumentClinic?
ArgumentClinic stores the signature as text. For default values, only a
few specific classes are supported. I want to support arbitrary Python
On 3/31/2018 12:09 PM, Steven D'Aprano wrote:
On Sat, Mar 31, 2018 at 04:48:56PM +0200, Jeroen Demeyer wrote:
I have prepared a PEP draft for unifying function/method classes. You
can find it at
https://github.com/jdemeyer/PEP-functions
This has not officially been submitted as PEP yet, I want
On 2018-03-31 18:09, Steven D'Aprano wrote:
It seems like a huge amount of work
What is a huge amount of work? Writing the PEP? Implementing the PEP?
Using the PEP? Adapting existing Python code to the PEP?
Why isn't the answer to provide a hook to support introspection?
That is a lot eas
On Sat, Mar 31, 2018 at 04:48:56PM +0200, Jeroen Demeyer wrote:
> I have prepared a PEP draft for unifying function/method classes. You
> can find it at
>
> https://github.com/jdemeyer/PEP-functions
>
> This has not officially been submitted as PEP yet, I want to hear your
> comments first.
It
I have prepared a PEP draft for unifying function/method classes. You
can find it at
https://github.com/jdemeyer/PEP-functions
This has not officially been submitted as PEP yet, I want to hear your
comments first.
Thanks,
Jeroen.
___
Python-ideas
13 matches
Mail list logo
