 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] gmail com> wrote:
>
> camera:
> location<0, 2, -15>
> lookat<0, 0, 0>
> up<0, 1, 0>
> fov<60>
>
> light:
> location<500, 100, -50>
> color<1, 1, 1>
> intensity<1.0>
>
> object:
> sphere:
> center<0, 0, 0>
> radius<1>
> material:
> texture:
> color<1, 0, 0>
> reflectivity<0.2>
>
> object:
> plane:
> normal<0, 1, 0>
> distance<-1>
> material:
> texture:
> color<0.2, 0.8, 0.2>
> reflectivity<0.1>
>
> ;)
>
> ingo
In python you can only have tab sized (4 spaces) indents like this, which looks
more tidy/less error prone (though I understand people would like more
flexibility and perhaps more compact concision) :
camera:
location<0, 2, -15>
lookat<0, 0, 0>
up<0, 1, 0>
fov<60>
light:
location<500, 100, -50>
color<1, 1, 1>
intensity<1.0>
object:
sphere:
center<0, 0, 0>
radius<1>
material:
texture:
color<1, 0, 0>
reflectivity<0.2>
object:
plane:
normal<0, 1, 0>
distance<-1>
material:
texture:
color<0.2, 0.8, 0.2>
reflectivity<0.1>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
>...
> In python you can only have tab sized (4 spaces) indents like this, which looks
> more tidy/less error prone (though I understand people would like more
> flexibility and perhaps more compact concision) :
>...
> object:
> sphere:
> center<0, 0, 0>
> radius<1>
> material:
> texture:
> color<1, 0, 0>
> reflectivity<0.2>
>...
Hi Mr
Python allows 1 or more extra leading spaces for each indentation level.
So you can actually write code like this:
for x in range(10):
for y in range(10):
for z in range(10):
print(f'<{x}, {y}, {z}>')
if (x % 2) == 1:
print('---------')
what is recommended in pep8 is another matter:
https://peps.python.org/pep-0008/#indentation
And BTW: Tabs are evil!
--
Tor Olav
http://subcube.com
https://github.com/t-o-k
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
> In python you can only have tab sized (4 spaces) indents like this[...]
in addition to Tor Olav's evil tabs, a tab is just a '\t' symbol like a '\n' or
'\r'. You can tell your editor to use any tab size >0 you like. Python just
looks at the '\t' not at what your editor thinks how wide a tab is.
But that's not all, Python also looks at spaces for indentation. The mixing of
tabs and spaces is what makes things messy. Something that easily happens when
copying code. So set your editor to always convert tabs to spaces, the length is
up to your preference.
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tor and Ingo, You are right ! I had even forgotten about those eventualities
since the guiding principle in Python for me has indeed become the PEP (with
quite some personal choice for when to apply it or not :-D ! It's so much
enforced by all collective projects however (git repo settings play a role in
this too)... and also luckily the auto formatting tools such as Black/Snake8/
etc, That I forgot I may have taken different habits if I had kept learning
python by myself all along. It works well once you have used some of this at
least once... but before, it's true the language does have room for shooting
yourself in the foot. All this makes me think of another Idea then :
What if POV 4 was not developed as a version of the language itself but rather
as only a couple of new features, and a formatting tool such as black ?
Would everyone around here also frown at this?
Post a reply to this message
|
|
| |
| |
|
|
From: Ilya Razmanov
Subject: Re: Curly braces replaced by indentations but only as an option ?
Date: 20 Mar 2025 08:22:48
Message: <67dc0898$1@news.povray.org>
|
|
|
| |
| |
|
|
On 20.03.2025 14:42, Mr wrote:
> as only a couple of new features, and a formatting tool such as black ?
With Python, all these autoformatters like 'black' drive me mad by
compressing all my comprehensions down to one line. To me, even well
formatted 3D list comprehensions with slicing and some 'if' and function
inside are hard to understand, so when formatting gets 'blacked', I
can't understand things I wrote five minutes ago.
--
Ilyich the Toad
https://dnyarri.github.io/
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Ilya Razmanov <ily### [at] gmailcom> wrote:
> On 20.03.2025 14:42, Mr wrote:
> > as only a couple of new features, and a formatting tool such as black ?
> With Python, all these autoformatters like 'black' drive me mad ...
while every project and organisation, it seems, is compelled to issue formatting
guidance/rules, one can "escape" from all of that, using the "pre-Gen-Z" ;-)
tool (note, singular) 'indent'.
eg <https://man.openbsd.org/indent.1>
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
"ingo" <nomail@nomail> wrote:
> ...
> object:
> sphere:
> center<0, 0, 0>
> radius<1>
> material:
> texture:
> color<1, 0, 0>
> reflectivity<0.2>
>
> object:
> plane:
> normal<0, 1, 0>
> distance<-1>
> material:
> texture:
> color<0.2, 0.8, 0.2>
> reflectivity<0.1>
JSON has been mentioned elsewhere as a replacement (?) or as a component of the
"new SDL". it would (I guess) make a real good storage format for objects (like
above), or materials/textures libraries, etc.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mr" <m******r******at_hotmail_dot_fr> wrote:
> Would everyone around here also frown at this?
Kind of ;) formatting is meditative moment, time for contemplating on the code
at hand. The language server for my editor auto formats on save, it is extremely
annoying as the result is ugly and I have not found how to turn it off.
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> hi,
>
> "ingo" <nomail@nomail> wrote:
> > ...
> > object:
> > sphere:
> > center<0, 0, 0>
> > radius<1>
> > material:
>
> JSON has been mentioned elsewhere as a replacement (?) or as a component of the
> "new SDL". it would (I guess) make a real good storage format for objects (like
> above), or materials/textures libraries, etc.
>
object and material are just containers, lists/arrays..
there are a few specialised ordered lists with an operator attached, union,
intersect etc.
A povObject/shape is like a specific composed dictionary/struct/record as is
texture. One could define it all in SQLite:
CREATE TABLE IF NOT EXISTS sphere(
//centre: ah, there is no vector type but we could crate a table for that
id INTEGER PRIMARY KEY NOT NULL,
name TEXT UNIQUE,
centre INTEGER REFERENCES vector(id),
radius REAL DEFAULT 1.0,
material INTEGER REFERENCES material(id)
)STRICT;
CREATE TABLE IF NOT EXISTS vector(
id INTEGER PRIMARY KEY NOT NULL, // or use a string formatted as '<x,y,z>'?
x REAL NOT NULL,
y REAL NOT NULL,
z REAL NOT NULL
)STRICT;
etc. etc. who needs type-systems and OOP if you have a database ;)
ingo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> object and material are just containers, lists/arrays..
> there are a few specialised ordered lists with an operator attached, union,
> intersect etc.
>
> A povObject/shape is like a specific composed dictionary/struct/record as is
> texture. One could define it all in SQLite:
>
> etc. etc. who needs type-systems and OOP if you have a database ;)
Yes,
Along those lines, I was also trying to look at the similarities of all of the
povObjects to see if we could have some more commonality under-the-hood. It's
something clipka mentioned. I have way too many spreadsheets and little pieces
of paper with scribbles . . .
It would also be great if as many things as possible had some sort of default
attached to it, so I could just invoke a sphere, and maybe it just had a
POV-Unit diameter and default texture.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
