Re: wsywig json editor?
On Thu, 2026-02-19 at 12:51 -0800, Jordan Brown wrote:
Did not include the Python program.
oops...
Changed it slightly to reflect the name and usage.
And of course the Windows folks will have to make it an executable and
perhaps chamge the name.
No idea what the Mac guys will have to do.
L
Looks plausible. I'd consider the exception handling to be somewhat
wrong, but it shouldn't be a problem in ordinary use.
On Thu, 2026-02-19 at 13:23 -0800, Jordan Brown via Discuss wrote:
Looks plausible. I'd consider the exception handling to be somewhat
wrong, but it shouldn't be a problem in ordinary use.
Not being at all fluent in Python, I wouldn't have known what to look
for.
I can often modify a python program, as I did with Move-STL-to-origin
https://github.com/lar3ry/OpenSCAD---Move-STL-to-origin
but I never have written anything in it from scratch
BTW, your posts are coming out with text in black.
L
On Thu, 2026-02-19 at 13:23 -0800, Jordan Brown via Discuss wrote:
Looks plausible. I'd consider the exception handling to be somewhat
wrong, but it shouldn't be a problem in ordinary use.
Not being at all fluent in Python, I wouldn't have known what to look
for.
I can often modify a python program, as I did with Move-STL-to-origin
https://github.com/lar3ry/OpenSCAD---Move-STL-to-origin
but I never have written anything in it from scratch
BTW, your posts are coming out with text in black.
L
On 2/19/2026 2:21 PM, larry wrote:
On Thu, 2026-02-19 at 13:23 -0800, Jordan Brown via Discuss wrote:
Looks plausible. I'd consider the exception handling to be somewhat
wrong, but it shouldn't be a problem in ordinary use.
Not being at all fluent in Python, I wouldn't have known what to look for.
I can often modify a python program, as I did with Move-STL-to-origin
https://github.com/lar3ry/OpenSCAD---Move-STL-to-origin
https://github.com/lar3ry/OpenSCAD---Move-STL-to-origin
but I never have written anything in it from scratch
It's actually two anti-patterns that are pretty common in all languages
that have exceptions:
- The try-catch for FileNotFoundError is too big. It covers not just
the open of the input file but a lot of other stuff, notably
including the open of the output file. If you give it an output
file with a directory that didn't exist, I suspect that it will
complain that the input file isn't found. try-catches intended to
catch particular problems should be wrapped as tightly as possible
around the point where the problem occurs, so that they won't
accidentally catch unexpected instances of that failure. - The try-catch for Exception shouldn't be there at all. Other than
problems opening files, there shouldn't be any exceptions. An
exception indicates a bug. If the program had a bug, the handling
here would say (for instance) that "key" is not defined... but will
not tell you what line the failure happened on. In a program this
small the error alone might be enough to find the problem, but in a
more complex program it won't be. There is an attitude that says
that programs should never let an exception make it all the way to
the default "dump a stack trace" handling. I think that attitude is
deeply misguided; it means that when there is a bug it will be
difficult to diagnose. Particularly bad examples might lead to the
program silently doing something damaging.
There should be a try-catch wrapped tightly around the open-for-write,
and I expect that the try-catch wrapped around the open-for-read should
catch more than just FileNotFoundError; it should catch, e.g.,
permission errors. Similarly for the try-catch wrapped around the
open-for-write.
But as I said, none of that should be an issue in ordinary use.
BTW, your posts are coming out with text in black.
Uh... yes? That's certainly the way they are on my screen, because
that's the way I have it configured, but I just looked and they don't
specify any colors; you should be getting whatever your configured
default is for HTML messages. (Or for plain-text, if your mail program
is configured to prefer the plain-text copy of the message.)
On Thu, 2026-02-19 at 18:47 -0800, Jordan Brown wrote:
On 2/19/2026 2:21 PM, larry wrote:
On Thu, 2026-02-19 at 13:23 -0800, Jordan Brown via Discuss wrote:
Looks plausible. I'd consider the exception handling to be
somewhat wrong, but it shouldn't be a problem in ordinary use.
Not being at all fluent in Python, I wouldn't have known what to
look for.
I can often modify a python program, as I did with Move-STL-to-
origin
https://github.com/lar3ry/OpenSCAD---Move-STL-to-origin
but I never have written anything in it from scratch
It's actually two anti-patterns that are pretty common in all
languages that have exceptions:
* The try-catch for FileNotFoundError is too big. It covers not
just the open of the input file but a lot of other stuff, notably
including the open of the output file. If you give it an output file
with a directory that didn't exist, I suspect that it will complain
that the input file isn't found. try-catches intended to catch
particular problems should be wrapped as tightly as possible around
the point where the problem occurs, so that they won't accidentally
catch unexpected instances of that failure.
Ahh.. of course.
* The try-catch for Exception shouldn't be there at all. Other than
problems opening files, there shouldn't be any exceptions. An
exception indicates a bug. If the program had a bug, the handling
here would say (for instance) that "key" is not defined... but will
not tell you what line the failure happened on. In a program this
small the error alone might be enough to find the problem, but in a
more complex program it won't be. There is an attitude that says
that programs should never let an exception make it all the way to
the default "dump a stack trace" handling. I think that attitude is
deeply misguided; it means that when there is a bug it will be
difficult to diagnose. Particularly bad examples might lead to the
program silently doing something damaging.
There should be a try-catch wrapped tightly around the open-for-
write, and I expect that the try-catch wrapped around the open-for-
read should catch more than just FileNotFoundError; it should catch,
e.g., permission errors. Similarly for the try-catch wrapped around
the open-for-write.
But as I said, none of that should be an issue in ordinary use.
I agree. Maybe I'll take a look at the catches and see if I can make
them better.
BTW, your posts are coming out with text in black.
Uh... yes? That's certainly the way they are on my screen, because
that's the way I have it configured, but I just looked and they don't
specify any colors; you should be getting whatever your configured
default is for HTML messages. (Or for plain-text, if your mail
program is configured to prefer the plain-text copy of the message.)
I think I get both HTML and plain text messages without preference,
When I respond I get asked if I want to switch to plain text.
The interesting thing is that the one I am responding to is shown white
on my dark theme Evolution, as was your previous one. The two before
those were shown dark on dark, and prior to that, they were always
black on white.
Larry