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 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

Re: What to use for finding as many syntax errors as possible.

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,

RE: What to use for finding as many syntax errors as possible.

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 by line (or "statement" or "expression", ...)

RE: What to use for finding as many syntax errors as possible.

Cameron, or OP if you prefer, I think by now you have seen a suggestion that languages make choices and highly structured ones can be easier to "recover" from errors and try to continue than some with way more complex possibilities that look rather unstructured. What is the error in code like

Re: What to use for finding as many syntax errors as possible.

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

RE: What to use for finding as many syntax errors as possible.

Michael, A reasonable question. Python lets you initialize variables but has no explicit declarations. Languages differ and I juggle attributes of many in my mind and am reacting to the original question NOT about whether and how Python should report many possible errors all at once but how ANY

Re: What to use for finding as many syntax errors as possible.

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

Re: What to use for finding as many syntax errors as possible.

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

Re: What to use for finding as many syntax errors as possible.

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

Help, PyCharm fails to recognize my tab setting...See attached picture of the code.

C:\Users\kevin\PycharmProjects\Myfuturevalue\venv\Scripts\python.exe C:\Users\kevin\PycharmProjects\Myfuturevalue\FutureValueCal.py   File "C:\Users\kevin\PycharmProjects\Myfuturevalue\FutureValueCal.py", line 31    elif (years > 50.0) or (years < 1.0) :    ^IndentationError: expected an

Re: What to use for finding as many syntax errors as possible.

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

Re: for -- else: what was the motivation?

On 09/10/2022 15.02, Peter J. Holzer wrote: On 2022-10-09 15:32:13 -0400, Avi Gross wrote: and of course no pipelines. Since you've now used that term repeatedly: What is a pipeline in Python? Could it be what's discussed starting on page 35 of this presentation?

Re: What to use for finding as many syntax errors as possible.

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? --

Re: What to use for finding as many syntax errors as possible.

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

Re: for -- else: what was the motivation?

Axy wrote: >> Also not really a justification for "shortest block first". Wanting >> some elaboration on that. What's the value in it? > > Well, the value is productivity. No need to save puzzles "what this > hanging else belongs to?" If you find yourself asking that question, the if-block is

Re: for -- else: what was the motivation?

On Tue, 11 Oct 2022 at 08:55, Robert Latest via Python-list wrote: > > Chris Angelico wrote: > > Yes, I'm aware that code readability becomes irrelevant for > > short-duration projects. Beside the point. I'm wondering how important > > it really is to have the shortest block first. > > I usually

Re: What to use for finding as many syntax errors as possible.

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

Re: What to use for finding as many syntax errors as possible.

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

Re: for -- else: what was the motivation?

Grant Edwards wrote: > I've followed that advice for several decades. I find it much easier > to read code that's organized that way -- particularly when the > difference in block sizes is large (e.g. the first block is one line, > and the second is a a hundred). If any conditionally executed

Re: for -- else: what was the motivation?

Axy 在 2022年10月10日 星期一下午5:55:29 [UTC+8] 的信中寫道： > On 09/10/2022 03:33, Jach Feng wrote: > > The else is always coming with the break, not the for. > However, the compiler does not complain. Sure, the compiler will not complain even in a IOCCC contest:-) > > but the [for...else] is insane. > Not

Re: for -- else: what was the motivation?

Chris Angelico wrote: > Yes, I'm aware that code readability becomes irrelevant for > short-duration projects. Beside the point. I'm wondering how important > it really is to have the shortest block first. I usually put the most expected / frequent / not negated block first if the whole if/else

Re: for -- else: what was the motivation?

On 2022-10-10, Calvin Spealman wrote: > On Sat, Oct 8, 2022 at 5:35 PM rbowman wrote: >> On 10/7/22 21:32, Axy wrote: >> > So, seriously, why they needed else if the following pieces produce same >> > result? Does anyone know or remember their motivation? >> >> In real scenarios there would be

RE: for -- else: what was the motivation?

I just want to get clear on what may be a side issue The suggestion is that a loop with an ELSE clause only makes sense if the user can BREAK out without finishing, right? My first question is whether a warning or even error makes sense if there is no BREAK statement anywhere in the loop but

Re: What to use for finding as many syntax errors as possible.

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

Re: What to use for finding as many syntax errors as possible.

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

Re: for -- else: what was the motivation?

On 2022-10-09 22:38:28 -0400, avi.e.gr...@gmail.com wrote: > [This is an answer for Peter and can easily be skipped by those who know or > have no wish to.] > > Strictly speaking Peter, the word "pipe" may not mean quite something in > Python but other concepts like chaining may be better. > >

Re: for -- else: what was the motivation?

On 2022-10-10 12:40:44 +1300, dn wrote: > On 10/10/2022 05.56, Peter J. Holzer wrote: > > On 2022-10-09 12:18:09 -0400, Avi Gross wrote: > > > Some would argue for a rule related to efficiency of execution. When you > > > have multiple blocks as in an if-else or case statement with multiple > > >

Re: for -- else: what was the motivation?

On 10/10/2022 19:25, Weatherby,Gerard wrote: pylint, at least, provides a warning: fe.py:4:0: W0120: Else clause on loop without a break statement (useless-else-on-loop) I'm using flake8, it does not, alas. Axy. -- https://mail.python.org/mailman/listinfo/python-list

Re: for -- else: what was the motivation?

pylint, at least, provides a warning: fe.py:4:0: W0120: Else clause on loop without a break statement (useless-else-on-loop) sum = 0 for i in range(5): sum += i else: print("Always executes") print(sum) From: Python-list on behalf of Axy via Python-list Date: Monday, October 10,

Re: for -- else: what was the motivation?

On 10/10/2022 15:52, Weatherby,Gerard wrote: I wonder if for/else could have been less confusing if it was referred to as for-break-else and if the else clause was only valid syntax if the for loop actually contained a break statement in the first place. Sounds reasonable. It would be

Re: for -- else: what was the motivation?

On 10/10/2022 15:52, Weatherby,Gerard wrote: Core developer Raymond Hettinger explains the history starting at 15:40 https://www.youtube.com/watch?v=OSGv2VnC0go (which I found on stackoverflow https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops )

Re: for -- else: what was the motivation?

Core developer Raymond Hettinger explains the history starting at 15:40 https://www.youtube.com/watch?v=OSGv2VnC0go (which I found on stackoverflow https://stackoverflow.com/questions/9979970/why-does-python-use-else-after-for-and-while-loops ) TL:DR The “else” is a historical artificial from

Re: for -- else: what was the motivation?

On Sat, Oct 8, 2022 at 5:35 PM rbowman wrote: > On 10/7/22 21:32, Axy wrote: > > So, seriously, why they needed else if the following pieces produce same > > result? Does anyone know or remember their motivation? > > In real scenarios there would be more logic in the for block that would > meet

Re: for -- else: what was the motivation?

try: open(disk) except: error(“Can’t open disk”) lots of things From: Python-list on behalf of Karsten Hilbert Date: Monday, October 10, 2022 at 5:46 AM To: python-list@python.org Subject: Re: for -- else: what was the motivation? *** Attention: This is an

Re: for -- else: what was the motivation?

On 2022-10-10, Chris Angelico wrote: > On Mon, 10 Oct 2022 at 11:52, MRAB wrote: >> >> On 2022-10-10 00:40, dn wrote: >> > On Sun, 9 Oct 2022 at 15:39, Axy via Python-list >> > wrote: >> > >> >> "shortest block first" >> > >> > Have never heard this advice before. Kind-of rankled with me, as it

[Python-announce] Re: Cheetah 3.3.0

Hello! I'm pleased to announce version 3.3.0, the 1st release of branch 3.3 of CheetahTemplate3. What's new in CheetahTemplate3 == The contributors for this release are: N Protokowicz, Enzo Conty, Andrea Mennucci, Saiprasad Kale, odidev, Pierre Ossman. Many thanks!

Re: for -- else: what was the motivation?

On Mon, 10 Oct 2022 at 22:37, Axy via Python-list wrote: > > > On 10/10/2022 12:24, Chris Angelico wrote: > > On Mon, 10 Oct 2022 at 21:57, Axy via Python-list > > wrote: > >> > >>> Not sure what you mean, but a for-else without a break is quite > >>> useless. What exactly ARE you arguing here?

Re: for -- else: what was the motivation?

On 10/10/2022 12:24, Chris Angelico wrote: On Mon, 10 Oct 2022 at 21:57, Axy via Python-list wrote: Not sure what you mean, but a for-else without a break is quite useless. What exactly ARE you arguing here? The else is associated with the break to the exact extent that one is essential

Re: for -- else: what was the motivation?

On Mon, 10 Oct 2022 at 21:57, Axy via Python-list wrote: > > > > Not sure what you mean, but a for-else without a break is quite > > useless. What exactly ARE you arguing here? > > > > The else is associated with the break to the exact extent that one is > > essential to the other's value. > >

Re: Cheetah 3.3.0

Hello! I'm pleased to announce version 3.3.0, the 1st release of branch 3.3 of CheetahTemplate3. What's new in CheetahTemplate3 == The contributors for this release are: N Protokowicz, Enzo Conty, Andrea Mennucci, Saiprasad Kale, odidev, Pierre Ossman. Many thanks!

Re: for -- else: what was the motivation?

Not sure what you mean, but a for-else without a break is quite useless. What exactly ARE you arguing here? The else is associated with the break to the exact extent that one is essential to the other's value. I'm not arguing. That was just for the record, how things are done in Python.

Re: for -- else: what was the motivation?

On Mon, 10 Oct 2022 at 20:56, Axy via Python-list wrote: > > > The else is always coming with the break, not the for. > However, the compiler does not complain. > > There are [for ...], [for...break...], and[for...break...else], > > That's implied and contradicts Zen of Python, I think. If

Re: for -- else: what was the motivation?

On Mon, 10 Oct 2022 at 20:46, Karsten Hilbert wrote: > > Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram: > > > I often follow this rule. For me, it's about readability. Compare: > > > > if not open( disk ): > > error( "Can't open disk" ) > > else: > > printf( "now imagine

Re: for -- else: what was the motivation?

On 09/10/2022 03:33, Jach Feng wrote: Axy 在 2022年10月8日 星期� �上午11:39:44 [UTC+8] 的信中寫道： Hi there, this is rather a philosophical question, but I assume I miss something. I don't remember I ever used else clause for years I was with python and my expectation was it executed only if the the main

Re: for -- else: what was the motivation?

Am Sun, Oct 09, 2022 at 09:58:14AM + schrieb Stefan Ram: > I often follow this rule. For me, it's about readability. Compare: > > if not open( disk ): > error( "Can't open disk" ) > else: > printf( "now imagine there's some larger block here" ) ... ad infinitum

Re: What to use for finding as many syntax errors as possible.

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

Re: What to use for finding as many syntax errors as possible.

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

Re: for -- else: what was the motivation?

Axy 在 2022年10月8日 星期六上午11:39:44 [UTC+8] 的信中寫道： > Hi there, > > this is rather a philosophical question, but I assume I miss something. > I don't remember I ever used else clause for years I was with python and > my expectation was it executed only if the the main body was never run. > Ha-ha! I

Re: for -- else: what was the motivation?

On 10/8/22 22:37, Axy wrote: Python is awesome because it's semantic is clear for the majority, but there are places that look odd. In case of "for", "else" looks logically tied with "for" clause, but actually it is not. It's tied with "break" statement and I overlooked that even after

Re: Polot severa figures inside a for loopin

On Sun, 9 Oct 2022 09:27:55 +1100, Cameron Simpson declaimed the following: > >And what's IDL? Can you provide a URL to it? > Off hand, given the references to plots, and netcdf & 2D specifically... So a nearly

Re: What to use for finding as many syntax errors as possible.

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