On Sunday, October 9, 2022 at 12:09:45 PM UTC+2, Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible
> in a python file. I know there is the risk of false positives when a
> tool tries to recover from a syntax error and proceeds but I would
> prefer th
On 2022-10-11 14:11:56 -0400, Thomas Passin wrote:
> To bring things back to the context of the original post, actual web
> browsers are extremely tolerant of HTML syntax errors (including incorrect
> nesting of tags) in the documents they receive.
HTML5 actually specifies exactly how to recover f
On 2022-10-13 11:23:40 +1100, Chris Angelico wrote:
> On Thu, 13 Oct 2022 at 11:19, Peter J. Holzer wrote:
> > On 2022-10-11 09:47:52 +1100, Chris Angelico wrote:
> > > On Tue, 11 Oct 2022 at 09:18, Cameron Simpson wrote:
> > > >
> > > Consider:
> > >
> > > if condition # no colon
> > > code
On Thu, 13 Oct 2022 at 11:23, dn wrote:
> # add an extra character within identifier, as if 'new' identifier
> 28 assert expected_value == fyibonacci_number
> UUU
>
> # these all trivial SYNTAX errors - could have tried leaving-out a
> keyword,
On Thu, 13 Oct 2022 at 11:19, Peter J. Holzer wrote:
>
> On 2022-10-11 09:47:52 +1100, Chris Angelico wrote:
> > On Tue, 11 Oct 2022 at 09:18, Cameron Simpson wrote:
> > >
> > Consider:
> >
> > if condition # no colon
> > code
> > else:
> > code
> >
> > To actually "restart" parsing, you
On 09/10/2022 23.09, Antoon Pardon wrote:
I would like a tool that tries to find as many syntax errors as possible
in a python file. I know there is the risk of false positives when a
tool tries to recover from a syntax error and proceeds but I would
prefer that over the current python strategy
On 2022-10-11 09:47:52 +1100, Chris Angelico wrote:
> On Tue, 11 Oct 2022 at 09:18, Cameron Simpson wrote:
> >
> Consider:
>
> if condition # no colon
> code
> else:
> code
>
> To actually "restart" parsing, you have to make a guess of some sort.
Right. At least one of the papers on par
On 11Oct2022 17:45, Thomas Passin wrote:
Personally, I'd most likely go for a decent programming editor that you
can set up to run a program on your file, use that to run a checker,
like pyflakes for instance, and run that from time to time. You could
run it when you save a file. Even if it
On 10/11/2022 5:09 PM, Thomas Passin wrote:
The OP wants to get help with problems in
his files even if it isn't perfect, and I think that's reasonable to
wish for. The link to a post about the lezer parser in a recent message
on this thread is partly about how a real, practical parser can do
On 10/11/2022 4:00 PM, Chris Angelico wrote:
On Wed, 12 Oct 2022 at 05:23, Thomas Passin wrote:
On 10/11/2022 3:10 AM, avi.e.gr...@gmail.com wrote:
I see resemblances to something like how a web page is loaded and operated.
I mean very different but at some level not so much.
I mean a typica
On Wed, 12 Oct 2022 at 05:23, Thomas Passin wrote:
>
> On 10/11/2022 3:10 AM, avi.e.gr...@gmail.com wrote:
> > I see resemblances to something like how a web page is loaded and operated.
> > I mean very different but at some level not so much.
> >
> > I mean a typical web page is read in as HTML w
On 10/11/2022 3:10 AM, avi.e.gr...@gmail.com wrote:
I see resemblances to something like how a web page is loaded and operated.
I mean very different but at some level not so much.
I mean a typical web page is read in as HTML with various keyword regions
expected such as ... or ... with thin
On Tue, 11 Oct 2022 at 18:12, wrote:
>
> Thanks for a rather detailed explanation of some of what we have been
> discussing, Chris. The overall outline is about what I assumed was there but
> some of the details were, to put it politely, fuzzy.
>
> I see resemblances to something like how a web pa
thing with DirEntry fields /
methods
From: Python-list on
behalf of avi.e.gr...@gmail.com
Date: Monday, October 10, 2022 at 10:11 PM
To: python-list@python.org
Subject: RE: What to use for finding as many syntax errors as possible.
*** Attention: This is an external email. Use caution respondin
Op 10/10/2022 om 19:08 schreef Robert Latest via Python-list:
Antoon Pardon wrote:
I would like a tool that tries to find as many syntax errors as possible
in a python file.
I'm puzzled as to when such a tool would be needed. How many syntax errors can
you realistically put into a single Pyt
Op 10/10/2022 om 19:08 schreef Robert Latest via Python-list:
Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible
> in a python file.
I'm puzzled as to when such a tool would be needed. How many syntax errors can
you realistically put into a single P
f Of Chris Angelico
Sent: Monday, October 10, 2022 11:55 PM
To: python-list@python.org
Subject: Re: What to use for finding as many syntax errors as possible.
On Tue, 11 Oct 2022 at 14:26, wrote:
>
> I stand corrected Chris, and others, as I pay the sin tax.
>
> Yes, there are many kinds of
holding contradictions in my mind while accepting both and yet neither!
LOL!
-Original Message-
From: Python-list On
Behalf Of Chris Angelico
Sent: Monday, October 10, 2022 11:24 PM
To: python-list@python.org
Subject: Re: What to use for finding as many syntax errors as possible.
On Tue
On Tue, 11 Oct 2022 at 14:26, wrote:
>
> I stand corrected Chris, and others, as I pay the sin tax.
>
> Yes, there are many kinds of errors that logically fall into different
> categories or phases of evaluation of a program and some can be determined
> by a more static analysis almost on a line b
On Tue, 11 Oct 2022 at 14:13, wrote:
> With the internet today, we are used to expecting error correction to come
> for free. Do you really need one of every 8 bits to be a parity bit, which
> only catches may half of the errors...
Fortunately, we have WAY better schemes than simple parity, which
a language based on
more mathematical rules including more precisely what is syntax versus ...
Suggestions?
-Original Message-
From: Python-list On
Behalf Of Chris Angelico
Sent: Monday, October 10, 2022 10:42 PM
To: python-list@python.org
Subject: Re: What to use for finding as many
st places ...
-Original Message-
From: Python-list On
Behalf Of Cameron Simpson
Sent: Monday, October 10, 2022 6:17 PM
To: python-list@python.org
Subject: Re: What to use for finding as many syntax errors as possible.
On 11Oct2022 08:02, Chris Angelico wrote:
>There's a huge diff
On Tue, 11 Oct 2022 at 13:10, wrote:
> If the above is:
>
> Import grumpy as np
>
> Then what happens if the code tries to find a file named "grumpy" somewhere
> and cannot locate it and this is considered a syntax error rather than a
> run-time error for whatever reason? Can you continue when all
plain wrong!
And it will compile or be interpreted without complaint albeit not do
exactly what it is supposed to!
-Original Message-
From: Python-list On
Behalf Of Michael F. Stemper
Sent: Monday, October 10, 2022 9:22 AM
To: python-list@python.org
Subject: Re: What to use for find
On 10/10/2022 9:21 AM, Michael F. Stemper wrote:
On 09/10/2022 10.49, Avi Gross wrote:
Anton
There likely are such programs out there but are there universal
agreements
on how to figure out when a new safe zone of code starts where error
testing can begin?
For example a file full of function
On Tue, 11 Oct 2022 at 09:18, Cameron Simpson wrote:
>
> On 11Oct2022 08:02, Chris Angelico wrote:
> >There's a huge difference between non-fatal errors and syntactic
> >errors. The OP wants the parser to magically skip over a fundamental
> >syntactic error and still parse everything else correct
On 09/10/2022 10.49, Avi Gross wrote:
My guess is that finding 100 errors might turn out to be misleading.
If you
fix just the first, many others would go away. If you spell a variable name
wrong when declaring it, a dozen uses of the right name may cause errors.
Should you fix the first or chan
On 11Oct2022 08:02, Chris Angelico wrote:
There's a huge difference between non-fatal errors and syntactic
errors. The OP wants the parser to magically skip over a fundamental
syntactic error and still parse everything else correctly. That's
never going to work perfectly, and the OP is surprised
Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible
> in a python file.
I'm puzzled as to when such a tool would be needed. How many syntax errors can
you realistically put into a single Python file before compiling it for the
first time?
--
https://m
Michael F. Stemper wrote:
> How does one declare a variable in python? Sometimes it'd be nice to
> be able to have declarations and any undeclared variable be flagged.
To my knowledge, the closest to that is using __slots__ in class definitions.
Many a time have I assigned to misspelled class memb
wrote:
> Cameron,
>
> Your suggestion makes me shudder!
Me, too
> Removing all earlier lines of code is often guaranteed to generate errors as
> variables you are using are not declared or initiated, modules are not
> imported and so on.
all of which aren't syntax errors, so the method should s
On 09/10/2022 10.49, Avi Gross wrote:
Anton
There likely are such programs out there but are there universal agreements
on how to figure out when a new safe zone of code starts where error
testing can begin?
For example a file full of function definitions might find an error in
function 1 and t
On Tue, 11 Oct 2022 at 06:34, Peter J. Holzer wrote:
>
> On 2022-10-10 09:23:27 +1100, Chris Angelico wrote:
> > On Mon, 10 Oct 2022 at 06:50, Antoon Pardon wrote:
> > > I just want a parser that doesn't give up on encoutering the first syntax
> > > error. Maybe do some semantic checking like che
On 2022-10-10 09:23:27 +1100, Chris Angelico wrote:
> On Mon, 10 Oct 2022 at 06:50, Antoon Pardon wrote:
> > I just want a parser that doesn't give up on encoutering the first syntax
> > error. Maybe do some semantic checking like checking the number of
> > parameters.
>
> That doesn't make sens
On 10Oct2022 09:04, Antoon Pardon wrote:
It is easy to get the syntax right before submitting to such a
pipeline. I usually run a linter on my code for serious commits, and
I've got a `lint1` alias which basicly runs the short fast flavour of
that which does a syntax check and the very fast l
Op 10/10/2022 om 00:45 schreef Cameron Simpson:
On 09Oct2022 21:46, Antoon Pardon wrote:
Is it that onerous to fix one thing and run it again? It was once
when you
handed in punch cards and waited a day or on very busy machines.
Yes I find it onerous, especially since I have a pipeline wit
On 10Oct2022 00:41, avi.e.gr...@gmail.com wrote:
Your suggestion makes me shudder!
And fair enough too. I don't do this for me, I'm just suggesting an
approach which might bring something to Antoon's objective.
Removing all earlier lines of code is often guaranteed to generate errors as
va
l goal is to have a chance to detect and maybe fix a few things per round
rather than just one. Not a bad wish. Just not a trivial wish to grant and
satisfy.
-Original Message-
From: Python-list On
Behalf Of Cameron Simpson
Sent: Sunday, October 9, 2022 6:45 PM
To: python-list@python.org
Su
On 10/9/2022 1:29 PM, Peter J. Holzer wrote:
> On 2022-10-09 12:59:09 -0400, Thomas Passin wrote:
>>
https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
>>
>> People seemed especially enthusiastic about the one-liner from jmd_dk.
>
> I d
On 09Oct2022 21:46, Antoon Pardon wrote:
Is it that onerous to fix one thing and run it again? It was once when
you
handed in punch cards and waited a day or on very busy machines.
Yes I find it onerous, especially since I have a pipeline with unit tests
and other tools that all have to redo
On Mon, 10 Oct 2022 at 06:50, Antoon Pardon wrote:
> I just want a parser that doesn't give up on encoutering the first syntax
> error. Maybe do some semantic checking like checking the number of parameters.
That doesn't make sense though. It's one thing to keep going after
finding a non-syntacti
Am Sun, Oct 09, 2022 at 07:51:12PM +0200 schrieb Antoon Pardon:
> >But the point is: you can't (there is no way to) be sure the
> >9+ errors really are errors.
> >
> >Unless you further constrict what sorts of errors you are
> >looking for and what margin of error or leeway for false
> >positives
> On 9 Oct 2022, at 18:54, Antoon Pardon wrote:
>
>
>
> Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
>> Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
>>
>>> Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading.
Op 9/10/2022 om 21:44 schreef Avi Gross:
But an error like setting the size of a fixed length data structure to the
right size may result in oodles of errors about being out of range that
magically get fixed by one change. Sometimes too much info just gives you a
headache.
So? The user of su
On 2022-10-09 15:18:19 -0400, Avi Gross wrote:
> Antoon, it may also relate to an interpreter versus compiler issue.
>
> Something like a compiler for C does not do anything except write code in
> an assembly language. It can choose to keep going after an error and start
> looking some more from
Op 9/10/2022 om 21:18 schreef Avi Gross:
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less stab
Op 9/10/2022 om 21:18 schreef Avi Gross:
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less stab
I will say that those of us meaning me, who express reservations are not
arguing it is a bad idea to get more info in one sweep. Many errors come in
bunches.
If I keep calling some function with the wrong number or type of arguments,
it may be the same in a dozen places in my code. The first erro
Antoon, it may also relate to an interpreter versus compiler issue.
Something like a compiler for C does not do anything except write code in
an assembly language. It can choose to keep going after an error and start
looking some more from a less stable place.
Interpreters for Python have to cat
On 2022-10-09 18:51, Antoon Pardon wrote:
Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, m
: What to use for finding as many syntax errors as possible.
*** Attention: This is an external email. Use caution responding, opening
attachments or clicking on links. ***
I would like a tool that tries to find as many syntax errors as possible
in a python file. I know there is the risk of false
Op 9/10/2022 om 19:23 schreef Karsten Hilbert:
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, many others would go away.
At this moment
On 2022-10-09 19:23:41 +0200, Karsten Hilbert wrote:
> Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
> > Op 9/10/2022 om 17:49 schreef Avi Gross:
> > >My guess is that finding 100 errors might turn out to be misleading. If you
> > >fix just the first, many others would go away.
>
On 2022-10-09 12:59:09 -0400, Thomas Passin wrote:
> https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
>
> People seemed especially enthusiastic about the one-liner from jmd_dk.
I don't think that one-liner solves Antoon's requirement of
Am Sun, Oct 09, 2022 at 06:59:36PM +0200 schrieb Antoon Pardon:
> Op 9/10/2022 om 17:49 schreef Avi Gross:
> >My guess is that finding 100 errors might turn out to be misleading. If you
> >fix just the first, many others would go away.
>
> At this moment I would prefer a tool that reported 100 err
https://stackoverflow.com/questions/4284313/how-can-i-check-the-syntax-of-python-script-without-executing-it
People seemed especially enthusiastic about the one-liner from jmd_dk.
On 10/9/2022 12:17 PM, Peter J. Holzer wrote:
On 2022-10-09 12:09:17 +0200, Antoon Pardon wrote:
I would like a to
Op 9/10/2022 om 17:49 schreef Avi Gross:
My guess is that finding 100 errors might turn out to be misleading. If you
fix just the first, many others would go away.
At this moment I would prefer a tool that reported 100 errors, which would
allow me to easily correct 10 real errors, over the p
On 2022-10-09 12:09:17 +0200, Antoon Pardon wrote:
> I would like a tool that tries to find as many syntax errors as possible in
> a python file. I know there is the risk of false positives when a tool tries
> to recover from a syntax error and proceeds but I would prefer that over the
> current py
Anton
There likely are such programs out there but are there universal agreements
on how to figure out when a new safe zone of code starts where error
testing can begin?
For example a file full of function definitions might find an error in
function 1 and try to find the end of that function and
I would like a tool that tries to find as many syntax errors as possible
in a python file. I know there is the risk of false positives when a
tool tries to recover from a syntax error and proceeds but I would
prefer that over the current python strategy of quiting after the first
syntax error.
60 matches
Mail list logo
