Spot The Error

  • Thread starter Lawrence D'Oliveiro
  • Start date
L

Lawrence D'Oliveiro

<http://www.python.org/dev/peps/pep-0008/>

Block Comments

Block comments generally apply to *some (or all) code that follows*
them, and are indented to the same level as that code. Each line of a
block comment starts with a # and a single space (unless it is indented
text inside the comment).

Paragraphs inside a block comment are separated by a line containing a
single #.

So, feel free to rewrite my example following PEP-8. Is the result easier or
harder to understand?
 
L

Lawrence D'Oliveiro

Andreas Leitgeb said:
I also tried to get into Python once. I was disappointed by that it didn't
have a general for-loop (that thing with ini,cond,incr&body parts), and
when I asked about it in comp.lang.python, they treated me similar to how
they treated you here for asking for ordered boolean: claiming that no one
would ever really need it, and offering work-arounds even much uglier than
bool?1:0. This, and the fact that editors rarely have a feature to bring
me to start/end of current block with python's sense of a block, while
giving me some handy key-strokes to find next outer open or close brace,
made me drop python like a hot stone. And this, although I liked the then-
new generators (co-routines).

Some Python aficionados, but not all of them, have enough experience across
a broad range of languages to have some perspective about things. How would
you compare your experience in that group versus this one? I get the feeling
the experience among this lot is a bit more narrow.

As for indentation control, after some years’ experience, I’ve come to the
conclusion that it’s not exactly the most brilliant feature of Python. (And
yes, that remark has earned me a lot of hatred from other Python
enthusiasts.) But I still think Python is a fantastic language regardless.
It’s definitely worth the time you invest in learning it.

With regard to looping, something like 90% of my loops can be written in the
equivalent of

for (;;)
{
...
if (cond)
break;
...
} /*for*/

often with more than one conditional break inside. In Python I can do it
with “while True :†of course. I’m reluctant to write something like

for item in ListBeingSearched :
...
if FoundWhatImLookingFor :
break
...
#end for

because that loop has one exit condition in its head and another in its
body; if there’s an exit condition in the body, I like to ensure they’re all
in the body, no mixing head+body.

Here’s a simple example of searching with an iterator in C++:

static bool HasFeatureIDParams()
/* returns true iff the CGI parameters include any for selecting
distinguishing features. */
{
bool HasSuchParams;
for (StringLister Param = cgi.Params.begin();;)
{
if (Param == cgi.Params.end())
{
HasSuchParams = false;
break;
} /*if*/
if (BeginsWith(Param->first, FeatureIDPrefix))
{
HasSuchParams = true;
break;
} /*if*/
++Param;
} /*for*/
return
HasSuchParams;
} /*HasFeatureIDParams*/

In Python this would be more awkward, mainly because you’re forced to bring
in exception handling:

def HasFeatureIDParams() :
Params = iter(cgi.Params)
while True :
try :
Param = Params.next()
except StopIteration :
HasSuchParams = False
break
#end try
if Param.first.startswith(FeatureIDPrefix)) :
HasSuchParams = True
break
#end if
#end while
return HasSuchParams
#end HasFeatureIDParams

(No, I don’t like embedding return statements in the middle of my code
either.)

But otherwise, Python iterators are absolutely wonderful things. For
example, complex database manipulations are so much easier to handle in
Python than in Java.
 
L

Lawrence D'Oliveiro

On 2/21/2011 7:22 AM, Lawrence D'Oliveiro wrote:

In message<[email protected]>, Kevin McMurtrie
wrote:

Formatting comments incorrectly so they don't appear in the IDE?

Which “IDE†would that be, then?

He is referring to the use of Javadoc comments. Instead of

public byte[] ReceiveChunk()
/* receives a complete chunk from the connection. */


You should write

/* receives a complete chunk from the connection. */
public byte[] ReceiveChunk()


This will allow the IDE to display the comment when you hover your mouse
above references to this method.

Why can’t this “IDE†handle the more natural style?

It is more common to have comments before. Whether common
implies natural is pretty subjective.

Except that comment sentence (above) expects to have its subject before, not
after.
But it does not matter. javadoc is a program, program expects
input in a certain format, javadoc expects comments
before, this is well documented, in fact it should be
in every Java beginner book.

I have seen plenty of javadoc-generated stuff on the Web. It doesn’t make me
any more enthusiastic to use it.
 
M

markspace

So, feel free to rewrite my example following PEP-8. Is the result easier or
harder to understand?


The point was your assertion that your comments in the Java you posted
were somehow more "natural" and therefore better. And the link I posted
refuted the idea that putting comments first came naturally to Python.

I found Lew's corrected example to be much easier to read. (I.e., the
"rewrite" has already been done.) And I find Java docs even easier
after they are compiled.

I think if you try to continue to assert that you have the one true way,
you'll continue to get shot down. As the Python page pointed out, "a
foolish consistency is the hobgoblin of little minds." Trying to use
what worked well for you in Python, or C, or C++ isn't necessarily going
to work well for Java.

We have Javadoc comments for a reason, because the tool uses that
format. Trying to reinvent that wheel is just going to make your source
incompatible with every other Java build process on the planet, for no
gain at all that I can see. Try to understand Java's process before you
try to rail against it.
 
M

markspace

Which were?


<http://www.gotw.ca/publications/c_family_interview.htm>

Gosling: For me as a language designer, which I don't really count
myself as these days, what "simple" really ended up meaning was could I
expect J. Random Developer to hold the spec in his head. That definition
says that, for instance, Java isn't -- and in fact a lot of these
languages end up with a lot of corner cases, things that nobody really
understands. Quiz any C developer about unsigned, and pretty soon you
discover that almost no C developers actually understand what goes on
with unsigned, what unsigned arithmetic is. Things like that made C
complex. The language part of Java is, I think, pretty simple. The
libraries you have to look up.
 
L

Lawrence D'Oliveiro

The point was your assertion that your comments in the Java you posted
were somehow more "natural" and therefore better. And the link I posted
refuted the idea that putting comments first came naturally to Python.

How did it refute it? Illustrate.
 
J

Joshua Cranmer

Except that comment sentence (above) expects to have its subject before, not
after.

Plenty of languages do not have an SVO sentence order; even English
eschews it some more poetic styles.
I have seen plenty of javadoc-generated stuff on the Web. It doesn’t make me
any more enthusiastic to use it.

When in Rome, do as the Romans do. Javadoc is the most common
documentation generator for Java, and it is a standard which has
partially percolated into other curly-brace languages (Doxygen and
PHPdoc both sport a similar style, as does JSdoc IIRC).
 
J

Joshua Cranmer

Some Python aficionados, but not all of them, have enough experience across
a broad range of languages to have some perspective about things. How would
you compare your experience in that group versus this one? I get the feeling
the experience among this lot is a bit more narrow.

I have coded non-trivial programs in Basic, JavaScript, Java, Python,
Ruby, PHP, assembly (a few different variants), C, C++, Smalltalk,
Matlab, bash, and FORTRAN (in no particular order). Yes, I am lacking in
the functional language department, although my usage of JavaScript is
mostly tied into a single implementation (SpiderMonkey, to be specific)
which allows me to use more of its functional features.

On the other hand, I have fallen in love with features supported by none
of those languages (okay, Smalltalk has it, but I am so unfamiliar with
its library that it's easier for me to kludge through, say, Python
instead of learn it just for a feature), e.g., continuations. So it's
not like I'm narrow-minded when it comes to language features.
 
A

Arved Sandstrom

Some Python aficionados, but not all of them, have enough experience across
a broad range of languages to have some perspective about things. How would
you compare your experience in that group versus this one? I get the feeling
the experience among this lot is a bit more narrow.

That's a bit rich coming from a guy who's made sweeping statements about
how boolean datatypes behave in all languages that he knows (that
assertion narrowed things down a lot), who just in this thread made
sweeping statements about comments that actually apply to a minority of
languages, who is obviously a Java novice (no harm in that), who pretty
clearly is also a C# (and most likely .NET managed language) novice
because otherwise some of his Java questions would never have been
asked, and who has demonstrated a somewhat naive understanding of
C++...among other things.

I am also minded about some disparaging comments you've made about
corporate programming - those smack of comments made by someone who's
done little or no such programming. Which in turn removes a gigantic
chunk of potential experience from _your_ portfolio.

How many years of COBOL do you have under your belt? Have you had to use
any other business languages like Natural? Any or lots of programming
experience in environments like CICS, or using EISs like SDAP,
PeopleSoft, Siebel or JD Edwards? Have you spent months of quality time
learning the intricacies of enterprise Oracle DB, or DB2, or working
close to the bare metal with ISAM-type files? Are you happy with your
thorough command of transactions in various environments? Have you spent
a year or two wrestling with various ESB or BPEL/BPM or business rules
implementations? Do you have decent experience with documents and
records management systems, or eForms of any type?

Maybe you spent most of your time working in scientific programming -
fair enough. So you're a FORTRAN and C (won't ask about C++, we know
where you stand with that) and awk/gawk and Matlab/MAPLE/Mathematica and
custom data processing language expert then, I take it. For starters.

Or maybe you're more an academic. Maybe you have excellent command of
functional languages like ML and Haskell and OCaml, and logic languages
like Prolog, and you can write rings around most people using a LISP
variant or with Self. Somehow I doubt it.

For what it's worth that last paragraph doesn't apply to me - I dabble
in those languages but am by no means adept. But the previous two
paragraphs do, and it took quite a few decades of work to get there. And
there are guys posting here who clearly know more than I do. You may
have noticed that we tend to back up our statements with facts and
references (admittedly, sometimes upon request).

You don't have to believe me, or anyone else's declaration of
experience, and personally I don't care. But you could investigate your
own CV and honestly assess how you stack up before making observations
about others.
As for indentation control, after some years’ experience, I’ve come to the
conclusion that it’s not exactly the most brilliant feature of Python. (And
yes, that remark has earned me a lot of hatred from other Python
enthusiasts.) But I still think Python is a fantastic language regardless.
It’s definitely worth the time you invest in learning it.

It's a decent language, sure. I don't know about "fantastic" - in 30+
years I haven't personally encountered a "fantastic" programming
language - but it's OK.

[ SNIP ]
(No, I don’t like embedding return statements in the middle of my code
either.)

Off and on, depending on team and client site and project, there's a
programmer or two that I work with that makes occasional comments like
this. Usually tossed out off-hand at meetings where some managers are
present. Often used to belittle junior programmers.

Have you actually thought this through, considering a wide variety of
languages and available function/method exit strategies, or did you just
read it somewhere and decide to parrot it?
But otherwise, Python iterators are absolutely wonderful things. For
example, complex database manipulations are so much easier to handle in
Python than in Java.

??? This coming from a guy who is just learning Java, and hasn't
probably used JPA in his life. Remarkable.

AHS
 
L

Lew

Plenty of languages do not have an SVO sentence order; even English eschews it
some more poetic styles.


When in Rome, do as the Romans do. Javadoc is the most common documentation
generator for Java, and it is a standard which has partially percolated into
other curly-brace languages (Doxygen and PHPdoc both sport a similar style, as
does JSdoc IIRC).

Why the hell is that ***hole arguing against a documented requirement of the
tool? Doesn't the documentation for the tool itself provide the final answer?

Apparently "Lawrence" is so committed to trollishness that he'll say really,
really stupid things just to prolong the argument. That's assuming he's
capable of saying things that aren't stupid, an assertion which so far here
completely lacks evidence.
 
M

Martin Gregorie

??? This coming from a guy who is just learning Java, and hasn't
probably used JPA in his life. Remarkable.
Hmmm, I see at most minimal differences between the complexity of
handling relational databases and regexes in Java and Python. The method
names may differ, but the order in which corresponding methods are called
and the logic used to call them are very similar. This applies reagerless
of whether you're using PostgresQL via jdbc or Python's pgsql or pyodbc
modules. WRT regexes, the java.util.regex package and the Python re
module are even more similar: if you can use one, the other is child's
play.
 
L

Lawrence D'Oliveiro

Hmmm, I see at most minimal differences between the complexity of
handling relational databases and regexes in Java and Python. The method
names may differ, but the order in which corresponding methods are called
and the logic used to call them are very similar. This applies reagerless
of whether you're using PostgresQL via jdbc or Python's pgsql or pyodbc
modules. WRT regexes, the java.util.regex package and the Python re
module are even more similar: if you can use one, the other is child's
play.

OK then, here’s a database conversion script I wrote recently for a client
(because they still think of data analysis in terms of using Excel).

provider_fields = \
( # everything except id
"id_code",
"update_id",
... total of 39 fields ...
)
provider_contact_fields = \
( # excluding Region, District & Town (separately handled)
"Physical_Address",
... only 8 fields here ...
)

sys.stdout.write \
( # column headers
",".join
(
quote_csv(f)
for f in
(
provider_fields
+
provider_contact_fields
+
("Region", "District", "Town")
+
... extra fields ...
)
)
+
"\n"
)

# now for the actual records
for \
record \
in \
sqlite_useful.GetEachRecord \
(
Conn = db,
TableName =
"provider inner join provider_contact on provider.id = provider_contact.provider_id"
" inner join location_region on location_region.region_id = provider_contact.Region"
" inner join location_district on"
" location_district.district_id = provider_contact.District"
" inner join location_town on location_town.town_id = provider_contact.town",
Fields =
["provider.id"]
+
list("provider.%s" % f for f in provider_fields)
+
list("provider_contact.%s" % f for f in provider_contact_fields)
+
[
"location_region.region as region",
"location_district.district as district",
"location_town.town as town",
],
Extra =
"order by provider.Name, provider.Organisation_name, provider_contact.Physical_Address,"
" location_region.region, location_district.district, location_town.town"
) \
:
... extra processing I won't bore you with ...
sys.stdout.write \
(
",".join
(
quote_csv(v)
for v in
(
list(record["provider.%s" % f] for f in provider_fields)
+
list(record["provider_contact.%s" % f] for f in provider_contact_fields)
+
list(record[f] for f in ("region", "district", "town"))
+
... extra fields ...
)
)
+
"\n"
)
#end for

Notice how heavily data-driven it is? In particular, how I can easily
add/remove fields in that giant “provider†table with minimal changes to the
script.

Try writing an equivalent in Java, and see how much code you end up with.
 
M

Martin Gregorie

Notice how heavily data-driven it is? In particular, how I can easily
add/remove fields in that giant “provider†table with minimal changes to
the script.

Try writing an equivalent in Java, and see how much code you end up
with.

I don't see anything there that I couldn't do as easily in Java and, more
to the point:

- by writing
"... extra processing I won't bore you with ... sys.stdout.write"
you've negated your own point: there is stuff you've left out that
is entirely relevant and makes it impossible to tell just how short
your actual code is.

- Since you're not using the DB-API 2.0 interface for SQLite you've
either omitted at least one module import or a large chunk of code.
Either way you've omitted essential items that prevent us from
running your code against SQLite or indeed any other SQL database.

- for a true data driven program you wouldn't need to build the data in
provider_*_fields into the program: it would by pulled in from external
files.
 
A

Andreas Leitgeb

Lawrence D'Oliveiro said:
Some Python aficionados, but not all of them, have enough experience across
a broad range of languages to have some perspective about things. How would
you compare your experience in that group versus this one?

It's in the nature of Python, that most who know it, are likely
to know also other languages - namely for doing serious stuff ;-)

Anyway, I no longer remember the details of the discussions. I only
remember not having seen there a comment as tasteless as Owen J.'s.
 
L

Lawrence D'Oliveiro

- by writing
"... extra processing I won't bore you with ... sys.stdout.write"
you've negated your own point: there is stuff you've left out that
is entirely relevant and makes it impossible to tell just how short
your actual code is.

Are you trying to say that, if I told you what was in the ellipses, it would
make the Java code SIMPLER?

You’re really grasping at straws.
- Since you're not using the DB-API 2.0 interface for SQLite you've
either omitted at least one module import or a large chunk of code.
Either way you've omitted essential items that prevent us from
running your code against SQLite or indeed any other SQL database.

You mean, the GetEachRecord routine? Sure, I can get into that if you want.
I was just trying to reduce the shock of exposure to the power of Python for
those who haven’t encountered it before.
- for a true data driven program you wouldn't need to build the data in
provider_*_fields into the program: it would by pulled in from external
files.

Fine, do that if you prefer. It just removes 40 or so lines of code from a
Python script which is already down to about 200 lines.
 
L

Lawrence D'Oliveiro

I am also minded about some disparaging comments you've made about
corporate programming - those smack of comments made by someone who's
done little or no such programming. Which in turn removes a gigantic
chunk of potential experience from _your_ portfolio.

Wow, I really stepped on some toes, didn’t I? Corporate programming is the
very antithesis of creativity and flexibility: its stultifying insistence on
following rigid procedure promotes mediocrity and suppresses original
thought. It’s no wonder that major enterprise IT projects regularly run over
time and over budget, and worse still, are obsolete before they can even be
deployed.

I look at C++, and I see a complicated, unwieldy class structure that is a
natural fit for the hierarchical management structures at such large
corporations. I look at Java, and it manages to achieve pretty much the same
thing. Conway’s Law works both ways.

Economic fact: most of the world’s GDP comes from small businesses, not
large ones. Large corporations tend to be a drag on innovation more often
than they are a driver of it.
How many years of COBOL do you have under your belt?

I did it for a year, in my first job after leaving University, after
avoiding studying it as part of my Computer Science degree. I did it because
nobody else at the software firm I was with wanted to touch it.

And let’s face it, Java fans, the highest-paid programming jobs in the world
right now are still the COBOL ones, because there is still more COBOL code
in use than Java, and it’s getting harder and harder to find programmers who
understand any of it.
 
M

Martin Gregorie

Are you trying to say that, if I told you what was in the ellipses, it
would make the Java code SIMPLER?

You’re really grasping at straws.
Not at all - I want to see what you conveniently left out. That includes
code needed to shut down cleanly, which is entirely missing. Omitting
that is scarcely professional even for a one-off script.
You mean, the GetEachRecord routine? Sure, I can get into that if you
want. I was just trying to reduce the shock of exposure to the power of
Python for those who haven’t encountered it before.
Since that apparently isn't a standard library module, of course the code
in it is relevant.
Fine, do that if you prefer. It just removes 40 or so lines of code from
a Python script which is already down to about 200 lines.
In Java all that can be sucked in with under 10 statements as a property
list and writing a completely general purpose RDBMS -> CSV converter
would be a fairly trivial exercise.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,774
Messages
2,569,599
Members
45,175
Latest member
Vinay Kumar_ Nevatia
Top