Thanks.
The problem is mostly when code from different people using different tools needs to be combined, or sample code from the internet (not from the well-behaved ones like github and stackoverflow) has to be tested and understood.
Of course it is fun to discover the lost intentions of the original programmer, but it is not practical in a day job.
QUOTE
Because we *already have it*: the character is ' '.

UNQUOTE

The problem with ' ' is that a sequence of ' 's can't easily be counted, especially on feature rich editors.

A sequence of '.' or some visible character can be counted.

Of course, with the previous line being continued on the current line, '.' could present problems, as Andrew B. points out, and they can be messy.

Could the solution lie in providing a "transfer" or "import-export" mode in editors where the indentation is given in terms of a chosen special character which is converted to spaces/tabs?

Thanks again

MK-Zedobject

On Sat, Aug 30, 2014 at 11:02 AM, Stephen J. Turnbull <stephen@xemacs.org> wrote:

Milind Khadilkar writes:

> Besides, spaces become difficult to count and distinguish from
> tabs, adding to the problem. (Why allow tabs at all?)

Working code should not be broken gratuitously. Sure, it was an
unfortunate decision in the first place, but we can't change that
original decision now.

> Why can't Python be made to accept the following indentation of

> code (in *addition* to the current schemes)?

Because we *already have it*: the character is ' '. If *you* follow
that rule, you won't have problems copy/pasting your own code into
well-behaved code. If you're working with somebody else's code which
mixes tabs and spaces, *using an alternative character doesn't help*,
whether the "bad" code is source or target.