Hi Just wondering if PyPy error messages are or could be of a higher quality than the CPython error messages? One of the goals of Rubinius a former Ruby alternate implementation similar in intent to PyPy was improved developer feedback in error messages. Is this an area of opportunity for PyPy? Cheers Sayth
I personally think it's fine: 1. CPython has pretty decent error messages. Other than long stack traces with recursion errors, or maybe column offsets, there isn't really anything that could be significantly improved. 2. Changing the actual errors would likely break...a *lot*! -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Apr 26, 2016 4:54 AM, "Sayth Renshaw" <flebber.crue@gmail.com> wrote:
Hi all, Some points: - in a couple of places pypy has better error messages than cpython, eg around calling functions with the wrong number of arguments, in complex cases. - we are certainly open to patches that improve the quality of our error messages, if that can be done with reasonable effort. - PyPy does not guarantee the same error messages as cpython, and it's a bug to rely on them. Cheers, Carl Friedrich On April 26, 2016 5:16:29 PM GMT+02:00, Ryan Gonzalez <rymg19@gmail.com> wrote:
Thanks for the feedback, just wondering really what the potential was. I sort of wish Ryan you hadn't used the word 'fine' its just a word that usually indicates something really needs to be done abs i had better shut up or its me; or it's about to break. Cheers Sayth On Wed, 27 Apr 2016 1:22 am Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
On Tue, Apr 26, 2016 at 10:16:29AM -0500, Ryan Gonzalez wrote:
Well, I don't know about that... some of the error messages are a bit uninformative ("SyntaxError: invalid syntax", although it may be difficult to do much about that one). But potential improvements should be taken on a case-by-case basis.
2. Changing the actual errors would likely break...a *lot*!
Do you mean the exception types? Yes, changing the exception types would break a lot of code. But changing the error messages shouldn't break anything, since the error messages are not part of the function API. They've changed before, and they will change again. -- Steve
On Tue, Apr 26, 2016 at 06:16:39PM +0200, Maciej Fijalkowski wrote:
Do you mean that PyPy might change ValueError to TypeError, or vice versa? Like this: # TypeError in CPython len(None) => raises ValueError # ValueError in CPython [].index("a") => raises TypeError That doesn't sound good to me. If I have misunderstood you, and you're just talking about the error strings, then that's fine. -- Steve
Not in *those* cases, but there are cases where CPython would raise different error classes depending e.g. on whether stuff is builtin function or not builtin function or the cpython errors are inconsistent. In those cases the exact error might be a bit different (I must admit I don't remember examples off hand) On Tue, Apr 26, 2016 at 6:38 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Those are simple cases, of course we use the same exception types there. However, if you write exactly the wrong obscure code you sometimes get a different exception type under some conditions. If you report them and they are easily fixable, we will. Carl Friedrich On April 26, 2016 6:38:31 PM GMT+02:00, Steven D'Aprano <steve@pearwood.info> wrote:
Hi, On 26 April 2016 at 19:02, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
That's about TypeError versus AttributeError for some attributes of built-in types in corner cases. That's not about ValueError. For example:
def f(): pass del f.__closure__
You get a TypeError in CPython, but an AttributeError in PyPy. That's because PyPy doesn't have the same zoo of built-in attribute types of CPython. For most purposes it doesn't make a difference, but it turns out that in this case half of these types raise AttributeError and the other half raises TypeError in CPython. A bientôt, Armin.
I personally think it's fine: 1. CPython has pretty decent error messages. Other than long stack traces with recursion errors, or maybe column offsets, there isn't really anything that could be significantly improved. 2. Changing the actual errors would likely break...a *lot*! -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Apr 26, 2016 4:54 AM, "Sayth Renshaw" <flebber.crue@gmail.com> wrote:
Hi all, Some points: - in a couple of places pypy has better error messages than cpython, eg around calling functions with the wrong number of arguments, in complex cases. - we are certainly open to patches that improve the quality of our error messages, if that can be done with reasonable effort. - PyPy does not guarantee the same error messages as cpython, and it's a bug to rely on them. Cheers, Carl Friedrich On April 26, 2016 5:16:29 PM GMT+02:00, Ryan Gonzalez <rymg19@gmail.com> wrote:
Thanks for the feedback, just wondering really what the potential was. I sort of wish Ryan you hadn't used the word 'fine' its just a word that usually indicates something really needs to be done abs i had better shut up or its me; or it's about to break. Cheers Sayth On Wed, 27 Apr 2016 1:22 am Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
On Tue, Apr 26, 2016 at 10:16:29AM -0500, Ryan Gonzalez wrote:
Well, I don't know about that... some of the error messages are a bit uninformative ("SyntaxError: invalid syntax", although it may be difficult to do much about that one). But potential improvements should be taken on a case-by-case basis.
2. Changing the actual errors would likely break...a *lot*!
Do you mean the exception types? Yes, changing the exception types would break a lot of code. But changing the error messages shouldn't break anything, since the error messages are not part of the function API. They've changed before, and they will change again. -- Steve
On Tue, Apr 26, 2016 at 06:16:39PM +0200, Maciej Fijalkowski wrote:
Do you mean that PyPy might change ValueError to TypeError, or vice versa? Like this: # TypeError in CPython len(None) => raises ValueError # ValueError in CPython [].index("a") => raises TypeError That doesn't sound good to me. If I have misunderstood you, and you're just talking about the error strings, then that's fine. -- Steve
Not in *those* cases, but there are cases where CPython would raise different error classes depending e.g. on whether stuff is builtin function or not builtin function or the cpython errors are inconsistent. In those cases the exact error might be a bit different (I must admit I don't remember examples off hand) On Tue, Apr 26, 2016 at 6:38 PM, Steven D'Aprano <steve@pearwood.info> wrote:
Those are simple cases, of course we use the same exception types there. However, if you write exactly the wrong obscure code you sometimes get a different exception type under some conditions. If you report them and they are easily fixable, we will. Carl Friedrich On April 26, 2016 6:38:31 PM GMT+02:00, Steven D'Aprano <steve@pearwood.info> wrote:
Hi, On 26 April 2016 at 19:02, Carl Friedrich Bolz <cfbolz@gmx.de> wrote:
That's about TypeError versus AttributeError for some attributes of built-in types in corner cases. That's not about ValueError. For example:
def f(): pass del f.__closure__
You get a TypeError in CPython, but an AttributeError in PyPy. That's because PyPy doesn't have the same zoo of built-in attribute types of CPython. For most purposes it doesn't make a difference, but it turns out that in this case half of these types raise AttributeError and the other half raises TypeError in CPython. A bientôt, Armin.
participants (6)
-
Armin Rigo -
Carl Friedrich Bolz -
Maciej Fijalkowski -
Ryan Gonzalez -
Sayth Renshaw -
Steven D'Aprano