Chris Huff <chr### [at] maccom> wrote:

> In article <3a8145cd@news.povray.org>, Geoff Wedig 
> <wed### [at] darwinepbicwruedu> wrote:

>> I've often thought of constructing a set of objects for visual scenes 
>> in python, with some kind of reader that produced POV script. 

> Look at VPython: http://cil.andrew.cmu.edu/projects/visual/
> There is a way to export POV scenes.


>> Python is a very clean and simple language, but provides a level of 
>> power that POV-script just doesn't at this time.

> Hmph. I personally don't like what I have seen of it, but I've never had 
> to do anything in it, and a lot of people do seem to like it.
> I mainly don't like the way loops and things don't have a visible 
> closing, and the fact that it is sensitive to white space. And though it 
> is supposed to be object oriented, the code I've seen doesn't look very 
> object oriented to me.

The white space thing I tend to agree with.  It does take getting used to. 
On the other hand, it's actually pretty nice.  I've worked with programmers
who use "arbitrary" rules -- which is to say rules that change from one line
to the next -- to write their code.  Having a built in requirement to lay
your code out neatly isn't a bad thing at all.

As for OO, python was originally a scripting tool, like Perl (it actually
pre-dates perl, but only has recently gotten much recognition) Most of the
code out there is very script like for that reason.  However, it does have a
fairly powerful OO component, as tools like wxPython show.  It's a very
flexible language in that sense.

Geoff

Post a reply to this message

On 8 Feb 2001 08:35:10 -0500, Geoff Wedig wrote:
>The white space thing I tend to agree with.  It does take getting used to. 
>On the other hand, it's actually pretty nice.  I've worked with programmers
>who use "arbitrary" rules -- which is to say rules that change from one line
>to the next -- to write their code.  Having a built in requirement to lay
>your code out neatly isn't a bad thing at all.

But tools like "indent" can fix stupid programmer tricks in C.  In Python,
the same stupid programmer tricks (or corruption due to some idiot loading
the script into a word processor, or whatever) kill the program in weird
and wonderful ways.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote:

> On 8 Feb 2001 08:35:10 -0500, Geoff Wedig wrote:
>>The white space thing I tend to agree with.  It does take getting used to. 
>>On the other hand, it's actually pretty nice.  I've worked with programmers
>>who use "arbitrary" rules -- which is to say rules that change from one line
>>to the next -- to write their code.  Having a built in requirement to lay
>>your code out neatly isn't a bad thing at all.

> But tools like "indent" can fix stupid programmer tricks in C.  In Python,
> the same stupid programmer tricks (or corruption due to some idiot loading
> the script into a word processor, or whatever) kill the program in weird
> and wonderful ways.

In other words, the language enforces something you have to go to outside
tools for in other languages?  And this is a bad thing?

Geoff

Post a reply to this message

On 8 Feb 2001 09:26:41 -0500, Geoff Wedig wrote:
>In other words, the language enforces something you have to go to outside
>tools for in other languages?  And this is a bad thing?

That's not what I said.  What I said is, you can fix broken indentation in
other languages, because there are other cues as to how it should have been
done.  In Python, when (not if) the indentation gets broken, the program stops 
working, and you might not even notice.  Yes, that is a bad thing.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

"Merits of Python" as topic should probably be moved to a Python newsgroup,
but here goes:

> > How about   "# end" or whatever you choose?   :-)
>
> The "# end" would be a comment...but what do you mean by "whatever you
> choose"?

# end, # endloop, # end whateverthehellyerstopping       :-)

> Can you tell Python to allow terminating characters/keywords?
> Will it then use that keyword instead of indentation to figure things
> out?

I'd be surprised if that was possible from within Python itself, but it
would probably not be difficult to modify source code and recompile.  Call
it Pythoff.   Sounds like a Russian variant.  :-)


> Visual structure is exactly why I *don't* like it. It's white space,
> there is nothing there, it's a vacuum, and nothing should be affected by
> it. I can understand space being used to separate "words", but to
> determine if something is inside or outside a loop or condition...I
> prefer a visual termination, not something that relies on an area of
> blank paper.

Yet, I am using blank spaces to seperate conceptual blocks even in the
dialog I write here- to good effect, I think.  Early Greek texts did not
even use white space to seperate WORDS, itjustallrantogetherlikethis.
(Like the way Germans build long words... just schmush a small sentence
together. :-)

> Pascal's "begin" and "end", C's "{" and "}", AppleScript's
> "end repeat", "end tell", POV-Ray's "#end", etc...
> I can't imagine the way it is in Python being *good* for code
> maintenance, but maybe I'm wrong...

I don't think you're 'wrong,' any more than Brits drive on the 'wrong' side
of the road from an American perspective.  But I do believe the
whitespace-as-codeblock-end is as easy to get used to as paragraph indents
in literature.  In truth, we look for such cues all the time in our reading.

> > In fact, if I adopt Python for major projects involving multiple
> > programmers, I would welcome a scheme which enforces comments
> > beginning in, say, column 60, and a minimum number of comments per
> > page.
>
> I hope I'm misunderstanding you...you want to push all comments to the
> far right, and minimize the number of comments?!?

Perhaps I should have said "and an enforced minimum."   In other words,
programmers using the IDE within my programming groups would be REQUIRED to
have at least a certain amount of text within the 'comment zone' or the code
would not be accepted as syntactically complete.

> That's the opposite of
> what it should be...the comments should be close to the code which they
> are commenting on, and code should always be well commented. Minimizing
> the number of comments certainly isn't the goal...

No, I would not have advocated minimal commenting for enhanced maintenance.
:-P

As for comments to the right, as opposed to mixed within the code, that's an
excellent scheme which I've been using for over twenty years, all the way
back to assembler code.  With high level languages the commenting can be
more sparse, but should still be GENEROUS.

In my approach, one begins a project by writing a mission statement, then
(in outline form) pseudocode in large conceptual blocks, then pseudocode
which begins to break down large tasks into smaller until we are writing
pseudocode at the level of code blocks, like this:

# SCAN DATA FOR TRIPLETS
# Read chunk from file,
# normalize data,
# scan,
# place triplets in array,
# remember end data,
# do another chunk.

Personally, I often can't resist coding as I write pseudocode (which I call
'comments').  But given the preliminary pseudocode above, one expands that
(as I do below with my impromptu pseudolanguage).


                                        # SCAN DATA FOR TRIPLETS
while not eof                           # Read chunk from file,
  readfile(nextblock, 1024)             #
  normalize(nextblock)                  # normalize data,
  tripScan(this + nextblock)            # scan,
  writefile(trips, append, 'file')      # place triplets in file,
  this = nextblock                      # remember end data,
do while                                # do another chunk.


Of coure, the last line would be unnecessary in SOME languages.  Ahem.  :->

> All I meant was that I've looked for examples of using OOP in Python,
> and haven't found them...
>
>
> > May be due in part to the fact that Python is relatively new.
>
> That would explain it, but I didn't think Python was that new...newer
> than C/C++, but not a new language.
> How long has it been around?

One can really not measure the capabilities of a language by what the
majority of programmers are doing with it, or when.   Fad, trend and hype
would lead us to believe that some languages will do everything imaginable
on every platform with no recoding, with complete stability and security,
replacing entire operating systems and sweeping the world.  The Goddess of
Reality merely smiles.

> > Are you aware of any aspect of object oriented design philiosophy, as
> > commonly defined, which is missing in Python?
>
> No, because I haven't been able to find much information about OOP in
> Python at all. I poked around the www.python.org site for a while, and
> only found a mention that it had OOP features. Any suggestions? Sites
> with good examples?

No, as I indicated, just beginning my own investigation.  Clearly, at least
a subset of OO programming is possible.  If you're concerned about the
degree of OO implementation, a question to that effect in the
comp.lang.python newsgroup should lead to spirited discussion (and
examples).

Post a reply to this message

> But tools like "indent" can fix stupid programmer tricks in C.  In Python,
> the same stupid programmer tricks (or corruption due to some idiot loading
> the script into a word processor, or whatever) kill the program in weird
> and wonderful ways.

There is ALWAYS a way, Ron.  :-O

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On 8 Feb 2001 09:26:41 -0500, Geoff Wedig wrote:
> >In other words, the language enforces something you have to go to outside
> >tools for in other languages?  And this is a bad thing?
>
> That's not what I said.  What I said is, you can fix broken indentation in
> other languages, because there are other cues as to how it should have
been
> done.  In Python, when (not if) the indentation gets broken, the program
stops
> working, and you might not even notice.  Yes, that is a bad thing.

I'm reminded of the old schtick:

Patient:  Doctor, it hurts when I do this.
Doctor:   Don't do that.

Yes, a lame or maladjusted word processor might break code.   Just as that
infernal LF-CR or CR-LF ordering which regularly rears its little ugly head
in programming text widgets. But you will SURELY notice, eventually, and
take the necessary steps to insure that your tools behave as needed.

After all, code text editors can be syntax-smart, color-coding keywords and
comments, enforcing close-parens and the like.  Newlines, blank lines and
indents can be rendered just as significant-- and eventually, with a little
practice, become that way in the eye of the prgrammer (or, more importantly,
the MAINTAINER).

I am 100% FOR syntactically requiring white space and visual blocking
structure- perhaps because I have been doing this voluntarily for over 20
years.  I assure you, the practice leads to the most easily modifiable and
maintainable code you will encounter anywhere.

Post a reply to this message

On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
>
>I'm reminded of the old schtick:
>
>Patient:  Doctor, it hurts when I do this.
>Doctor:   Don't do that.

Me too.  And for me, significant whitespace is very much a "Don't do that
then" thing.  Not that I don't enforce whitespace; if I had my way, our 
version-control software here would check for compliance with the coding
standards before allowing checkins.  Unfortunately, the software isn't up
to it and neither is the code (which a whole bevy of contractors got to
before we did.)

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
>Yes, a lame or maladjusted word processor might break code.   Just as that
>infernal LF-CR or CR-LF ordering which regularly rears its little ugly head
>in programming text widgets. But you will SURELY notice, eventually, and
>take the necessary steps to insure that your tools behave as needed.

The problem is that "eventually" part.  I'd rather not notice it after the
code has been sent to production.  And while it's fine to say "don't do that,
then" it's a lot harder to say that to an entire team of programmers plus an
assortment of random contractors.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
> On Thu, 8 Feb 2001 11:11:17 -0800, OpenMined wrote:
> >Yes, a lame or maladjusted word processor might break code.   Just as
that
> >infernal LF-CR or CR-LF ordering which regularly rears its little ugly
head
> >in programming text widgets. But you will SURELY notice, eventually, and
> >take the necessary steps to insure that your tools behave as needed.
>
> The problem is that "eventually" part.  I'd rather not notice it after the
> code has been sent to production.  And while it's fine to say "don't do
that,
> then" it's a lot harder to say that to an entire team of programmers plus
an
> assortment of random contractors.
>

I understand the nature of the difficulty of working with existing code and
an existing assortment of trained (read 'ingrained habits') programmers.  A
paradigm shift (or even a modest change) in those circusmstances is often
nearly impossible.

But your objections are EXACTLY those which were genuinely expressed when
the world was urged to move from spaghetti code to structured code,  and
from the structured-linear model to the object-oriented model.  Yes, a
change in methods is not without its difficulties in the SHORT term-- and
probably should NOT be attempted mid-project.

(I will have to say, however, that to "notice it after the code has been
sent to production" would suggest a breakdown in- or absense of- adequate
testing protocols.  In my view, any programmer which creates/modifies code
without creating/using in parallel an exhaustive every-state module testing
regime- as much or more work than writing the original code- simply has not
finished the job.)

So, when I speak favorably of Python's use of white space- a concept I would
enjoy seeing extended, as mentioned- I am thinking in terms of new projects,
with programmers who have fully adapted to the needs of the programming
environment, and with a project for which the ongoing needs are as important
as the need to get it done and out quickly.

In these contexts, using white space and enforced commenting will, I
believe, eventually be seen as a scientific, legal and commercial necessity,
simply GOOD programming practice, not just as an arcane preference.

___

Post a reply to this message