 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmail com> wrote:
> If spaces and tabs were to suddenly have real meaning in POV 4, and depending on
> how we each write POV code-- the layout of the text-- it could break all of our
> old scenes, going back decades.
Aye, lad. But we're talking about POV-Ray 4.0, dontchaknow.
Let's cast off the shackles of "backward compatibility" and do something NEW!
It's not like the old versions will be deleted from the fabric of reality.
> For example, I personally write code with tabbed indents, just to make the
> various constructs clear in my mind. Like...
>
> sphere{0,1
> texture{
> pigment{rgb 1}
> finish{...}
> }
> normal{...}
> }
I do it just to make jr twitch to the verge of seizures.
Other times I simply do things because I think they're a CAPITAL IDEA.
I think the real value of opening and terminating symbols is their utility for
future delinters and debuggers.
I have already expressed my support for MORE different kinds of brackets and
parentheses, as well as #endif, #endwhile, #endfor, #endmacro, etc.
- BW
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...it could break all of our
> > old scenes, going back decades.
>
> Aye, lad. But we're talking about POV-Ray 4.0, dontchaknow.
> Let's cast off the shackles of "backward compatibility" and do something NEW!
>
> It's not like the old versions will be deleted from the fabric of reality.
>
A new(?) language with new syntax rules. Arrggghh. I have enough trouble trying
to understand the NEW remote control for my recently-installed NEW AND
IMPROVED(?) cable-TV box. :-[
> > Personally, I have always liked the fact that POV-ray's SDL syntax did not
> > impose any meaning on tabs or spaces; it would have been one more 'layer of
> > abstraction' to add to the learning of the syntax...
In other words, code-writing in POV has always been more 'relaxed' and not so
exacting; no need to worry about spaces or tabs... which I like to use liberally
:-) Of course, others might complain that this 'feature' produces a LESS
structured/exacting environment, in the context of other languages. But it sure
makes code-writing easier, in my humble opinion.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> 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
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"ingo" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] gmailcom> 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
|
|
| |
| |
|
|
|
|
| |
|
|
