[Python-Dev] Add more SyntaxWarnings?

[Steven D'Aprano]

At the cost of breaking threading a bit, I'm going to reply to a few 
different people in one post.

On Fri, Jan 25, 2019 at 09:52:53AM +1100, Chris Angelico wrote:
> On Fri, Jan 25, 2019 at 9:42 AM Steven D'Aprano <steve at pearwood.info> wrote:
> > We could say that implementations are allowed to raise errors at compile
> > time instead of run time, but aren't required to. Then it becomes a
> > matter of "quality of implementation".
[...]

> Does there need to be a new subclass of SyntaxError for "Technically
> Valid But Not Meaningful" problems? Is there value in distinguishing
> "InevitableTypeError" from "InevitableAttributeError"?

If we did this (which is looking less and less likely...) I would argue 
for plain old TypeError and AttributeError. There should be no 
difference in the exception raised, only in the timing (compile time 
versus run time).



On Thu, Jan 24, 2019 at 11:45:49PM +0000, Chris Barker wrote:
> I would love to see Python become generally more informative with 
> errors.
>
> In this case, you’d probably get a similar error, but it’s still nice 
> to get it sooner

That is precisely my thinking.



On Thu, Jan 24, 2019 at 03:24:41PM -0800, Guido van Rossum wrote:
> I'm -1 on all of these cases. There's nothing mysterious about e.g.
> `TypeError: unsupported operand type(s) for +: 'int' and 'str'`

Its not about the error being mysterious, its about raising the 
exception as early as possible. It shouldn't take 20 years to discover 
that this snippet buried deep in a large code base:

    if datetime.date.today().year == 2029:
        spam = 1 + '1'

will fail :-)



On Thu, Jan 24, 2019 at 03:58:50PM -0800, Guido van Rossum wrote:
> But I doubt we'll see much mileage out of the syntax checks.

Frankly, I agree, so I'm not going to argue hard for this. It was more 
speculation than a solid proposal.

A project manager I used to work with would have dismissed this as "turd 
polishing", but I prefer to think of it as "craftsmanship" -- a bit like 
a carpenter ensuring that his screws don't protrude above the surface of 
the wood. Sure, its not going to hold the wood together any better, but 
its just a nicer end-user experience :-)

I expect that the cost of implementing these checks would probably 
exceed the benefit of detecting the errors early, but I could be wrong. 
Maybe it would be easy to implement.

But if there is strong opposition to it, I'm not going to champion the 
idea any further.



-- 
Steve