"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