Python needs better error reporting

[Opus]

I would normally support a more verbose parser for a language.  I fully believe 
that if the thing can tell you there is an error, it should be able to show 
some proof, and help you out.  This being said, the fact that this is not a 
compiled language (it still needs to read the source file to make sure it is up 
to date), a verbose parser would slow it down.

At the most, I might suggest that there be an option to run just the parser, 
with more verbose output.  Maybe even a different parser would be in order.  
Idea for anyone????

True, the language definition of Python is nice and clean, it would be nice to 
see a pre-parser written for it, in it.  If it passes, it could even call 
Python to write out a .pyc file.  Maybe even an option for the parser to spot 
bad-practice code.  I.E. Is is faster to call 'var += 1' or 'var = var + 1'.

Maybe even one that gives you O analysis of your code.  That would be really 
nice.  Could not only play with some code to opomize speed before you use it.

On 30 Jun 2002 at 0:11, James J. Besemer wrote:

> 
> I rather think Dave has a good point.
> 
> A better parser could give a more informative diagnostic in this case and I
> suspect others.
> 
> Tim Peters wrote:
> 
> > Well, "xor" isn't legit there, but other tokens that are OK after
> >
> >     if s == ' '
> >
> > include
> >
> >    [a ong list]
> 
> The question is NOT be what all may follow the string literal.  Rather it should
> be what tokens are legal between the string literal and end of line?  Very
> different questions.
> 
> If I'm not mistaken, only ":" or "\" are legal in that narrow context.  While
> additional tokens may be legal in terms of following the string literal, they
> still result in an error, so there's no point in listing them.  Line
> continuation is a special case all its own.  Either it's illegal for some
> reason, in which that situation constitutes a diagnostic all its own.  Otherwise
> it can be completely ignored, as any errors/diagnostics would involve the next
> following token, not the line continuation itself.
> 
> So it would be perfectly reasonable for the parser to say "semicolon missing" or
> "semicolon expected" in this case.
> 
> Whether or not it's worth the effort to implement is, as always, debatable and
> furthermore, I suppose, moot unless somebody is offering to do the work.
> 
> Regards
> 
> --jb
> 
> --
> James J. Besemer  503-280-0838 voice
> http://cascade-sys.com  503-280-0375 fax
> mailto:jb at cascade-sys.com
> 
> 
> 
> 
> -- 
> http://mail.python.org/mailman/listinfo/python-list


--Opus--

You can't tell me what sucks!
                            - Beavis, a true Objectivist.

--------------------------------------------------------
Get added to my Humor list:
mailto:opus at value.net?subject=ADD_HUMOR
Get added to my Neat list:
mailto:opus at value.net?subject=ADD_NEAT
Get my PGP public key:
mailto:opus at value.net?subject=PSEND&body=send%20PublicKEY.asc
Visit My Home Page:
http://value.net/~opus/