Re: [Python-ideas] Assign-in-place operator
On 2019-06-04 14:34, Ricky Teachey wrote: "update an object with another" (dunder update) Yes, that's essentially what I meant. To me, "assign an object in place" and "update an object with another" mean the same thing. A few come to mind: my_dict.update This is PEP 584, where += is used my_gen.send Sure, this makes sense to me! my_list.append I disagree because this keeps the contents of the old list. my_list.extend This should just be a generalization of the += operator. my_stream.write I'm not convinced. If you have an operator for writing, you expect an operator for reading too. But then, the analogy with += breaks down for me. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Assign-in-place operator
On 2019-06-04 13:29, Steven D'Aprano wrote:> As far as I can tell, there is no difference between your proposal and the OP's proposal except you have changed the name of the dunder from __arrow__ to __iassign__. I never claimed that there was a difference. I just tried to clarify what the original poster asked and put it in a wider context, because the original post was way too much focused on hardware stuff. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Assign-in-place operator
I'd like to get rid of all the signal and HDL stuff (whatever that means) in this thread, so I think what the original poster really wants is an "assign in place" operator. Basically, something like += or *= but without the arithmetic. When you think of it this way, it's not an unreasonable request. There would be at least one major use of this operator within CPython, for lists. With this proposal, the awkward syntax (there are 219 instances of this in the CPython sources) L[:] = new_list would become L <== new_list The implementation would be completely analogous to the existing in-place arithmetic operators. For example A <== B would become equivalent to A = type(A).__iassign__(A, B). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Exception for developer errors?
On 2019-04-11 00:09, Stefano Borini wrote: I occasionally found situations where I want to raise an exception for errors that can only arise because the developer made a mistake, for example: I use AssertionError for this. An assertion failure means "this is a bug", so that seems the right choice to me. You don't need to use an actual assert statement, you can manually raise AssertionError too. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] dict.merge(d1, d2, ...) (Counter proposal for PEP 584)
On 2019-03-21 17:11, Guido van Rossum wrote: I don't find it easy to understand or remember that d1.update(d2) modifies d1 in place, while d1.merge(d2) first copies d1. That would be an advantage with + versus += (or | versus |=). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Preallocated tuples and dicts for function calls
On 2019-03-08 22:16, Martin Bammer wrote: Hi, what about the idea that the interpreter preallocates and preinitializes the tuples and dicts for function calls where possible when loading a module? The basic premise here is wrong: function calls using the METH_FASTCALL convention don't need to allocate any temporary tuple/dict for function calls. Of course, not all function calls use METH_FASTCALL, but most of them where performance matters do. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEPs: Theory of operation [was: Moving to another forum system ...]
On 2018-10-03 17:56, Wes Turner wrote: The phrase "core developers and the BDFL" is where some sort of alternate quorum/majority policy would need to be specified if this is a contentious issue in practice? The whole point of the process described in PEP 8000 is to make this more precise. The only question for now (in particular for PEP 580) is whether the old BDFL-Delegate system can still work until the new governance model has been decided. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Keyword only argument on function call
On 2018-09-11 14:20, Steven D'Aprano wrote: On Tue, Sep 11, 2018 at 08:53:55PM +1000, Steven D'Aprano wrote: [...] Or perhaps we could have an officially blessed way to give tools a hint as to what the real signature is. class Child(Parent): @signature_hint(Parent.method) def method(self, **kwargs): pass I was planning to submit a PEP to support a __signature__ attribute (without the _hint) in inspect.signature(), see PEP 576 and PEP 579 for some context. The reason is very different from what is suggested here: to allow implementing custom function-like classes that inspect should treat as functions. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fix some special cases in Fractions?
With gmpy2 (note that mpq=fractions, mpfr=floating-point reals):
>>> from gmpy2 import mpq
>>> mpq("1/1") ** mpq("2/3")
mpfr('1.0')
>>> mpq("-1/1") ** mpq("2/3")
mpfr('nan')
>>> mpq("0/1") ** mpq("2/3")
mpfr('0.0')
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fix some special cases in Fractions?
On 2018-08-30 11:11, Jonathan Fine wrote: If anyone has time and ready access, it would help to know what https://www.sympy.org/en/index.html does with this. It handles such powers symbolically, not actually returning a numerical result: >>> from sympy import Rational >>> Rational(1,2) ** Rational(2,3) 2**(1/3)/2 >>> Rational(1,1) ** Rational(2,3) 1 >>> Rational(-1,1) ** Rational(2,3) (-1)**(2/3) >>> Rational(0,1) ** Rational(2,3) 0 ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fix some special cases in Fractions?
On 2018-08-30 11:05, Jonathan Fine wrote: I'm used to using a number theory computer algebra system https://pari.math.u-bordeaux.fr/. I don't think that a comparison with PARI is very relevant because PARI doesn't really have a type system the way that Python does. For example the fraction 3/1 doesn't really exist in PARI, only the integer 3 does. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Fix some special cases in Fractions?
On 2018-08-30 06:39, Neil Girdhar wrote: I'd like these to be Fraction(1), Fraction(1), and Fraction(0). Why? I cannot think of any natural use case why you would want Fractions for a few special cases on an operation which returns non-Fractions generically. I consider it a feature to know in advance the type of the output of an operation, given the types of the input. Having an unexpected type suddenly show up because you happen to hit a special case is a recipe for bugs. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] With expressions
On 2018-08-04 09:43, Steven D'Aprano wrote: If you want to propose a general exception suppressing mechanism (aside from the existing try...except statement) then propose it as an independent PEP. This was already tried in PEP 463 (which IMHO is a pity that it wasn't accepted because it seems really useful). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Change repr of collections.OrderedDict to be more dict-like
On 2018-07-27 00:50, David Mertz wrote: I often use doctests to verify APIs and behaviors when I update code. I know I'm in a minority and most developers slightly disparage doctests. If it makes you feel better, SageMath development uses only doctests for testing. We have over 30 doctests and it works great! We do use a customized doctesting framework though. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] slice[] to get more complex slices
On 2018-07-23 12:24, Jeroen Demeyer wrote: Another solution that nobody has mentioned (as far as I know) is to add additional syntax to the language for that. For example, one could say that (1:3) could be used to construct slice(1, 3) directly. The parentheses are required to avoid confusion with type hints. I'm not a Python language expert, but I don't think that type hints can occur inside parentheses like that. And this could be extended to tuples (1:3, 2:4) and lists [1:3, 2:4] of slices too. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] slice[] to get more complex slices
On 2018-07-23 11:58, Grégory Lielens wrote: Not sure slice[1::3] can be done It can be done. Since "slice" is a class, it would require a metaclass though. Another solution that nobody has mentioned (as far as I know) is to add additional syntax to the language for that. For example, one could say that (1:3) could be used to construct slice(1, 3) directly. The parentheses are required to avoid confusion with type hints. I'm not a Python language expert, but I don't think that type hints can occur inside parentheses like that. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-13 14:11, Steven D'Aprano wrote: What it *actually* does is: is_almost_certainly_prime_except_for_a_ludicrously_microscopic_chance_of_error_thousands_of_times_less_likely_than_a_stray_cosmic_ray_flipping_a_bit_in_memory_and_causing_the_wrong_result_to_be_returned() That's just a long variant of is_probable_prime() If your bank is satisfied with "mere probable prime number" to transfer billions of dollars around the world, then I'm sure that the users of Python's std library should be too. That's besides the point. I agree that probable primes are good enough, just don't call them "prime". ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-13 14:26, Steven D'Aprano wrote: I'm pretty sure that Sage is using numpy This computation uses PARI/GP, a dedicated library for number theory (https://pari.math.u-bordeaux.fr/) with a Python interface (https://github.com/defeo/cypari2). And it's probably making far less conservative choices about the rate of false positives it is willing to accept. It's an actual primality test, not a probable primality test. But for numbers which are not prime (like your examples), the difference doesn't actually matter. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-13 11:50, Jacco van Dorp wrote: At the very least, use is_likely_prime() as function name. I agree with you here: the function name should reflect what it actually does. (Note that the technical term is "probable prime", so it should be is_probable_prime) But I don't think that the Python stdlib should have a proven is_prime() function because that would be complicated, slow and have very limited benefit over is_probable_prime(). ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-13 10:43, Jacco van Dorp wrote: If there's going to be failure possible primality tests, there should also exist certain ones. No matter how slow it can be to do it. A certain primality test would be too specialized for the Python stdlib. If you really need that (which you typically don't), there are existing number theory packages. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-13 04:02, Chris Angelico wrote: Haha. Okay. I'm not familiar with every possible primality test, so I had no idea that they ALL have the same failure mode :) There exist guaranteed primality tests, but those are much slower and more complicated. The state of the art is ECPP: https://en.wikipedia.org/wiki/Elliptic_curve_primality ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
On 2018-07-12 20:11, Steven D'Aprano wrote:
about 4.7 seconds to test 2**800 + 1;
In SageMath:
sage: n = 2**800+1; timeit('is_prime(n)')
625 loops, best of 3: 303 µs per loop
That's 4 orders of magnitude faster...
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Add the imath module
If you want inspiration: https://github.com/sagemath/sage/blob/master/src/sage/arith/misc.py ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
On 2018-06-21 11:00, INADA Naoki wrote: When Python 4, I think we can even throw away classmethod and staticmethod object. PyFunction can have binding flag instead, like METH_CLASS and METH_STATIC for PyCFunction. classmethod and staticmethod is just a function which modify the flag. One issue with that idea is that staticmethod, classmethod can actually arbitrary objects, not only Python functions. In fact, even this object can be created: >>> staticmethod(42) So in that sense, they behave more like "method" which can also wrap arbitrary callables (in this case, callability is checked). So I'm vaguely thinking of putting "method", "staticmethod" and "classmethod" on top of a common base class for things wrapping callables. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
On 2018-06-21 10:33, Serhiy Storchaka wrote: Status quo wins. Well, I'm already planning to make changes to staticmethod/classmethod (not right now, but it's on my post-PEP-580 roadmap). So the "status quo" argument doesn't apply. My question is really: assuming that we redesign staticmethod/classmethod anyway, should we make them callable? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] staticmethod and classmethod should be callable
On 2018-06-20 19:33, Serhiy Storchaka wrote: 20.06.18 12:56, Jeroen Demeyer пише: Are there any reasons to *not* make staticmethod and classmethod callable? There were no reasons to make staticmethod and classmethod callable. You have to compare the advantages of making them callable vs. the advantages of *not* making them callable. I think that consistency *is* good to have, so I consider that one reason to make them callable. Are there any reasons for *not* making them callable? ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] staticmethod and classmethod should be callable
While working on PEP 579 and friends, I noticed one oddity with classmethods: for Python classes, the object stored in the class __dict__ is of type "classmethod". For extension types, the type is "classmethod_descriptor". In turns out that the latter is callable itself, unlike staticmethod or classmethod instances: >>> fromhex = float.__dict__["fromhex"] >>> type(fromhex) >>> fromhex(float, "0xff") 255.0 >>> @classmethod ... def f(cls): pass >>> f(float) Traceback (most recent call last): File "", line 1, in TypeError: 'classmethod' object is not callable Since it makes sense to merge the classes "classmethod" and "classmethod_descriptor" (PEP 579, issue 8), one of the above behaviors should be changed. Given that adding features is less likely to break stuff, I would argue that classmethod instances should become callable. This would also make classmethod more analogous to function: you can see both "function" and "classmethod" as unbound methods. The only thing that is different is the binding behavior (binding to the instance vs. the class). Finally, function decorators typically turn functions into a different kind of callable. I find it counter-intuitive that @classmethod doesn't do that. And for consistency, also staticmethod instances should be callable. Are there any reasons to *not* make staticmethod and classmethod callable? Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] A PEP on introducing variables on 'if' and 'while'
On 2018-06-09 14:43, Juancarlo Añez wrote: Is there a guide about writing (and publishing) PEPs? https://www.python.org/dev/peps/pep-0001/ ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Meta-PEP about built-in functions
Hello, Both PEP 573 and PEP 575 deal with built-in functions. Additionally, some people (Stefan Behnel, Robert Bradshaw, Jim Pivarski and me) are currently brainstorming about a yet-to-be-written PEP to allow calling the underlying C function of a built-in function using native types (for example, a C long instead of a Python int). Think of it as analogous to the buffer protocol: the buffer protocol exposes C *data* while this would expose C *callables*. Since all these PEPs would overlap somewhat, I'm starting to wonder about the best way to organize this. Ideally, I would like some kind of "meta-PEP" where we discuss the future of built-in functions in general terms without too much details. This would be followed by several PEPs each going in detail about one specific aspect. Is there a precedent for this? What do the seasoned Python developers think? Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] __loader__.get_source(): semantics of returning None
On 2018-04-28 18:26, Paul Moore wrote: """ If a file named filename is not found, the function will look for it in the module search path, sys.path, after first checking for a PEP 302 __loader__ in module_globals, in case the module was imported from a zipfile or other non-filesystem import source. """ Sorry, I should have been more precise. linecache does the following (which is what is in the doc you quoted above): (1) Look for the filename exactly as given. (2) Look for a loader and call its get_source() method. (3) Look for the filename under all sys.path entries. The difference between (1) and (3) is when a relative filename is given, typically relative to site-packages. And I'm actually interested in that third case. So the question is really: should (3) still be tried if __loader__.get_source() returns None? Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] __loader__.get_source(): semantics of returning None
The documentation of __loader__.get_source() says "Returns None if no source is available (e.g. a built-in module)." But what does "no source is available" mean precisely? It could mean either of two things: (A) I am absolutely certain that there is no source anywhere to be found. (B) I don't know where to find the source, but if you look hard enough, you may find it. Currently, linecache interprets it as (A). Is there any chance that we can either change the interpretation for returning None to (B) or to provide an officially documented way to answer (B)? This could be using a new return value (say, NotImplemented) or by not implementing get_source at all (such that __loader__.get_source raises AttributeError). The latter is probably how things already work in practice, but it isn't really documented that way. The context for this question/proposal is https://bugs.python.org/issue32797 When the linecache module is asked for the source code of a certain file, it queries the __loader__.get_source() for the source code. If this returns None, that's the end: no source is returned. However, linecache is also passed the filename! So even if it could find the source by filename, it won't even try that if get_source() returns None. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] Change magic strings to enums
On 2018-04-25 09:57, Ivan Levkivskyi wrote: In the latter case rewriting EnumMeta in C ... or Cython. It's a great language and I'm sure that the Python standard library could benefit a lot from it. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP draft: Unifying function/method classes
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://github.com/jdemeyer/PEP-functions#replacing-tp_call-meth_arg0_function And it's very difficult to estimate runtime and maintenance cost of the PEP, without draft implementation. Runtime cost: the goal is no slowdowns at all. Maintenance cost: IMHO, this PEP simplifies functions in CPython by removing special classes like method_descriptor so the effect should only be in the good sense. FASTCALL is introduced in recently version, and it make implementation complicated. I'm afraid that this PEP make it worse. What do you mean? I am not making any changes to METH_FASTCALL. I only mention it in my PEP to document it. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP draft: Unifying function/method classes
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 objects. Sourcefile is meaningless when there is no source file. This is motivated by Cython, in which case there *is* a genuine and useful source file. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP draft: Unifying function/method classes
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 easier said than done. How would you do that? The problem is that multiple classes are involved, at least "builtin_function_or_method" and "method_descriptor". So you'll end up with at least 3 classes (those 2 plus the existing "function") supporting introspection. With my proposal, this is implemented only once. And do you expect users to implement those hooks or do you expect Python to do it? If you want to do it in Python, you'll need to add a new class anyway. That doesn't look simpler than my PEP. That being said, if there is a general consensus that this is the right thing to do, I'll go for it. However, I'm afraid that people will complain that I'm complicating functions in Python even more. Second: while introspection was the initial motivation, it does make sense to unify built-in functions and Python functions. For example: why are unbound methods just functions in Python classes but not in extension types? If you are going to do some reorganization of function classes anyway, you might as well do it properly. I claim that functions will be *easier* to work with in Python when my PEP is accepted, both for the end user as well as for the implementor of custom function classes. 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 bit faster, I don't think that's a good enough reason. I didn't really mean "isinstance" literally, I was mostly thinking of the C API. I agree that it's not clear. Do you happen to know why the existing function classes in Python disallow subclassing? I assumed that it was for exactly this reason. Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP draft: Unifying function/method classes
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 mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP proposal: unifying function/method classes
Dear Nick Coghlan, First of all, thanks for your insightful comments! On 2018-03-24 09:09, Nick Coghlan wrote: As Antoine notes, unifying user-defined functions and builtin functions would be fraught with backwards compatibility problems, so you probably don't want to go down that path when your goal is "Let third parties define types that are recognised by the core interpreter as being user-defined functions". First of all, my post was mainly meant to get an answer to "is this idea PEP-able?". I have never written a PEP and PEP 1 recommends this step. So it's not clear whether you want to say "that potential PEP is a bad idea" or just "go ahead with your PEP but be aware of backwards compatibility issues". It would be good to know what your backwards compatibility worries are. If I have a clearer idea of what could break, it would be easier to see if it's possible to not break that. Anyway, many (not all though!) backwards compatibility issues could be fixed by keeping the current built-in functions as a distinct type (say, old_style_builtin although I wouldn't use that name). My vague plan in the PEP is to introduce a base class "basefunction" and have old_style_builtin and Python functions be subclasses of that. Cython functions would then be another subclass. That way, we could implement "basefunction" properly and then implement old_style_builtin to support things like __get__ not binding as a method. If it was just about introspection, then we could define a new protocol method or attribute, update the inspect module to respect it, and call it done. True. In fact, I got a long way by just defining inspect.isfunction as def isfunction(obj): return hasattr(type(obj), "__code__") However, it seems to me that the most plausible path towards granting Cython access to the optimised fast paths for native functions would be setting Py_TPFLAGS_BASETYPE on types.FunctionType Why FunctionType and not BuiltinFunctionType? That's really the problem here: I want a function which is as fast as a built-in function but which behaves from a user's point of view as a Python function. We can't introduce a new protocol into those paths without slowing them down I don't really follow you here. Are you saying that it's impossible to allow custom function classes that are as fast as the current builtin functions? Instead of adding a flag for a subclass, we could add a flag for "can be called as if it is a built-in function". Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
Re: [Python-ideas] PEP proposal: unifying function/method classes
On 2018-03-23 00:36, Antoine Pitrou wrote: It does make sense, since the proposal sounds ambitious (and perhaps impossible without breaking compatibility). Well, *some* breakage of backwards compatibility will be unavoidable. My plan (just a plan for now!) is to preserve backwards compatibility in the following ways: * Existing Python attributes of functions/methods should continue to exist and behave the same * The inspect module should give the same results as now (by changing the implementation of some of the functions in inspect to match the new classes) * Everything from the documented Python/C API. This means that I might break compatibility in the following ways: * Changing the classes of functions/methods (this is the whole point of this PEP). So anything involving isinstance() checks might break. * The undocumented parts of the Python/C API, in particular the C structure. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] PEP proposal: unifying function/method classes
Dear python-ideas, I would like to draft a PEP to change the implementation of functions and methods in CPython. The idea for this PEP come from a discussion on https://bugs.python.org/issue30071 The core idea of the PEP is to reorganize classes for functions and methods with the goal of removing the difference between functions/methods implemented in C and functions/methods implemented in Python. Currently, CPython has two different function classes: the first is Python functions, which is what you get when defining a function with def or lambda. The second is built-in functions such as len, isinstance or numpy.dot. These are implemented in C. These two classes are completely independent with different functionality. For example, built-in functions do not have __get__ and therefore cannot be used as methods. And only Python functions support introspection like inspect.getargspec or inspect.getsourcefile. This is a problem for projects like Cython that want to implement functions in C but still want to offer functionality close to Python functions. In Cython, this was solved by inventing a new function class called cyfunction. Unfortunately, this new function class creates problems, for example the inspect module does not recognize such functions as being functions (this is the bug mentioned above) and the performance is worse (CPython has specific optimizations for calling built-in functions). When you look at methods, the inconsistency increases: On the one hand, the implementation of built-in functions and bound methods is very similar but built-in unbound methods are different. On the other hand, Python functions and unbound methods are identical but bound methods are different. Do you think that it makes sense to propose a PEP for this? Jeroen. ___ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
