#include <math.h>

[Dan Pop]

Out of interest and for the benefit of the OP, does the standard have
anything to say about linkage?

Quite a lot. But it is quite quiet about linking.

Dan

 

[Les Cargill]

Certainly GNU make because I read it there and tried it and it worked. I
cannot know and don't care much about all other make programs. By the
same token I don't know that TAB is the separator other make programs.
To the extent that TAB was chosen by make's original author (Who?)

Richard Stallman.

it
seems arbitrary and badly chosen.

It's a way. Python seems to have reinvented this "error".

 

[Jeremy Yallop]

It's a way. Python seems to have reinvented this "error".

Python accepts both tabs and spaces as indentation. There's no need
to use tabs if you don't want to.

Jeremy.

 

[Les Cargill]

Python accepts both tabs and spaces as indentation. There's no need
to use tabs if you don't want to.

Right! I meant it's still indentation-based, which is odd in this
day and age.

 

[August Derleth]

Right! I meant it's still indentation-based, which is odd in this
day and age.

But Python's indentation rules follow the informal format of all other
Algol-based languages. What you are forced to do in Python is merely
what you should be doing in C and Pascal and such anyway.

If you absolutely despise whitespace, one space character works just
fine. There's no concept of sacred columns that Fortran and other
punch-card-based languages plagued us all with Back In The Day.

A small example:

def my_abs(x):
if x <= 0:
return x
else:
return -x

There. Done. That's as obnoxious as the rules get. Emacs even does it
for you (the newline key is electric in Python mode, so Emacs will
auto-indent whenever you end a line).

 

[gswork]

About /linking/ refer to ISO/IEC 9899:1999 5.1.1.2#8.

About /linkage/ refer to 6.2.2., 6.7, 6.7.4, 6.7.5.2, 6.9,
6.9.2, 6.11.2, ...

HTH
Regards

Thanks for the references

 

[Richard Bos]

But Python's indentation rules follow the informal format of all other
Algol-based languages. What you are forced to do in Python is merely
what you should be doing in C and Pascal and such anyway.

No, it isn't.

I'm not sure if Python's equivalent of this is legal...

int function(struct object * const first_source,
struct object * const second_source,
struct object * destination)
{
/* Do something */
}

....but Python's equivalent of this certainly isn't...

if (first_object ->wibble_counter > maximum_wibbles ||
second_object->wibble_counter > maximum_wibbles)
return -1;

....and if a language doesn't allow me to make my code more readable by
being creative with indentation like that, it goes into the bin for
being too uppity for its own good.

One of the reasons why I like C is that, if _I_ decide something is more
legible the way I like it, the language doesn't stop me from maintaining
my code in a year or two.

Richard

 

[Jeremy Yallop]

I'm not sure if Python's equivalent of this is legal...

int function(struct object * const first_source,
struct object * const second_source,
struct object * destination)
{
/* Do something */
}

You can certainly write something equivalent to that in Python, since
most objects are mutable, and calling a function passes references to
arguments by value. By this I mean that when you pass an argument to
a function the object (e.g. the "struct") is bound to the parameter
name within the function body. Consequently, the object is available
for modification within the function, but if the parameter name
appears on the left side of an assignment expression then the name is
simply rebound and the object is not modified. It's rather similar to
what you have above: the effects of assignments to destination->foo
are visible outside the function, but assignments to destination
itself are not.

class Foo:
def __init__(self, val):
self.value = val

# set the value of `output' to the sum of the values of
# `first_source' and `second_source'. Return half of the final
# value of `output'
def function(first_source, second_source, output):
# modify the object to which `output' is bound.
output.value = first_source.value + second_source.value
return output.value / 2

# Probably not what was intended
def function_2(first_source, second_source, output):
# rebind output within `function_2'. No effect once the
# function returns
output = first_source, second_source

...but Python's equivalent of this certainly isn't...

if (first_object ->wibble_counter > maximum_wibbles ||
second_object->wibble_counter > maximum_wibbles)
return -1;

This is written

if (first_object .wibble_counter > maximum_wibbles or
second_object.wibble_counter > maximum_wibbles):
return -1

Jeremy.

 

[Les Cargill]

But Python's indentation rules follow the informal format of all other
Algol-based languages. What you are forced to do in Python is merely
what you should be doing in C and Pascal and such anyway.

That doesn't matter. It's like designing a TV video section that
can only support PAL and not NTSC - it's an unnecessary constraint.

In this day and age of language design tools, it's unnecessary. Any
resonance with card image formatting is archaic.

If you absolutely despise whitespace,

I don't, and that is not the point at all.

Curly braces are cheap, explicit and very visible. They make fine
delimiters.

one space character works just
fine. There's no concept of sacred columns that Fortran and other
punch-card-based languages plagued us all with Back In The Day.

A small example:

def my_abs(x):
if x <= 0:
return x
else:
return -x

There. Done. That's as obnoxious as the rules get.

It's not that onerous, but the fine details add up.

 

[Richard Bos]

You can certainly write something equivalent to that in Python, since
most objects are mutable, and calling a function passes references to
arguments by value.

I wasn't talking about the semantics, merely about the indentation.

This is written

if (first_object .wibble_counter > maximum_wibbles or
second_object.wibble_counter > maximum_wibbles):
return -1

Like bloody hell it is. That is _not_ as legible. In fact, it isn't even
in the same ballpark. And that's even without considering three levels
of indentation.

Richard

 

[Jeremy Yallop]

I wasn't talking about the semantics, merely about the indentation.

Okay.

def function(first_source,
second_source,
destination):
# do something

There's no *need* to write like this in Python, though: the signature
doesn't include all the type information, so the parameter list is
shorter. It's sometimes useful for comments about each parameter:

def function(first_source, # some comment
second_source, # something else
destination): # and some more
# do something

but I can't imagine many other situations where it would be used.
Still, if you want to indent your code like that, nobody will stop
you.

Like bloody hell it is. That is _not_ as legible.

If you want, you change the indentation of the return statement.
There's no need to lose your temper.

if (first_object .wibble_counter > maximum_wibbles or
second_object.wibble_counter > maximum_wibbles):
return -1

is fine, too.

Jeremy.

 

[Richard Bos]

If you want, you change the indentation of the return statement.
There's no need to lose your temper.

if (first_object .wibble_counter > maximum_wibbles or
second_object.wibble_counter > maximum_wibbles):
return -1

is fine, too.

Not in any version of Python I've used.

Richard

 

[Jeremy Yallop]

Not in any version of Python I've used.

I tried it on various versions of Python, from 1.0.1 (February 1994)
to 2.3 (October 2003) and they all accepted it without problems.

Jeremy.

 

[Mark McIntyre]

Seems that would be easy enough to solve. Open Source,

Sure, but that wasn't the question was it?