comp.lang.python - 26 new messages in 5 topics - digest

comp.lang.python
http://groups.google.com/group/comp.lang.python?hl=en

comp.lang.python@googlegroups.com

Today's topics:

* understanding someone else's program - 5 messages, 5 authors
http://groups.google.com/group/comp.lang.python/t/93a7e4a223956dae?hl=en
* python 3.3 repr - 14 messages, 6 authors
http://groups.google.com/group/comp.lang.python/t/4726d89afd8330a2?hl=en
* Program Translation - Nov. 14, 2013 - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/69cada4c80ff7036?hl=en
* Best approach to edit linux configuration file - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/9834d854a5fbdfa1?hl=en
* Automation - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.python/t/2cb5aaffece4c4a9?hl=en

==============================================================================
TOPIC: understanding someone else's program
http://groups.google.com/group/comp.lang.python/t/93a7e4a223956dae?hl=en
==============================================================================

== 1 of 5 ==
Date: Fri, Nov 15 2013 3:19 am
From: Ben Finney


"C. Ng" <ngcbmy@gmail.com> writes:

> Please suggest how I can understand someone else's program

Welcome to this forum!

I sympathise with this query. Much of the craft of programming is in
understanding the code written by other programmers, and learning from
that experience how to improve the understandability of the code one
writes.

In general, the answer to your question is: Read a lot of other people's
code, preferably by the side of the programmer who wrote it. Experiment
with a lot of code written by others, and test one's understanding by
improving it and confirming it still works :-)

> where
> - documentation is sparse

Sadly the case for the majority of software any of us will be involved
with maintaining.

> - in function A, there will be calls to function B, C, D.... and in
> those functions will be calls to functions R,S,T.... and so on so
> forth... making it difficult to trace what happens to a certain
> variable

This is normal modular programming. Ideally, those functions should each
be doing one conceptually simple task, with a narrowly-defined
interface, and implementing its job by putting together other parts at a
lower level.

Is there something particular about these functions that make them more
difficult than good code?

--
\ "Generally speaking, the errors in religion are dangerous; |
`\ those in philosophy only ridiculous." —David Hume, _A Treatise |
_o__) of Human Nature_, 1739 |
Ben Finney





== 2 of 5 ==
Date: Fri, Nov 15 2013 5:39 am
From: Joel Goldstick


On Fri, Nov 15, 2013 at 6:19 AM, Ben Finney <ben+python@benfinney.id.au> wrote:
> "C. Ng" <ngcbmy@gmail.com> writes:
>
>> Please suggest how I can understand someone else's program
>
> Welcome to this forum!
>
> I sympathise with this query. Much of the craft of programming is in
> understanding the code written by other programmers, and learning from
> that experience how to improve the understandability of the code one
> writes.
>
> In general, the answer to your question is: Read a lot of other people's
> code, preferably by the side of the programmer who wrote it. Experiment
> with a lot of code written by others, and test one's understanding by
> improving it and confirming it still works :-)
>
>> where
>> - documentation is sparse
>
> Sadly the case for the majority of software any of us will be involved
> with maintaining.
>
>> - in function A, there will be calls to function B, C, D.... and in
>> those functions will be calls to functions R,S,T.... and so on so
>> forth... making it difficult to trace what happens to a certain
>> variable
>
> This is normal modular programming. Ideally, those functions should each
> be doing one conceptually simple task, with a narrowly-defined
> interface, and implementing its job by putting together other parts at a
> lower level.
>
> Is there something particular about these functions that make them more
> difficult than good code?
>
> --
> \ "Generally speaking, the errors in religion are dangerous; |
> `\ those in philosophy only ridiculous." —David Hume, _A Treatise |
> _o__) of Human Nature_, 1739 |
> Ben Finney
>
> --
> https://mail.python.org/mailman/listinfo/python-list

Much more time is spent figuring out old code than writing new code!
Python docstrings help a little. Do you know about a utility called
pydocs? If you don't, read about it. Using pydocs you can produce
documentation for all the modules you need to understand. It will
pull out the docstrings at the top of the module,and for each method
and function. Normally, that level of documentation won't be good
enough to satisfy the needs of a new reader, so go through each
function and understand them one at a time. Add to the docstrings.


--
Joel Goldstick
http://joelgoldstick.com




== 3 of 5 ==
Date: Fri, Nov 15 2013 5:49 am
From: Jean-Michel Pichavant


----- Original Message -----
> Hi all,
>
> Please suggest how I can understand someone else's program where
> - documentation is sparse
> - in function A, there will be calls to function B, C, D.... and in
> those functions will be calls to functions R,S,T.... and so on so
> forth... making it difficult to trace what happens to a certain
> variable
>
> Am using ERIC4 IDE.
>
> Thanks.

If the documentation is sparse, writing the doc yourself is one way to dive into someone else's code. To begin with, you can stick to the function purpose, and for the WTF functions try to document the parameters and return values as well.

It may take a lot of time depending on how good the current code is.

JM


-- IMPORTANT NOTICE:

The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.




== 4 of 5 ==
Date: Fri, Nov 15 2013 5:50 am
From: William Ray Wing


On Nov 15, 2013, at 6:05 AM, C. Ng <ngcbmy@gmail.com> wrote:

> Hi all,
>
> Please suggest how I can understand someone else's program where
> - documentation is sparse
> - in function A, there will be calls to function B, C, D.... and in those functions will be calls to functions R,S,T.... and so on so forth... making it difficult to trace what happens to a certain variable
>
> Am using ERIC4 IDE.
>
> Thanks.
> --
> https://mail.python.org/mailman/listinfo/python-list

The other suggestions you have received are good places to start. I'd add only one other - that you consider running the code inside an IDE and single-stepping through as you watch what happens to the variables. As you get a better and better feel for what the code is doing, you can move up from single stepping to setting break points before and after places you are still scratching you head over.

-Bill



== 5 of 5 ==
Date: Fri, Nov 15 2013 6:03 am
From: Chris Angelico


On Sat, Nov 16, 2013 at 12:49 AM, Jean-Michel Pichavant
<jeanmichel@sequans.com> wrote:
> If the documentation is sparse, writing the doc yourself is one way to dive into someone else's code. To begin with, you can stick to the function purpose, and for the WTF functions try to document the parameters and return values as well.

Agreed. I just had someone do that with my code - it was sparsely
commented, and he went through adding docs based on what he thought
functions did (based on their names and a cursory look at their bodies
- return values, particularly, were often documented by description,
which wasn't particularly useful with certain callbacks). Seeing where
he'd misdescribed something was a great way for me to figure out which
functions were poorly named, or at least begging for better comments.

If you have the luxury of working with the original programmer, that
would be something I'd strongly recommend. Even if you can't, try to
set some comments down; but be aware that false comments are worse
than none at all, so do notate which are your comments and which bits
you're particularly unsure of.

ChrisA





==============================================================================
TOPIC: python 3.3 repr
http://groups.google.com/group/comp.lang.python/t/4726d89afd8330a2?hl=en
==============================================================================

== 1 of 14 ==
Date: Fri, Nov 15 2013 3:28 am
From: Robin Becker


I'm trying to understand what's going on with this simple program

if __name__=='__main__':
print("repr=%s" % repr(u'\xc1'))
print("%%r=%r" % u'\xc1')

On my windows XP box this fails miserably if run directly at a terminal

C:\tmp> \Python33\python.exe bang.py
Traceback (most recent call last):
File "bang.py", line 2, in <module>
print("repr=%s" % repr(u'\xc1'))
File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
return codecs.charmap_encode(input,self.errors,encoding_map)[0]
UnicodeEncodeError: 'charmap' codec can't encode character '\xc1' in position 6:
character maps to <undefined>

If I run the program redirected into a file then no error occurs and the the
result looks like this

C:\tmp>cat fff
repr='┴'
%r='┴'

and if I run it into a pipe it works as though into a file.

It seems that repr thinks it can render u'\xc1' directly which is a problem
since print then seems to want to convert that to cp437 if directed into a terminal.

I find the idea that print knows what it's printing to a bit dangerous, but it's
the repr behaviour that strikes me as bad.

What is responsible for defining the repr function's 'printable' so that repr
would give me say an Ascii rendering?
-confused-ly yrs-
Robin Becker





== 2 of 14 ==
Date: Fri, Nov 15 2013 3:38 am
From: Ned Batchelder


On Friday, November 15, 2013 6:28:15 AM UTC-5, Robin Becker wrote:
> I'm trying to understand what's going on with this simple program
>
> if __name__=='__main__':
> print("repr=%s" % repr(u'\xc1'))
> print("%%r=%r" % u'\xc1')
>
> On my windows XP box this fails miserably if run directly at a terminal
>
> C:\tmp> \Python33\python.exe bang.py
> Traceback (most recent call last):
> File "bang.py", line 2, in <module>
> print("repr=%s" % repr(u'\xc1'))
> File "C:\Python33\lib\encodings\cp437.py", line 19, in encode
> return codecs.charmap_encode(input,self.errors,encoding_map)[0]
> UnicodeEncodeError: 'charmap' codec can't encode character '\xc1' in position 6:
> character maps to <undefined>
>
> If I run the program redirected into a file then no error occurs and the the
> result looks like this
>
> C:\tmp>cat fff
> repr='┴'
> %r='┴'
>
> and if I run it into a pipe it works as though into a file.
>
> It seems that repr thinks it can render u'\xc1' directly which is a problem
> since print then seems to want to convert that to cp437 if directed into a terminal.
>
> I find the idea that print knows what it's printing to a bit dangerous, but it's
> the repr behaviour that strikes me as bad.
>
> What is responsible for defining the repr function's 'printable' so that repr
> would give me say an Ascii rendering?
> -confused-ly yrs-
> Robin Becker

In Python3, repr() will return a Unicode string, and will preserve existing Unicode characters in its arguments. This has been controversial. To get the Python 2 behavior of a pure-ascii representation, there is the new builtin ascii(), and a corresponding %a format string.

--Ned.




== 3 of 14 ==
Date: Fri, Nov 15 2013 4:16 am
From: Robin Becker


On 15/11/2013 11:38, Ned Batchelder wrote:
..........
>
> In Python3, repr() will return a Unicode string, and will preserve existing Unicode characters in its arguments. This has been controversial. To get the Python 2 behavior of a pure-ascii representation, there is the new builtin ascii(), and a corresponding %a format string.
>
> --Ned.
>

thanks for this, edoesn't make the split across python2 - 3 any easier.
--
Robin Becker





== 4 of 14 ==
Date: Fri, Nov 15 2013 5:54 am
From: Ned Batchelder


On Friday, November 15, 2013 7:16:52 AM UTC-5, Robin Becker wrote:
> On 15/11/2013 11:38, Ned Batchelder wrote:
> ..........
> >
> > In Python3, repr() will return a Unicode string, and will preserve existing Unicode characters in its arguments. This has been controversial. To get the Python 2 behavior of a pure-ascii representation, there is the new builtin ascii(), and a corresponding %a format string.
> >
> > --Ned.
> >
>
> thanks for this, edoesn't make the split across python2 - 3 any easier.
> --
> Robin Becker

No, but I've found that significant programs that run on both 2 and 3 need to have some shims to make the code work anyway. You could do this:

try:
repr = ascii
except NameError:
pass

and then use repr throughout.

--Ned.




== 5 of 14 ==
Date: Fri, Nov 15 2013 6:25 am
From: Roy Smith


In article <b6db8982-feac-4036-8ec4-2dc720d41a4b@googlegroups.com>,
Ned Batchelder <ned@nedbatchelder.com> wrote:

> In Python3, repr() will return a Unicode string, and will preserve existing
> Unicode characters in its arguments. This has been controversial. To get
> the Python 2 behavior of a pure-ascii representation, there is the new
> builtin ascii(), and a corresponding %a format string.

I'm still stuck on Python 2, and while I can understand the controversy ("It breaks my Python 2 code!"), this seems like the right thing to have done. In Python 2, unicode is an add-on. One of the big design drivers in Python 3 was to make unicode the standard.

The idea behind repr() is to provide a "just plain text" representation of an object. In P2, "just plain text" means ascii, so escaping non-ascii characters makes sense. In P3, "just plain text" means unicode, so escaping non-ascii characters no longer makes sense.

Some of us have been doing this long enough to remember when "just plain text" meant only a single case of the alphabet (and a subset of ascii punctuation). On an ASR-33, your C program would print like:

MAIN() \(
PRINTF("HELLO, ASCII WORLD");
\)

because ASR-33's didn't have curly braces (or lower case).

Having P3's repr() escape non-ascii characters today makes about as much sense as expecting P2's repr() to escape curly braces (and vertical bars, and a few others) because not every terminal can print those.

--
Roy Smith
roy@panix.com





== 6 of 14 ==
Date: Fri, Nov 15 2013 6:29 am
From: Robin Becker


On 15/11/2013 13:54, Ned Batchelder wrote:
.........
>
> No, but I've found that significant programs that run on both 2 and 3 need to have some shims to make the code work anyway. You could do this:
>
> try:
> repr = ascii
> except NameError:
> pass
....
yes I tried that, but it doesn't affect %r which is inlined in unicodeobject.c,
for me it seems easier to fix windows to use something like a standard encoding
of utf8 ie cp65001, but that's quite hard to do globally. It seems sitecustomize
is too late to set os.environ['PYTHONIOENCODING'], perhaps I can stuff that into
one of the global environment vars and have it work for all python invocations.
--
Robin Becker





== 7 of 14 ==
Date: Fri, Nov 15 2013 6:40 am
From: Serhiy Storchaka


15.11.13 15:54, Ned Batchelder написав(ла):
> No, but I've found that significant programs that run on both 2 and 3 need to have some shims to make the code work anyway. You could do this:
>
> try:
> repr = ascii
> except NameError:
> pass
>
> and then use repr throughout.

Or rather

try:
ascii
except NameError:
ascii = repr

and then use ascii throughout.






== 8 of 14 ==
Date: Fri, Nov 15 2013 6:43 am
From: Robin Becker


..........
> I'm still stuck on Python 2, and while I can understand the controversy ("It breaks my Python 2 code!"), this seems like the right thing to have done. In Python 2, unicode is an add-on. One of the big design drivers in Python 3 was to make unicode the standard.
>
> The idea behind repr() is to provide a "just plain text" representation of an object. In P2, "just plain text" means ascii, so escaping non-ascii characters makes sense. In P3, "just plain text" means unicode, so escaping non-ascii characters no longer makes sense.
>

unfortunately the word 'printable' got into the definition of repr; it's clear
that printability is not the same as unicode at least as far as the print
function is concerned. In my opinion it would have been better to leave the old
behaviour as that would have eased the compatibility.

The python gods don't count that sort of thing as important enough so we get the
mess that is the python2/3 split. ReportLab has to do both so it's a real issue;
in addition swapping the str - unicode pair to bytes str doesn't help one's
mental models either :(

Things went wrong when utf8 was not adopted as the standard encoding thus
requiring two string types, it would have been easier to have a len function to
count bytes as before and a glyphlen to count glyphs. Now as I understand it we
have a complicated mess under the hood for unicode objects so they have a
variable representation to approximate an 8 bit representation when suitable etc
etc etc.

> Some of us have been doing this long enough to remember when "just plain text" meant only a single case of the alphabet (and a subset of ascii punctuation). On an ASR-33, your C program would print like:
>
> MAIN() \(
> PRINTF("HELLO, ASCII WORLD");
> \)
>
> because ASR-33's didn't have curly braces (or lower case).
>
> Having P3's repr() escape non-ascii characters today makes about as much sense as expecting P2's repr() to escape curly braces (and vertical bars, and a few others) because not every terminal can print those.
>
.....
I can certainly remember those days, how we cried and laughed when 8 bits became
popular.
--
Robin Becker





== 9 of 14 ==
Date: Fri, Nov 15 2013 6:50 am
From: Joel Goldstick


>> Some of us have been doing this long enough to remember when "just plain
>> text" meant only a single case of the alphabet (and a subset of ascii
>> punctuation). On an ASR-33, your C program would print like:
>>
>> MAIN() \(
>> PRINTF("HELLO, ASCII WORLD");
>> \)
>>
>> because ASR-33's didn't have curly braces (or lower case).
>>
>> Having P3's repr() escape non-ascii characters today makes about as much
>> sense as expecting P2's repr() to escape curly braces (and vertical bars,
>> and a few others) because not every terminal can print those.
>>
> .....
> I can certainly remember those days, how we cried and laughed when 8 bits
> became popular.
>
Really? you cried and laughed over 7 vs. 8 bits? That's lovely (?).
;). That eighth bit sure was less confusing than codepoint
translations


> --
> Robin Becker
> --
> https://mail.python.org/mailman/listinfo/python-list



--
Joel Goldstick
http://joelgoldstick.com




== 10 of 14 ==
Date: Fri, Nov 15 2013 6:52 am
From: Robin Becker


On 15/11/2013 14:40, Serhiy Storchaka wrote:
......


>> and then use repr throughout.
>
> Or rather
>
> try:
> ascii
> except NameError:
> ascii = repr
>
> and then use ascii throughout.
>
>

apparently you can import ascii from future_builtins and the print() function is
available as

from __future__ import print_function

nothing fixes all those %r formats to be %a though :(
--
Robin Becker





== 11 of 14 ==
Date: Fri, Nov 15 2013 7:03 am
From: Robin Becker


...........
>> became popular.
>>
> Really? you cried and laughed over 7 vs. 8 bits? That's lovely (?).
> ;). That eighth bit sure was less confusing than codepoint
> translations


no we had 6 bits in 60 bit words as I recall; extracting the nth character
involved division by 6; smart people did tricks with inverted multiplications
etc etc :(
--
Robin Becker




== 12 of 14 ==
Date: Fri, Nov 15 2013 7:07 am
From: Joel Goldstick


On Fri, Nov 15, 2013 at 10:03 AM, Robin Becker <robin@reportlab.com> wrote:
> ...........
>
>>> became popular.
>>>
>> Really? you cried and laughed over 7 vs. 8 bits? That's lovely (?).
>> ;). That eighth bit sure was less confusing than codepoint
>> translations
>
>
>
> no we had 6 bits in 60 bit words as I recall; extracting the nth character
> involved division by 6; smart people did tricks with inverted
> multiplications etc etc :(
> --

Cool, someone here is older than me! I came in with the 8080, and I
remember split octal, but sixes are something I missed out on.
> Robin Becker



--
Joel Goldstick
http://joelgoldstick.com




== 13 of 14 ==
Date: Fri, Nov 15 2013 7:08 am
From: Ned Batchelder


On Friday, November 15, 2013 9:43:17 AM UTC-5, Robin Becker wrote:
> Things went wrong when utf8 was not adopted as the standard encoding thus
> requiring two string types, it would have been easier to have a len function to
> count bytes as before and a glyphlen to count glyphs. Now as I understand it we
> have a complicated mess under the hood for unicode objects so they have a
> variable representation to approximate an 8 bit representation when suitable etc
> etc etc.
>

Dealing with bytes and Unicode is complicated, and the 2->3 transition is not easy, but let's please not spread the misunderstanding that somehow the Flexible String Representation is at fault. However you store Unicode code points, they are different than bytes, and it is complex having to deal with both. You can't somehow make the dichotomy go away, you can only choose where you want to think about it.

--Ned.

> --
> Robin Becker





== 14 of 14 ==
Date: Fri, Nov 15 2013 7:08 am
From: Chris Angelico


On Sat, Nov 16, 2013 at 1:43 AM, Robin Becker <robin@reportlab.com> wrote:
> ..........
>
>> I'm still stuck on Python 2, and while I can understand the controversy
>> ("It breaks my Python 2 code!"), this seems like the right thing to have
>> done. In Python 2, unicode is an add-on. One of the big design drivers in
>> Python 3 was to make unicode the standard.
>>
>> The idea behind repr() is to provide a "just plain text" representation of
>> an object. In P2, "just plain text" means ascii, so escaping non-ascii
>> characters makes sense. In P3, "just plain text" means unicode, so escaping
>> non-ascii characters no longer makes sense.
>>
>
> unfortunately the word 'printable' got into the definition of repr; it's
> clear that printability is not the same as unicode at least as far as the
> print function is concerned. In my opinion it would have been better to
> leave the old behaviour as that would have eased the compatibility.

"Printable" means many different things in different contexts. In some
contexts, the sequence \x66\x75\x63\x6b is considered unprintable, yet
each of those characters is perfectly displayable in its natural form.
Under IDLE, non-BMP characters can't be displayed (or at least, that's
how it has been; I haven't checked current status on that one). On
Windows, the console runs in codepage 437 by default (again, I may be
wrong here), so anything not representable in that has to be escaped.
My Linux box has its console set to full Unicode, everything working
perfectly, so any non-control character can be printed. As far as
Python's concerned, all of that is outside - something is "printable"
if it's printable within Unicode, and the other hassles are matters of
encoding. (Except the first one. I don't think there's an encoding
"g-rated".)

> The python gods don't count that sort of thing as important enough so we get
> the mess that is the python2/3 split. ReportLab has to do both so it's a
> real issue; in addition swapping the str - unicode pair to bytes str doesn't
> help one's mental models either :(

That's fixing, in effect, a long-standing bug - of a sort. The name
"str" needs to be applied to the most normal string type. As of Python
3, that's a Unicode string, which is as it should be. In Python 2, it
was the ASCII/bytes string, which still fit the description of "most
normal string type", but that means that Python 2 programs are
Unicode-unaware by default, which is a flaw. Hence the Py3 fix.

> Things went wrong when utf8 was not adopted as the standard encoding thus
> requiring two string types, it would have been easier to have a len function
> to count bytes as before and a glyphlen to count glyphs. Now as I understand
> it we have a complicated mess under the hood for unicode objects so they
> have a variable representation to approximate an 8 bit representation when
> suitable etc etc etc.

http://unspecified.wordpress.com/2012/04/19/the-importance-of-language-level-abstract-unicode-strings/

There are languages that do what you describe. It's very VERY easy to
break stuff. What happens when you slice a string?

>>> foo = "asdf"
>>> foo[:2],foo[2:]
('as', 'df')

>>> foo = "q\u1234zy"
>>> foo[:2],foo[2:]
('qሴ', 'zy')

Looks good to me. I split a four-character string, I get two
one-character strings. If that had been done in UTF-8, either I would
need to know "don't split at that boundary, that's between bytes in a
character", or else the indexing and slicing would have to be done by
counting characters from the beginning of the string - an O(n)
operation, rather than an O(1) pointer arithmetic, not to mention that
it'll blow your CPU cache (touching every part of a potentially-long
string) just to find the position.

The only reliable way to manage things is to work with true Unicode.
You can completely ignore the internal CPython representation; what
matters is that in Python (any implementation, as long as it conforms
with version 3.3 or later) lets you index Unicode codepoints out of a
Unicode string, without differentiating between those that happen to
be ASCII, those that fit in a single byte, those that fit in two
bytes, and those that are flagged RTL, because none of those
considerations makes any difference to you.

It takes some getting your head around, but it's worth it - same as
using git instead of a Windows shared drive. (I'm still trying to push
my family to think git.)

ChrisA





==============================================================================
TOPIC: Program Translation - Nov. 14, 2013
http://groups.google.com/group/comp.lang.python/t/69cada4c80ff7036?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Nov 15 2013 3:46 am
From: Clive Page


On 14/11/2013 17:36, Gordon Sande wrote:

> Indeed! Under NAGWare Fortran it runs to completion with C=all but pulls an
> undefined reference when C=undefined is added.
>
> Lots of obsolete features and other warnings but no compiler error
> messages.
>
> The obvious lessons are that 1. Fortran has very good historical continuity
> and 2. the good debugging Fortran compilers do a good job.
>
>

I would also check it out with FTNCHEK as well - it usually finds lots
of potential or actual problems with code of this vintage.


--
Clive Page




== 2 of 2 ==
Date: Fri, Nov 15 2013 5:51 am
From: "E.D.G."


"E.D.G." <edgrsprj@ix.netcom.com> wrote in message
news:ro-dnch2dPtbRhnPnZ2dnUVZ_rSdnZ2d@earthlink.com...

The responses regarding that Etgtab program were encouraging. I was
not sure if anyone would even recognize the code as the program was written
quite a while ago.

The main reason for wanting to translate it into modern language code
is so that it can be easily modified and also merged with another computer
program. The main language it would probably be translated into is True
BASIC. This is because the person doing the work is a retired professional
computer programmer who does work like that as a hobby. But he will only
work with True BASIC. In fact he already translated most of the Etgtab
program. The effort got stopped when he could not understand some of the
FORTRAN code. Unlike working personnel, retired people can start and stop
efforts like that as they please.

From discussions with people in several Newsgroups the conclusions I
arrived at in the past few weeks are the following:

Perl would not work because it does calculations too slowly.
Standard Python would also not work for the same reason. However, there are
Python routines available that would make it possible to accelerate the
calculations.

FORTRAN, True BASIC, XBasic, and another language called Julia likely
do calculations fast enough. Julia looks like it is specifically designed
for that type of work.

http://julialang.org/

I am checking with that programmer to see if he wants to continue
with the effort.

The program itself has some importance for earthquake related
research. A number of years ago I checked with the U.S. Government's "Ask A
Geologist" staff to see if they knew about any freeware programs that
researchers could use to generate those types of data. And I was told that
they did not know of any. Apparently they did not even know that Etgtab
exists. I had to do some Internet searches to find it.

The Solid Earth Tide data it generates are probably fairly good. The
plan is to check its ocean tide data against data from the following Web
site to see how well they match.

http://tbone.biol.sc.edu/tide/

We could not find any good freeware programs for generating the types
of sun and moon location data needed for this research and so we wrote one
ourselves. It has been available for a number of years as a freeware
program written in True BASIC.






==============================================================================
TOPIC: Best approach to edit linux configuration file
http://groups.google.com/group/comp.lang.python/t/9834d854a5fbdfa1?hl=en
==============================================================================

== 1 of 2 ==
Date: Fri, Nov 15 2013 5:05 am
From: Himanshu Garg


I have to setup the DNS server. For this I have to edit the configuration files.

For this I have to search if the lines(block of text) already exist in the file and if not, I have to add them to the file.

So, I want to know what is the best way to accomplish this.




== 2 of 2 ==
Date: Fri, Nov 15 2013 5:16 am
From: Chris Angelico


On Sat, Nov 16, 2013 at 12:05 AM, Himanshu Garg <hgarg.india@gmail.com> wrote:
> I have to setup the DNS server. For this I have to edit the configuration files.
>
> For this I have to search if the lines(block of text) already exist in the file and if not, I have to add them to the file.
>
> So, I want to know what is the best way to accomplish this.

Is your script allowed to take complete control of the file, or do you
have to cope with human edits?

If you CAN take control, things are easy. Just keep track of your own
content and match exact lines; as long as you always make consistent
output, you can look for those lines precisely.

But if, as I suspect from your (scanty) description, you can't, then
you'll need to figure out how to identify whether the lines exist or
not. That means text parsing rules. Python can definitely do this;
it's simply a matter of figuring out what you're looking for, what
you're adding, etc.

Configuring DNS is pretty easy for a script to do. I've done it
several times (though only once in Python - other languages other
times).

ChrisA





==============================================================================
TOPIC: Automation
http://groups.google.com/group/comp.lang.python/t/2cb5aaffece4c4a9?hl=en
==============================================================================

== 1 of 3 ==
Date: Fri, Nov 15 2013 6:23 am
From: Mark Lawrence



On 15/11/2013 06:44, Steven D'Aprano wrote:
> On Thu, 14 Nov 2013 17:10:02 +0000, Mark Lawrence wrote:
>
>> On 14/11/2013 03:56, renato.barbosa.pim.pereira@gmail.com wrote:
>>> I apologize again for my bad english and any inconvenience that I have
>>> generated.
>>>
>>>
>> I do wish that people would stop apologising for poor English, it's an
>> extremely difficult language. IIRC there are eight different ways of
>> pronouncing the vowel combination au. Whatever happened to "There
>> should be one-- and preferably only one --obvious way to do it."? :)
>
> Words like "sorry", "pardon me", etc. are the social grease to smooth out
> interactions between people. Instead, I read such apologies as a flag
> that we ought to make allowances for any grammatical or spelling errors
> they may make, rather than to interpret them as signs of laziness or
> stupidity.
>
> I'm inclined to forgive nearly any language error from somebody who is
> trying their best to communicate, while people who merely cannot be
> bothered to use language which is at least an approximation to
> grammatically correct, syntactically valid, correctly-spelled sentences
> inspire similar apathy in me. If they can't be bothered to write as well
> as they are capable of, I can't be bothered to answer their questions.
>
> A few minor errors is one thing, but when you see people whose posts are
> full of error after error and an apparent inability to get English syntax
> right, you have to wonder how on earth they expect to be a programmer?
> Compilers are even less forgiving of errors than is my wife, and she once
> kicked a man to death for using a colon where a semi-colon was required.
> (Only joking. He didn't actually die.)

Semi-colons or more accurately the lack of them, used to be the bain of
my life. Good old CORAL 66 had its BEGIN, END and COMMENT (maybe in
single quotes?), but there was no ENDCOMMENT, no guesses how it was
spelt. Could have retired years ago...

>
> This doesn't apply to people who gave some sort of sign that they're
> doing the best that they can, whether it is due to inexperience,
> dyslexia, being Foreign *wink*, or even broken keyboard. ("Nw kyboard is
> on ordr, pls xcus my lack of lttr aftr D and b4 F.")

I had another wonderful day yesterday hacking foreigners to bits and
burning them, great fun. Is the last part above in parentheses meant to
be related to a broken keyboard or is it simply modern textspeak?

>
> But it does amuse me when non-native English speakers apologise, then
> write a post which is better written, more clear, and far more articulate
> than the native English speakers :-)
>

I wish you'd written "clearer" rather than "more clear", this would have
shown that your English is good like what mine is.

--
Python is the second best programming language in the world.
But the best has yet to be invented. Christian Tismer

Mark Lawrence





== 2 of 3 ==
Date: Fri, Nov 15 2013 6:58 am
From: Grant Edwards


On 2013-11-14, Mark Lawrence <breamoreboy@yahoo.co.uk> wrote:
> On 14/11/2013 03:56, renato.barbosa.pim.pereira@gmail.com wrote:
>> I apologize again for my bad english and any inconvenience that I have generated.
>
> I do wish that people would stop apologising for poor English, it's an
> extremely difficult language.

It's certainly not necessary from anybody for whom English is not a
first language -- and that's usually pretty easy to guess based on
domains and personal names.

There are people (not many in this group) who grew up speaking English
and really ought to apologize for their writing -- but they never do.

So a good rule of thumb is:

If you think maybe you need to apologize for your English, you don't

If it never occurred to you that you need to apologize, you might.

;)

--
Grant Edwards grant.b.edwards Yow! Let's all show human
at CONCERN for REVERAND MOON's
gmail.com legal difficulties!!




== 3 of 3 ==
Date: Fri, Nov 15 2013 7:02 am
From: Grant Edwards


On 2013-11-15, Paul Rudin <paul.nospam@rudin.co.uk> wrote:
> Steven D'Aprano <steve+comp.lang.python@pearwood.info> writes:
>
>> A few minor errors is one thing, but when you see people whose posts are
>> full of error after error and an apparent inability to get English syntax
>> right, you have to wonder how on earth they expect to be a programmer?
>
> The irritating thing is apparent lack of care. A post is written once
> and will be seen (perhaps not read) by many people. People post with the
> intention of others reading their words. If they can't be bothered to
> take a little care in writing, why should we spend time reading?

Just because English is your second language it doesn't mean you don't
need to pay attention to what keys you're hitting and proof-read a
posting before hitting "send".

And yes, people can _easily_ tell the difference between errors caused
by being lazy/sloppy and errors caused by writing in a second
language.

--
Grant Edwards grant.b.edwards Yow! Let me do my TRIBUTE
at to FISHNET STOCKINGS ...
gmail.com




==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.python"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.python?hl=en

To unsubscribe from this group, send email to comp.lang.python+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.python/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en