Hi,

I've a project with tabs and spaces mixed (yes I know it's bad).

I edit each file to remove tabs, but it's so easy to make a mistake.
Do you know a tools to compare the initial file with the cleaned one to 
know if the algorithms are the same ?
By comparing pyc files for example.

Thanks.

> I've a project with tabs and spaces mixed (yes I know it's bad).
> 
> I edit each file to remove tabs, but it's so easy to make a mistake.
> Do you know a tools to compare the initial file with the cleaned one to
> know if the algorithms are the same ?
> By comparing pyc files for example.

Tools/scripts/reindent.py of the standard Python distribution normalizes
white space in source code. It is used to maintain normalized
indentation in the Python library itself, but you can certainly use it
also for your own files :-)

Regards,
Martin

Le 31/10/2010 13:10, Martin v. Loewis a �crit :
>> I've a project with tabs and spaces mixed (yes I know it's bad).
>>
>> I edit each file to remove tabs, but it's so easy to make a mistake.
>> Do you know a tools to compare the initial file with the cleaned one to
>> know if the algorithms are the same ?
>
> Tools/scripts/reindent.py of the standard Python distribution normalizes
> white space in source code.

So great, you save my time !
Should I be worry about this comment in reindent.py "So long as the 
input files get a clean bill of health from tabnanny.py, reindent should 
do a good job." ?

Thanks

> Should I be worry about this comment in reindent.py "So long as the
> input files get a clean bill of health from tabnanny.py, reindent should
> do a good job." ?

I don't think so: IIUC, this is about comments that are not reasonably
aligned with preceding or following code lines, most likely, you don't
have such comments in your files.

Regards,
Martin

In message <4ccd5ad9$0$19151$426a74cc@news.free.fr>, jf wrote:

> I edit each file to remove tabs ...

    expand -i <oldfile >newfile

> Do you know a tools to compare the initial file with the cleaned one to
> know if the algorithms are the same ?

    diff -b oldfile newfile

in 645437 20101031 230912 Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>In message <4ccd5ad9$0$19151$426a74cc@news.free.fr>, jf wrote:
>
>> I edit each file to remove tabs ...
>
>expand -i <oldfile >newfile
>
>> Do you know a tools to compare the initial file with the cleaned one to
>> know if the algorithms are the same ?
>
>diff -b oldfile newfile

meld

On Mon, 01 Nov 2010 12:09:12 +1300, Lawrence D'Oliveiro wrote:
> In message <4ccd5ad9$0$19151$426a74cc@news.free.fr>, jf wrote:
>
>> I edit each file to remove tabs ...
>
>     expand -i <oldfile >newfile
>
>> Do you know a tools to compare the initial file with the cleaned one to
>> know if the algorithms are the same ?
>
>     diff -b oldfile newfile

Warning: "diff -b" won't detect changes in indentation.  Changes in
indentation can change a Python program.

-- 
To email me, substitute nowhere->spamcop, invalid->net.

In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:

> On Mon, 01 Nov 2010 12:09:12 +1300, Lawrence D'Oliveiro wrote:
>
>> In message <4ccd5ad9$0$19151$426a74cc@news.free.fr>, jf wrote:
>>
>>> I edit each file to remove tabs ...
>>
>>     expand -i <oldfile >newfile
>>
>>> Do you know a tools to compare the initial file with the cleaned one to
>>> know if the algorithms are the same ?
>>
>>     diff -b oldfile newfile
> 
> Warning: "diff -b" won't detect changes in indentation.  Changes in
> indentation can change a Python program.

I’m getting less and less keen on that particular feature of Python...

On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>
>>>     diff -b oldfile newfile
>> 
>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>> indentation can change a Python program.
>
> I'm getting less and less keen on that particular feature of Python...

Why?

Other languages have similar problems if you remove salient bits of
syntax before comparing two source files files.

For exmaple, if you remove all of the curly-braces from two C source
files before comparing them, you don't get useful results.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm continually AMAZED
                                  at               at th'breathtaking effects
                              gmail.com            of WIND EROSION!!

On Mon, 1 Nov 2010 22:24:03 +0000 (UTC), Grant Edwards wrote:
> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>>
>>>>     diff -b oldfile newfile
>>> 
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.
>>
>> I'm getting less and less keen on that particular feature of Python...
>
> Why?
>
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.
>
> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.

True, but diff doesn't come with an "ignore curly braces" option.
I'm not personally repelled by Python's use of significant indentation,
but I must concede that some awkwardness results from assigning
significance to something (whitespace) that many tools are inclined
to treat as insignificant.

-- 
To email me, substitute nowhere->spamcop, invalid->net.

On 11/1/2010 3:18 PM Lawrence D'Oliveiro said...
> In message<8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
<snip>
>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>> indentation can change a Python program.
>
> I’m getting less and less keen on that particular feature of Python...

That feature being indentation based structure?  At least you can look 
at python code and _know_ that spurious placement of required line noise 
don't have the ability to impact what the code does.

Emile

In message <mailman.465.1288653523.2218.python-list@python.org>, Emile van 
Sebille wrote:

> At least you can look at python code and _know_ that spurious placement of
> required line noise don't have the ability to impact what the code does.

But it does. What is spurious whitespace if not noise, after all?

On Nov 1, 4:48=A0pm, Peter Pearson <ppear...@nowhere.invalid> wrote:
> True, but diff doesn't come with an "ignore curly braces" option.
> I'm not personally repelled by Python's use of significant indentation,
> but I must concede that some awkwardness results from assigning
> significance to something (whitespace) that many tools are inclined
> to treat as insignificant.

Beyond Compare at least is smart enough to know that leading
whitespace is significant in .py files, using the default
configuration.

Cheers,
Ian

On 2010-11-01, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.

>> I'm getting less and less keen on that particular feature of Python...

> Why?

> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.

Sure.

> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.

Right.

But there's no *reason* to do that, while there are many common daily
events which result in whitespace changes.  e.g., any email sent
to my work account is being magically transformed into HTML (no one
knows why) on the server, so I can't get correct indentation except
in attachments.  Many editors helpfully convert spaces to tabs
by default some or all of the time.  And so on.

The more I use it, the more I think it was an interesting experiment
which has worked out about as well as scanf.  The "problem" it fixes
is something that's hardly ever been a problem for me in C or
related languages -- and which could be completely eliminated by
automated indenters, which were actually conceptually possible.

I've lost more time to indentation issues in Python in a month than
I've lost to mismatches between indentation and flow in C in twenty
years.  In theory, it sounds like it would help to eliminate the
ambiguity.  In practice, eliminating the question of whether code
was intended to follow explicit flow rather than indentation just
means that when there's a mistake you don't even get a warning that
someone was confused.

At least in C, if I see:
	if (foo)
		a;
	else
		b;
		c;

I *know* that something is wrong.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 02 Nov 2010 04:16:28 GMT
Seebs <usenet-nospam@seebs.net> wrote:
> But there's no *reason* to do that, while there are many common daily
> events which result in whitespace changes.  e.g., any email sent
> to my work account is being magically transformed into HTML (no one
> knows why) on the server, so I can't get correct indentation except
> in attachments.  Many editors helpfully convert spaces to tabs
> by default some or all of the time.  And so on.

You have problems.  Indentation as syntax isn't one of them.  "No one
knows why" email is being "magically" transformed?  Your editor has a
mind of its own?  Yikes!

> I've lost more time to indentation issues in Python in a month than
> I've lost to mismatches between indentation and flow in C in twenty

Your experience is 180 from mine.

> years.  In theory, it sounds like it would help to eliminate the
> ambiguity.  In practice, eliminating the question of whether code
> was intended to follow explicit flow rather than indentation just
> means that when there's a mistake you don't even get a warning that
> someone was confused.
> 
> At least in C, if I see:
> 	if (foo)
> 		a;
> 	else
> 		b;
> 		c;
> 
> I *know* that something is wrong.

Does it look right?  With Python looking right and being right are the
same thing.  Once I realized that indentation should only be done using
spaces in Python I never had a problem.  I certainly had problems with
C when the code looked right.  Sometimes you can't even see the problem
because it's hidden in a badly defined macro.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

In message <slrnicv44s.9it.usenet-nospam@guild.seebs.net>, Seebs wrote:

> At least in C, if I see:
>        if (foo)
>                a;
>        else
>                b;
>                c;
> 
> I *know* that something is wrong.

This is why, when I started learning Python, I soon developed the habit of 
inserting explicit “#end” markers. To Pythonize your example my way, it 
would have come out as

        if foo :
                a
        else :
                b
        #end if
                c

which should also give a hint that something might be wrong.

On Mon, 01 Nov 2010 22:24:03 +0000, Grant Edwards wrote:

> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
> wrote:
[...]
>> I'm getting less and less keen on that particular feature of Python...
> 
> Why?
> 
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.
> 
> For exmaple, if you remove all of the curly-braces from two C source
> files before comparing them, you don't get useful results.

Ah, but other languages don't make the guarantee that you can add or 
remove random whitespace in arbitrary places and still have code that 
works correctly!

Of course, neither does Python, but there's a certain type of personality 
that is never happy unless they are bitching and moaning, and if they 
can't find something more substantial to bitch and moan about, they'll 
bitch and moan about the fact that they can't make random changes to 
syntactically significant tokens in their source code without things 
breaking. Boo hoo, cry me a river.

Personally, I'm more disturbed by the default prompt in the interactive 
interpreter. >>> clashes with the symbol used for quoting text in email 
and news. That causes me far more distress than indentation.


Doing a bit of my own bitching and moaning'ly y'rs,


-- 
Steven

On Mon, 01 Nov 2010 22:48:16 +0000, Peter Pearson wrote:

> I must concede that some awkwardness results from assigning significance
> to something (whitespace) that many tools are inclined to treat as
> insignificant.

Then the tools are broken.

Or perhaps I should say:

Th enth etool sarebroke n.


-- 
Steven

On Tue, 02 Nov 2010 04:16:28 +0000, Seebs wrote:

> e.g., any email sent
> to my work account is being magically transformed into HTML (no one
> knows why) on the server, so I can't get correct indentation except
> in attachments.

I suppose then you're going to insist that Python should stop using > and 
< for comparison operators, because your mail server converts them to 
&gt; and &lt; escapes?


> I've lost more time to indentation issues in Python in a month than I've
> lost to mismatches between indentation and flow in C in twenty years.

I've lost more time to reading people's bitching about indentation than I 
have dealing with indentation problems.

But then, I don't insist on using tools which are broken by design. If 
your email server converts plain text to HTML, it is broken. If your 
editor changes spaces to tabs, or visa versa, without being told to do so 
(either by an explicit command or an obvious setting), then your editor 
is broken.

If you are stuck with broken mail servers and broken editors and broken 
tools because of political reasons, then you have my sympathy. But stop 
insisting that everybody has to carry the overhead of your work-arounds 
for your broken tools.



-- 
Steven

On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
> In message<mailman.465.1288653523.2218.python-list@python.org>, Emile van
> Sebille wrote:
>
>> At least you can look at python code and _know_ that spurious placement of
>> required line noise don't have the ability to impact what the code does.
>
> But it does. What is spurious whitespace if not noise, after all?

But it does so by intent.  Other languages lend only an appearance of 
structure through the indentation style of the writer.  It's as good as 
outdated comments.

Emile

On 2010-11-01, Peter Pearson <ppearson@nowhere.invalid> wrote:
> On Mon, 1 Nov 2010 22:24:03 +0000 (UTC), Grant Edwards wrote:
>> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>>> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>>>
>>>>>     diff -b oldfile newfile
>>>> 
>>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>>> indentation can change a Python program.
>>>
>>> I'm getting less and less keen on that particular feature of Python...
>>
>> Why?
>>
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>>
>> For exmaple, if you remove all of the curly-braces from two C source
>> files before comparing them, you don't get useful results.
>
> True, but diff doesn't come with an "ignore curly braces" option.

True, but the fact that diff has an option that for Python sources
will produces useless results doesn't seem like a valid indictment of
Python's syntax and semantics.

> I'm not personally repelled by Python's use of significant
> indentation, but I must concede that some awkwardness results from
> assigning significance to something (whitespace) that many tools are
> inclined to treat as insignificant.

However, the human brain does treat whitespace as significant.

-- 
Grant Edwards               grant.b.edwards        Yow! I joined scientology
                                  at               at a garage sale!!
                              gmail.com            

On 2010-11-02, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-01, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:

>>> I'm getting less and less keen on that particular feature of
>>> Python...
>
>> Why?
>
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>
> Sure.
>
>> For exmaple, if you remove all of the curly-braces from two C source
>> files before comparing them, you don't get useful results.
>
> Right.
>
> But there's no *reason* to do that, while there are many common daily
> events which result in whitespace changes.  e.g., any email sent to
> my work account is being magically transformed into HTML (no one
> knows why) on the server, so I can't get correct indentation except
> in attachments.

And you think compatibility with your broken e-mail server is a good
reason to change the syntax of a programming language?

> Many editors helpfully convert spaces to tabs by default some or all
> of the time.  And so on.

Such editors are broken.

> The more I use it, the more I think it was an interesting experiment
> which has worked out about as well as scanf.

I think it's brilliant (indentation that actually means something, not
scanf).

> The "problem" it fixes is something that's hardly ever been a problem
> for me in C or related languages -- and which could be completely
> eliminated by automated indenters, which were actually conceptually
> possible.

They're only possible if you put redundant block markers in the
source.

> I've lost more time to indentation issues in Python in a month than
> I've lost to mismatches between indentation and flow in C in twenty
> years.

Then you're doing something terribly wrong.  I find indentation-based
structure to be completely effortless.  Are you using an editor that
doesn't have a Python mode?

> In theory, it sounds like it would help to eliminate the ambiguity.
> In practice, eliminating the question of whether code was intended to
> follow explicit flow rather than indentation just means that when
> there's a mistake you don't even get a warning that someone was
> confused.
>
> At least in C, if I see:
> 	if (foo)
> 		a;
> 	else
> 		b;
> 		c;
>
> I *know* that something is wrong.

I suppose you can add comments to Python if you some syntactically
null "redudundacy" to indicate the intended structure.  Personally,

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a
                                  at               quadrophonic sensation
                              gmail.com            of two winos alone in a
                                                   steel mill!

On 2010-11-02, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:

> Ah, but other languages don't make the guarantee that you can add or 
> remove random whitespace in arbitrary places and still have code that
> works correctly!
>
> Of course, neither does Python, but there's a certain type of
> personality that is never happy unless they are bitching and moaning,
> and if they can't find something more substantial to bitch and moan
> about, they'll bitch and moan about the fact that they can't make
> random changes to syntactically significant tokens in their source
> code without things breaking. Boo hoo, cry me a river.

:)

> Personally, I'm more disturbed by the default prompt in the
> interactive interpreter. >>> clashes with the symbol used for quoting
> text in email and news. That causes me far more distress than
> indentation.

I've tripped over that as well.  Not very often, but it's a bigger 
problem than significant whitespace.  I must admit that the first few
minutes I worked with Python having significant whitespace seemed
awkward -- probably because it invoked unpleasant memories of Fortran
IV on punch-cards.

After a short time, I suddenly realized that Python got it right: the
compiler and my brain are using the _same_thing_ to denote program
structure.  All those years of my brain using one thing and the
compiler using a different thing were (and are) obviously the wrong
way to do it.

-- 
Grant Edwards               grant.b.edwards        Yow! My BIOLOGICAL ALARM
                                  at               CLOCK just went off ... It
                              gmail.com            has noiseless DOZE FUNCTION
                                                   and full kitchen!!

On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> You have problems.  Indentation as syntax isn't one of them.

In the absence of indentation as syntax, they haven't bugged me.

> "No one
> knows why" email is being "magically" transformed?

Yay for a large company IT department with both MS and Blackberry
stuff involved.

> Your editor has a
> mind of its own?  Yikes!

It is extremely useful to me to have spaces converted to tabs
for every other file I edit.

>> I've lost more time to indentation issues in Python in a month than
>> I've lost to mismatches between indentation and flow in C in twenty

> Your experience is 180 from mine.

Could be.  But really, I've simply never seen a real problem with
flow/indentation mismatches in C.

>> At least in C, if I see:
>> 	if (foo)
>> 		a;
>> 	else
>> 		b;
>> 		c;
>> 
>> I *know* that something is wrong.

> Does it look right?  With Python looking right and being right are the
> same thing.

No, they aren't.  See... That would work *if I knew for sure what the intent
was*.

	if foo:
	    bar
	else:
	    baz
	    quux

Does it look right?  We have *no idea*, because we don't actually know
whether quux was *intended* to be in the else branch or whether that's a typo.

So the only way I can figure that out is by fully figuring out the function
of all the code bits -- meaning I have to fully understand the code, same
as I would to debug the C.  The fact that indentation is flow control
just means I have only one set of cues, so I can't watch for mismatches.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> I've lost more time to reading people's bitching about indentation than I 
> have dealing with indentation problems.

Doesn't totally surprise me.  :)

> But then, I don't insist on using tools which are broken by design.

Neither do I.

> If your email server converts plain text to HTML, it is broken.

Yup.  I have an open ticket with the IT department.  :)

> If your 
> editor changes spaces to tabs, or visa versa, without being told to do so 
> (either by an explicit command or an obvious setting), then your editor 
> is broken.

Yes.  But that's the thing -- I *want* that behavior for every other tool,
file format, or other thing I work with.

> If you are stuck with broken mail servers and broken editors and broken 
> tools because of political reasons, then you have my sympathy. But stop 
> insisting that everybody has to carry the overhead of your work-arounds 
> for your broken tools.

I have made no such insistance.  I have not said Python should change.  I
have not said other people should want what I want.  I'm not the one telling
other people that editors they've used happily for twenty years without
any problems are clearly wrong.

I have merely observed that Python is, in this respect, gratuitously
brittle.  It doesn't observe the robustness principle; it is
conservative in what it accepts, and in particular, is vulnerable to a
category of problem which is fairly common, well-known, and likely to
remain common for the next few decades.

There are reasons for it to be this way, and I don't object to the
existence of people who prefer that side of the tradeoff.  I do dislike
it when people smugly tell me off for having different preferences.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> You have problems.  Indentation as syntax isn't one of them.
>
> In the absence of indentation as syntax, they haven't bugged me.
>
>> "No one
>> knows why" email is being "magically" transformed?
>
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.
>
>> Your editor has a
>> mind of its own?  Yikes!
>
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.
>
>>> I've lost more time to indentation issues in Python in a month than
>>> I've lost to mismatches between indentation and flow in C in twenty
>
>> Your experience is 180 from mine.
>
> Could be.  But really, I've simply never seen a real problem with
> flow/indentation mismatches in C.
>
>>> At least in C, if I see:
>>> 	if (foo)
>>> 		a;
>>> 	else
>>> 		b;
>>> 		c;
>>> 
>>> I *know* that something is wrong.
>
>> Does it look right?  With Python looking right and being right are the
>> same thing.
>
> No, they aren't.  See... That would work *if I knew for sure what the intent
> was*.
>
> 	if foo:
> 	    bar
> 	else:
> 	    baz
> 	    quux
>
> Does it look right?  We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.
>
> So the only way I can figure that out is by fully figuring out the function
> of all the code bits -- meaning I have to fully understand the code, same
> as I would to debug the C.  The fact that indentation is flow control
> just means I have only one set of cues, so I can't watch for mismatches.

You can add redundant, semantically empty structure info to Python
programs just as easily as you can to C programs:

    if foo:
        bar
    else:
        baz
        quux
    #endif

    
-- 
Grant Edwards               grant.b.edwards        Yow! With YOU, I can be
                                  at               MYSELF ...  We don't NEED
                              gmail.com            Dan Rather ...

On 11/2/2010 10:58 AM Seebs said...
> No, they aren't.  See... That would work *if I knew for sure what the intent
> was*.
>
> 	if foo:
> 	    bar
> 	else:
> 	    baz
> 	    quux
>
> Does it look right?  We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.

What is right is that there's no question that quux is subsequent to baz 
in all cases barring exceptions (and assuming no tabs intermixed)

The apparent structure in python _is_ the structure, whereas otherwise 
you've got to count your ;'s and {}'s etc to determine and verify the 
structure matches the apparent structure provided by the programmer.

Whether that's what the specs called for or not is always a source for bugs.

Emile

On 2010-11-02, Emile van Sebille <emile@fenx.com> wrote:
> On 11/2/2010 10:58 AM Seebs said...
>> No, they aren't.  See... That would work *if I knew for sure what the intent
>> was*.
>>
>> 	if foo:
>> 	    bar
>> 	else:
>> 	    baz
>> 	    quux
>>
>> Does it look right?  We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a typo.
>
> What is right is that there's no question that quux is subsequent to baz 
> in all cases barring exceptions (and assuming no tabs intermixed)
>
> The apparent structure in python _is_ the structure, whereas otherwise 
> you've got to count your ;'s and {}'s etc to determine and verify the 
> structure matches the apparent structure provided by the programmer.
>
> Whether that's what the specs called for or not is always a source
> for bugs.

Yup.  I've never found that the ability to write incorrect code that
_appears_ correct to be a good thing.  Nor do I find the ability to
write correct code that appears to be incorrect to be valuable.

In Python, if the structure looks right, then structure _is_ right.

-- 
Grant Edwards               grant.b.edwards        Yow! Now we can become
                                  at               alcoholics!
                              gmail.com            

On 02 Nov 2010 17:58:06 GMT
Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> > "No one
> > knows why" email is being "magically" transformed?
> 
> Yay for a large company IT department with both MS and Blackberry
> stuff involved.

"Large" is no excuse for incompetency.

> > Your editor has a
> > mind of its own?  Yikes!
> 
> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.

So configure it to recognize Python files and act accordingly.

> No, they aren't.  See... That would work *if I knew for sure what the intent
> was*.
> 
> 	if foo:
> 	    bar
> 	else:
> 	    baz
> 	    quux
> 
> Does it look right?  We have *no idea*, because we don't actually know
> whether quux was *intended* to be in the else branch or whether that's a typo.

And C has the same problem.

    if (foo)
        bar;
    else
        baz;

        quux;

Is quux meant to be part of the else clause?  The writer's indentation
suggests "yes" but the code says "no".

> So the only way I can figure that out is by fully figuring out the function

Same is true for the C code.  In both cases you can tell what the code
will do (modulo weird macros in the C code) but the intention is
impossible to determine without mind reading abilities in both cases.
We do know that the Python code *appears* to be doing exactly what the
author intended and the C code *appears* to not be.

In either case, <syntax checker> != <debugger>.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Tue, 2 Nov 2010 18:15:03 +0000 (UTC)
Grant Edwards <invalid@invalid.invalid> wrote:
> You can add redundant, semantically empty structure info to Python
> programs just as easily as you can to C programs:
> 
>     if foo:
>         bar
>     else:
>         baz
>         quux
>     #endif

"Redundant" is right.  However, there is a use for such comments:

    if foo:
        bar
    else:
        baz
        if snafu:
            cookie
        #endif snafu
        quux
    #endif foo

Useful in more complicated code, of course.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Steven D'Aprano wrote:
> Personally, I'm more disturbed by the default prompt in the interactive 
> interpreter. >>> clashes with the symbol used for quoting text in email 
> and news. That causes me far more distress than indentation.

Here here!

I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)

~Ethan~

On 2010-11-02, Grant Edwards <invalid@invalid.invalid> wrote:
> True, but the fact that diff has an option that for Python sources
> will produces useless results doesn't seem like a valid indictment of
> Python's syntax and semantics.

The question is *why* diff has that option.

The answer is because whitespace changes (spaces to tabs, different
tab stops, etcetera) are an extremely common failure mode, such that
it's quite common for files to end up with unintentional whitespace
changes.

This, in turn, is why there are so many tools to automatically fix up
whitespace type issues, such as cb/indent for C, auto-indentation for
many languages (including stuff like XML) features in editors, and so
on -- because it's a common problem.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-02, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
>> If your 
>> editor changes spaces to tabs, or visa versa, without being told to do so 
>> (either by an explicit command or an obvious setting), then your editor 
>> is broken.
>
> Yes.  But that's the thing -- I *want* that behavior for every other tool,
> file format, or other thing I work with.

I agree with Seebs, Python is the only language I know that promotes
the use of spaces over tabs; and there are equally picky syntaxs (ie,
Makefiles) that mandate the use of tabs.  I personally prefer tabs as
it lets *me* decide how far the apparent indentations are in the code.
You may like four spaces; but, I agree with Linus Torvalds that eight
spaces is much clearer.  The beautiful thing about tabs is that we can
both set our tab stops to match our own viewing preferences.

>> If you are stuck with broken mail servers and broken editors and broken 
>> tools because of political reasons, then you have my sympathy. But stop 
>> insisting that everybody has to carry the overhead of your work-arounds 
>> for your broken tools.
>
> I have made no such insistance.  I have not said Python should change.  I
> have not said other people should want what I want.  I'm not the one telling
> other people that editors they've used happily for twenty years without
> any problems are clearly wrong.

Indeed, a simple script is enough to identify how levels are indented and
convert the present indenting to whatever is your preference.

> There are reasons for it to be this way, and I don't object to the
> existence of people who prefer that side of the tradeoff.  I do dislike
> it when people smugly tell me off for having different preferences.

This is Python's most noticable blemish outside of the community.
Everybody knows that Python is the language that forces you to use a
particular style of formatting; and, that is a turn-off for many people.
It is a big mistake that whenever the issue arises, the community
effectively attacks anybody who might have disagreements with the tradeoffs
made for the Python language.  This tends to set people on the defensive
and gives them a bad taste about the language as a whole.

It would be much better if the community would simply acknowledge that
this is a tradeoff the the language has made and one which is often
misunderstood by many first time Python programmers.  Then it is possible
transition to Python's strengths.  Don't simply ignore that there *are*
potential downfalls to this approach.

On 2010-11-02, Grant Edwards <invalid@invalid.invalid> wrote:
> And you think compatibility with your broken e-mail server is a good
> reason to change the syntax of a programming language?

No.  I never said that.

>> Many editors helpfully convert spaces to tabs by default some or all
>> of the time.  And so on.

> Such editors are broken.

If I use an editor for twenty years, and it works beautifully with fifteen
different programming languages across five operating systems, and someone
comes along with a file format which tends to silently break when treated
the same way, my first response is not to blame the editor.

> I think it's brilliant (indentation that actually means something, not
> scanf).

It is.  However, it's also brittle.

>> The "problem" it fixes is something that's hardly ever been a problem
>> for me in C or related languages -- and which could be completely
>> eliminated by automated indenters, which were actually conceptually
>> possible.

> They're only possible if you put redundant block markers in the
> source.

Yes.  Or make the block markers not-redundant.

> Then you're doing something terribly wrong.  I find indentation-based
> structure to be completely effortless.

And it is *ABSOLUTELY CERTAIN* that, if any two people have different
experiences of how easy or hard something is, it's because one of them
is doing something wrong, right?

Because people are *never* actually different.  There is no such thing
as "preferences".  There is no such thing as a "matter of taste".  No,
no.  If one person finds something comfortable, and another dislikes it,
it's because the second one is *doing something terribly wrong*.

> Are you using an editor that
> doesn't have a Python mode?

Yes.  I haven't used "modes" in editors until now.  I've never needed to.
Every other file format I work with is robust about this.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Sigh! How flame-wars tend to lose the original question:

On Oct 31, 5:02=A0pm, jf <j...@aucuneadresse.fr> wrote:
> Hi,
>
> I've a project with tabs and spaces mixed (yes I know it's bad).

Do python aficionados want to suggest that mixing spaces and tabs is a
'good thing'?

On 2010-11-02, Ethan Furman <ethan@stoneleaf.us> wrote:
> Steven D'Aprano wrote:
>> Personally, I'm more disturbed by the default prompt in the interactive 
>> interpreter. >>> clashes with the symbol used for quoting text in email 
>> and news. That causes me far more distress than indentation.
>
> Here here!
>
> I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)

So _now_ what are going to whinge about?

-- 
Grant Edwards               grant.b.edwards        Yow! I am NOT a nut....
                                  at               
                              gmail.com            

Grant Edwards wrote:
> On 2010-11-02, Ethan Furman <ethan@stoneleaf.us> wrote:
>> Steven D'Aprano wrote:
>>> Personally, I'm more disturbed by the default prompt in the interactive 
>>> interpreter. >>> clashes with the symbol used for quoting text in email 
>>> and news. That causes me far more distress than indentation.
>>
>> I finally did "sys.ps1 = '--> '" in my interactive startup file.  :)
> 
> So _now_ what are going to whinge about?
                    ^-
                      \
                  missing a word?  ;)

If the word is "you" -- how about complaints about the documentation?

elif the word is "we" -- maybe lack of reading comprehension?

elif the word is "Steven" -- absolutely no clue  ;)

else -- maybe multiple inheritance being a bug...
         http://bugs.python.org/issue2667

~Ethan~

In message <mailman.497.1288703990.2218.python-list@python.org>, Emile van 
Sebille wrote:

> On 11/1/2010 4:22 PM Lawrence D'Oliveiro said...
>
>> In message<mailman.465.1288653523.2218.python-list@python.org>, Emile van
>> Sebille wrote:
>>
>>> At least you can look at python code and _know_ that spurious placement
>>> of required line noise don't have the ability to impact what the code
>>> does.
>>
>> But it does. What is spurious whitespace if not noise, after all?
> 
> But it does so by intent.  Other languages lend only an appearance of
> structure through the indentation style of the writer.

No, the indentation is there to make the structure clearer, not to act as a 
substitute for the structure. Try to conflate the two, and you end up with 
problems such as we are discussing.

> It's as good as outdated comments.

Outdated comments are a bug like any other, and should be fixed.

In message <ianem3$cuq$1@reader1.panix.com>, Grant Edwards wrote:

> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
> wrote:
>
>> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>>
>>>>     diff -b oldfile newfile
>>> 
>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>> indentation can change a Python program.
>>
>> I'm getting less and less keen on that particular feature of Python...
> 
> Why?
> 
> Other languages have similar problems if you remove salient bits of
> syntax before comparing two source files files.

But other languages don’t make those “salient bits of syntax” invisible. 
I.e. they are actually “salient”.

On 2010-11-02, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <ianem3$cuq$1@reader1.panix.com>, Grant Edwards wrote:
>
>> On 2010-11-01, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand>
>> wrote:
>>
>>> In message <8j8am4Fk2jU1@mid.individual.net>, Peter Pearson wrote:
>>>>
>>>>>     diff -b oldfile newfile
>>>> 
>>>> Warning: "diff -b" won't detect changes in indentation.  Changes in
>>>> indentation can change a Python program.
>>>
>>> I'm getting less and less keen on that particular feature of Python...
>> 
>> Why?
>> 
>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
>
> But other languages don???t make those ???salient bits of syntax???
> invisible.

Huh? Indentation is invisible?  You can't see the indentation in
Python source code?

I'm baffled...

-- 
Grant

On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> "Redundant" is right.  However, there is a use for such comments:
>
>     if foo:
>         bar
>     else:
>         baz
>         if snafu:
>             cookie
>         #endif snafu
>         quux
>     #endif foo

Actually, I have found similar markers to be useful everywhere.  I don't
like the way my editor tries to fold Python code, so I started inserting
folding markers myself:

     # foo {{{
     if foo:
     
         bar
	 
     else:

         baz

	 # snafu {{{
         if snafu:
             cookie
         # }}}

         quux

     # }}}

If the bar, baz, and quux blocks are large enough logical units, I will
fold them as well.

What I found is that the makers become an incredibly useful form of
organzational tool.

On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> "Large" is no excuse for incompetency.

It is in practice.

> So configure it to recognize Python files and act accordingly.

So far as I know, it doesn't have a feature to do this.  In any event,
I work around it okay.

>> No, they aren't.  See... That would work *if I knew for sure what the intent
>> was*.
>> 
>> 	if foo:
>> 	    bar
>> 	else:
>> 	    baz
>> 	    quux
>> 
>> Does it look right?  We have *no idea*, because we don't actually know
>> whether quux was *intended* to be in the else branch or whether that's a typo.

> And C has the same problem.

Not quite!

>     if (foo)
>         bar;
>     else
>         baz;
>
>         quux;

> Is quux meant to be part of the else clause?  The writer's indentation
> suggests "yes" but the code says "no".

Right.

And that's the thing:  In C, I know there's something wrong here.  I may not
know what it is, but I know *something* is wrong.

> Same is true for the C code.

Pretty much!

> In both cases you can tell what the code
> will do (modulo weird macros in the C code) but the intention is
> impossible to determine without mind reading abilities in both cases.
> We do know that the Python code *appears* to be doing exactly what the
> author intended and the C code *appears* to not be.

Yes.  And in my experience, that means that since the code must be
wrong (or I wouldn't be looking at it), it's very nice that in one of
them, I've just been told for sure that the writer was confused right
here at this line.  In the other, I have no way of knowing that the
writer was confused.

What was it someone once said?  "Explicit is better than implicit."

I *like* my parity bits.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Emile van Sebille <emile@fenx.com> wrote:
> What is right is that there's no question that quux is subsequent to baz 
> in all cases barring exceptions (and assuming no tabs intermixed)

Yes, but that doesn't mean it does what the programmer intended, just
that it does what it does.

> The apparent structure in python _is_ the structure, whereas otherwise 
> you've got to count your ;'s and {}'s etc to determine and verify the 
> structure matches the apparent structure provided by the programmer.

Yes.

I understand this.

However, I have probably seen all of two or three bugs ever related to
mis-indented C, and I've had various things screw up or wreck indentation
on dozens of occasions.  Being able to recover has been nice.  (So's being
able to use fence matching to jump to the other end of a block.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Tim Harig <usernet@ilthio.net> wrote:
> This is Python's most noticable blemish outside of the community.
> Everybody knows that Python is the language that forces you to use a
> particular style of formatting; and, that is a turn-off for many people.

Honestly, I could probably live with that; the killer is the impossibility
of recovering from white space damage.  I have had many things happen to
code over the years which required someone to run them through indent/cb.

> It is a big mistake that whenever the issue arises, the community
> effectively attacks anybody who might have disagreements with the tradeoffs
> made for the Python language.  This tends to set people on the defensive
> and gives them a bad taste about the language as a whole.

Yes.  It does not create an impression that this is an engineering tradeoff
which has been considered and understood; it creates the impression that
people are defensive enough about it that they're not able to confidently
acknowledge the shortcomings while maintaining that the tradeoff is worth
it.

I like C.  If you tell me that C's macro processor sucks, I will agree
with you.  I don't have to make excuses or pretend that there's no
downsides; I can justify my preference for the language even *granting*
those downsides (and downsides aplenty are to be found).

> It would be much better if the community would simply acknowledge that
> this is a tradeoff the the language has made and one which is often
> misunderstood by many first time Python programmers.  Then it is possible
> transition to Python's strengths.  Don't simply ignore that there *are*
> potential downfalls to this approach.

Amen.

I am fine with this tradeoff.  It's not what I would have picked, but
hey, I'm not Dutch.  What I'm not fine with is people telling me that
it's not a tradeoff and that all the problems are my fault.

If someone designed a protocol where a particular kind of file was required
to be sent via email, as plain text, with many lines starting "From ", and
the protocol died horribly whenever it encountered ">From " at the
beginning of a line, no amount of pointing out that the mail servers in
question were wrong would make it a good design for a protocol.

Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
*extremely common* bad thing, and I fundamentally don't think it was
a good choice to build a system with no redundancy against it.  That
"redundant" information saves our hides on a regular basis in an
imperfect world.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-02, Grant Edwards <invalid@invalid.invalid> wrote:
> Huh? Indentation is invisible?  You can't see the indentation in
> Python source code?

The difference between tabs and spaces is invisible on a great
number of the devices on which people display code.

Indentation is visible, but the underlying structure of it may not
be.  (It's worse than that, because for instance "   	" is
quite hard to distinguish from the quite similar "	".)  And at
least one of them is clearly wrong.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On Wed, 3 Nov 2010 00:41:46 +0000 (UTC)
Tim Harig <usernet@ilthio.net> wrote:
> On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> Actually, I have found similar markers to be useful everywhere.  I don't
> like the way my editor tries to fold Python code, so I started inserting
> folding markers myself:
> 
>      # foo {{{
>      if foo:

Now that is redundant.  We know it's "foo" at the top of the block.
Identifying the end of the block has some value.  And the braces just
make the code noisy.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On 03 Nov 2010 01:20:40 GMT
Seebs <usenet-nospam@seebs.net> wrote:
> However, I have probably seen all of two or three bugs ever related to
> mis-indented C, and I've had various things screw up or wreck indentation

Really?  I have never seen bugs in C related to indentation.  I have
seen plenty related to braces.  What I have seen is bugs hidden by the
indentation not matching the block structure.  Wrong indentation in
Python *is* a bug.  There's no other visual signal to hide the error.

> on dozens of occasions.  Being able to recover has been nice.  (So's being
> able to use fence matching to jump to the other end of a block.)

But I can see the other end of the block in Python.  I don't need any
tricks to make sure that it is the end.  And if your block is too big
to see the structure easily then that just means that some code should
be factored out to a method.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On 2010-11-03, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On Wed, 3 Nov 2010 00:41:46 +0000 (UTC)
> Tim Harig <usernet@ilthio.net> wrote:
>> On 2010-11-02, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> Actually, I have found similar markers to be useful everywhere.  I don't
>> like the way my editor tries to fold Python code, so I started inserting
>> folding markers myself:
>> 
>>      # foo {{{
>>      if foo:
>
> Now that is redundant.  We know it's "foo" at the top of the block.

In practice the comment would explain why and how the conditional is
being used just like any other comment.  Since your example as abstract,
I didn't have anything useful to say about it as I would for real code.

When the code is folded, I will see nothing but the comments.  It is often
helpful to look at a section of code with all of the code blocks folded to
gain a high level understanding of the code before zeroing in on the
specific section that I wish to edit.  When I do edit a section, I unfold
no more code blocks then necessary.  If I have to unfold too many blocks to
to edit a single section of code, then it is a powerful indication that
either the code block is not properly self contained or that the comments
of the surrounding code blocks are insufficient to convey information about
their code block.

> Identifying the end of the block has some value.  And the braces just
> make the code noisy.

With good syntax highlighting, you don't notice them unless you are looking
for something because the markers are in comments and the markers for
a block are only visible when the block is unfolded.  As a benefit, they allow the folding
stucture to provide expression of the code structure that cannot be
expressed in the code itself.

I often group blocks together that would not otherwise be indented or
otherwise expressed together as they were in your example.

	# top level group {{{

	# part 1 {{{
	code
	# }}}

	# part 2 {{{
	code
	# }}}
	
	# part 3 {{{
	code
	# }}}

	# }}}

Folded in my editor, it looks like this:

 44 +--- 15 lines: # top level group -------------------------------------------

Unfolding the top level group, it looks like this:

 44         # top level group {{{
 45
 46 +----  3 lines: # part 1 ---------------------------------------------------
 49
 50 +----  3 lines: # part 2 ---------------------------------------------------
 53
 54 +----  3 lines: # part 3 ---------------------------------------------------
 57
 58         # }}}

It is therefore clear that all three of the parts are logically connected.
I can keep them all folded and view them as a group or a can look into the
group and edit just the relevant section of the group:

 44         # top level group {{{
 45
 46 +----  3 lines: # part 1 ---------------------------------------------------
 49
 50         # part 2 {{{
 51         code
 52         # }}}
 53
 54 +----  3 lines: # part 3 ---------------------------------------------------
 57
 58         # }}}

I have effectively added a meta structure to the blocks inside of
the fuction at a finer grain then is supported by the syntax itself.
Should I decide later that the top level group is becoming autonomous
enough to warrant moving to a separate function, I can simply grab the
entire folded block as an entity and move it to its own function body.

On 2010-11-03, Tim Harig <usernet@ilthio.net> wrote:
> On 2010-11-03, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> On Wed, 3 Nov 2010 00:41:46 +0000 (UTC)
>> Tim Harig <usernet@ilthio.net> wrote:
>> Identifying the end of the block has some value.  And the braces just
>> make the code noisy.
>
> With good syntax highlighting, you don't notice them unless you are looking
> for something because the markers are in comments and the markers for
> a block are only visible when the block is unfolded.  As a benefit, they allow the folding
> stucture to provide expression of the code structure that cannot be
> expressed in the code itself.

Also note that you can use whatever you like for the folding markers if the
braces intimidate you.  {{{ just happens to be the most recognized
standard.  The Erlang crowd like to use ## for this sort of thing.

On 2010-11-03, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On 03 Nov 2010 01:20:40 GMT
> Seebs <usenet-nospam@seebs.net> wrote:
>> However, I have probably seen all of two or three bugs ever related to
>> mis-indented C, and I've had various things screw up or wreck indentation

> Really?  I have never seen bugs in C related to indentation.  I have
> seen plenty related to braces.  What I have seen is bugs hidden by the
> indentation not matching the block structure.

Right.  That's *related to* indentation -- it wouldn't be there (we hope)
had the indentation been right.

> Wrong indentation in
> Python *is* a bug.  There's no other visual signal to hide the error.

Sure, but there's also no way for you to spot that something looks
suspicious.  In Python, if something is misindented, it does what you
told it to do, and there's no way for you to tell, by looking at it,
that it isn't what was intended.  In C, if something is misindented,
it does what you told it to do, but it's obvious looking at the code
that something went wrong.

> But I can see the other end of the block in Python.  I don't need any
> tricks to make sure that it is the end.  And if your block is too big
> to see the structure easily then that just means that some code should
> be factored out to a method.

This level of dogmatism about what should always be the case is not
conducive to good software engineering practices.  It is not obvious to
me that it's *always* the case.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:

> I agree with Seebs, Python is the only language I know that promotes the
> use of spaces over tabs; 

Really? I'm not aware of *any* language that promotes tabs over spaces. I 
thought the tabs vs spaces war was mostly won by spaces over a decade ago 
(apart from a few plucky freedom fighters who will never surrender).


> and there are equally picky syntaxs (ie,
> Makefiles) that mandate the use of tabs.  I personally prefer tabs as it
> lets *me* decide how far the apparent indentations are in the code. You
> may like four spaces; but, I agree with Linus Torvalds that eight spaces
> is much clearer.  The beautiful thing about tabs is that we can both set
> our tab stops to match our own viewing preferences.

Actually I agree with you about tabs. I think tabs are far more logical 
and sensible. But I'm stuck with broken tools that don't deal with tabs, 
and with PEP 8 that mandates the use of spaces, and popular opinion that 
says make is crazy for using tabs.

So, I bite my lip, stop using broken tools that make dealing with space-
indents painful, and just deal with it. And you know what? It's not so 
bad after all.


> This is Python's most noticable blemish outside of the community.
> Everybody knows that Python is the language that forces you to use a
> particular style of formatting; and, that is a turn-off for many people.

Their loss. I don't miss the flame wars over the One True Brace Style. 
There are enough disagreements over coding conventions without adding to 
them.


> It is a big mistake that whenever the issue arises, the community
> effectively attacks anybody who might have disagreements with the
> tradeoffs made for the Python language.  This tends to set people on the
> defensive and gives them a bad taste about the language as a whole.

That's very insightful. Why don't you apply some of that insight to the 
other side? It is *incredibly* annoying to see the same old people making 
the same old snide remarks about the same old issues over and over again, 
particularly when:

* it's not an issue for thousands of other users;
* even if it were an issue, if you use the right tool for the job, the 
issue disappears;
* and even if there is no right tool for the job, the feature isn't going 
to change;
* and even if it would change, the people doing the whinging aren't going 
to volunteer to make the change.


> It would be much better if the community would simply acknowledge that
> this is a tradeoff the the language has made and one which is often
> misunderstood by many first time Python programmers.

Been there, done that. This is *old news*.



-- 
Steven

On Wed, 03 Nov 2010 12:01:06 +1300, Lawrence D'Oliveiro wrote:

> In message <ianem3$cuq$1@reader1.panix.com>, Grant Edwards wrote:

>> Other languages have similar problems if you remove salient bits of
>> syntax before comparing two source files files.
> 
> But other languages don’t make those “salient bits of syntax” invisible.
> I.e. they are actually “salient”.

(1) Indentation is visible. Compare:


    This line has leading visible whitespace.

This line has leading invisible characters.

See the difference?


(2) Salient doesn't mean visible. It means "prominent, conspicuous, 
noticeable". Something can be conspicuous by its absence; conspicuous 
whitespace                                can                    be
very                            noticeable.



-- 
Steven

On 2010-11-03, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On 03 Nov 2010 01:20:40 GMT
> Seebs <usenet-nospam@seebs.net> wrote:
>> However, I have probably seen all of two or three bugs ever related to
>> mis-indented C, and I've had various things screw up or wreck indentation
>
> Really?  I have never seen bugs in C related to indentation.  I have
> seen plenty related to braces.

Same here.

> What I have seen is bugs hidden by the indentation not matching the
> block structure.  Wrong indentation in Python *is* a bug.  There's no
> other visual signal to hide the error.

Exactly.

-- 
Grant Edwards               grant.b.edwards        Yow! I selected E5 ... but
                                  at               I didn't hear "Sam the Sham
                              gmail.com            and the Pharoahs"!

On 2010-11-03, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-02, Grant Edwards <invalid@invalid.invalid> wrote:
>> Huh? Indentation is invisible?  You can't see the indentation in
>> Python source code?
>
> The difference between tabs and spaces is invisible on a great
> number of the devices on which people display code.

Allowing a mixture of tabs/spaces for indentation was a mistake, and
pretty much everybody agrees on that.  However, that isn't what's
being discussed.

> Indentation is visible, but the underlying structure of it may not
> be.  (It's worse than that, because for instance " " is quite hard to
> distinguish from the quite similar " ".) And at least one of them is
> clearly wrong.

-- 
Grant Edwards               grant.b.edwards        Yow! An air of FRENCH FRIES
                                  at               permeates my nostrils!!
                              gmail.com            

On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 
>
> Really? I'm not aware of *any* language that promotes tabs over spaces. I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

Python is the only language that I know that *needs* to specify tabs versus
spaces since it is the only language I know of which uses whitespace
formating as part of its syntax and structure.  Mixed usage may be annoying
in other languages; but, it breaks Python.

Otherwise, it is my experience that the preference for tabs versus spaces
depends on the users chosen platform.  *nix users prefer tabs while Windows
users prefer spaces.

>> and there are equally picky syntaxs (ie,
>> Makefiles) that mandate the use of tabs.  I personally prefer tabs as it
>> lets *me* decide how far the apparent indentations are in the code. You
>> may like four spaces; but, I agree with Linus Torvalds that eight spaces
>> is much clearer.  The beautiful thing about tabs is that we can both set
>> our tab stops to match our own viewing preferences.
>
> Actually I agree with you about tabs. I think tabs are far more logical 
> and sensible. But I'm stuck with broken tools that don't deal with tabs, 

Where you not the one a few posts back telling Seebs that he needed to
change his broken tools?

> and with PEP 8 that mandates the use of spaces, and popular opinion that 
> says make is crazy for using tabs.

Stupid rules are meant to be broken.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

If I am using somebody elses project, then I will post my output using
their code conventions.  I have smart conversion scripts that convert
between different indent formats.  I edit in the format that I prefer and,
in my projects, the indentation in the SCM is in my preferred format.

>> This is Python's most noticable blemish outside of the community.
>> Everybody knows that Python is the language that forces you to use a
>> particular style of formatting; and, that is a turn-off for many people.
>
> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

This choice has obviously not been effective in stopping flame wars.  I can
cite multiple threads where it has caused them.

>> It is a big mistake that whenever the issue arises, the community
>> effectively attacks anybody who might have disagreements with the
>> tradeoffs made for the Python language.  This tends to set people on the
>> defensive and gives them a bad taste about the language as a whole.
>
> That's very insightful. Why don't you apply some of that insight to the 
> other side? It is *incredibly* annoying to see the same old people making 
> the same old snide remarks about the same old issues over and over again, 
> particularly when:

A large part of the reason that the issue keeps coming up is that the
community never really deals with it when it does.  I have enough customer
support experience to know that a client is never really satisfied until
you acknowledge their problem.  Until the problem is acknowledged, the
client will have put up psychological communcation block that prevents
them from hearing any workarounds that you might have.

The community never acknowledges the problem.  It simply sweeps the
problem under the rug telling the people raising these issues that they
don't know what they are talking about; strengthening the psychological
block and further impeding the communication.  The people with these
problems therefore never feel that they have been heard, become unwilling
to listen to the solutions,  and will thus keep bringing the problem
back up.

> * it's not an issue for thousands of other users;

You are now hearing the testimony of those who have had problems.  I also
know that it is human nature for advocates to simply overlook the problems
when they arise.  That doesn't mean that the problem is there.

I have used Python for over a decade in spite of its problems because I
believe that the benefits outway the detriments.  I am however objective
enough to be congnizant of the problems; and, I am fully aware of there
effects on new members of the community.

When prospective Python programmers approach me with these problems I:

	1. Acknowledge that the problem exits.

	2. Explain the trade-offs that have lead to the problem.
	
	3. Suggest ways to work around the problem.
	
	4. Point out why I believe the benefits of using Python outway its
		idiosyncrasies.

I don't just tell them that there is no problem or that the problems they
may be experiencing are their fault because they choose to do something
differently then I might.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

That a tools is needed is in itself an indication that the problem exists.
That isn't to say that good tools don't have their place or that they
cannot contribute to the solution.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Funny that.  I *do* have a history of submitting patches to open source
projects.

>> It would be much better if the community would simply acknowledge that
>> this is a tradeoff the the language has made and one which is often
>> misunderstood by many first time Python programmers.
>
> Been there, done that. This is *old news*.

Except that you are not.  Your general attitude is that since you don't
experience problems nobody else must either.

On Wed, 03 Nov 2010 02:40:11 +0000, Seebs wrote:

> Sure, but there's also no way for you to spot that something looks
> suspicious.  In Python, if something is misindented, it does what you
> told it to do, and there's no way for you to tell, by looking at it,
> that it isn't what was intended.  In C, if something is misindented, it
> does what you told it to do, but it's obvious looking at the code that
> something went wrong.

If it's that obvious, why do people keep causing those indentation-
related bugs in C?

I'm glad for you that you have a finely trained attention to detail that 
is able to instantly spot misindented C code (or is that misplaced braces 
and correctly indented?), but it is a notoriously common error which 
suggests that it's not anywhere near as obvious as you think.

It's *far* more common than Python code being misindented.

There's even a commonly suggested style for C programmers: always use 
braces any time the syntax allows them, even when they're not needed, 
because the next guy who maintains the file may not be as careful and may 
forget to add the braces when needed.


>> But I can see the other end of the block in Python.  I don't need any
>> tricks to make sure that it is the end.  And if your block is too big
>> to see the structure easily then that just means that some code should
>> be factored out to a method.
> 
> This level of dogmatism about what should always be the case is not
> conducive to good software engineering practices.

I question that assertion. Good engineering practices is about setting 
best practices, and following them, not avoiding them because there might 
be the odd exception here and there.


> It is not obvious to me that it's *always* the case.

So what if there is an exception one time in twenty thousand? You don't 
design a tool (such as a programming language) on the basis of what's 
good for the rare exceptional cases, but on what's good for the common 
cases. The common case is that functions and methods should be short 
enough to see the structure by eye. If it isn't, you have more problems 
than just the lack of begin/end markers. The language shouldn't make 
everyone carry the burden of supporting two-page functions all the time, 
just to save you an insignificant amount of trouble on the vanishingly 
rare occasion you need a function that is two pages long.


-- 
Steven

On 11/3/2010 11:49 AM Tim Harig said...

> A large part of the reason that the issue keeps coming up is that the
> community never really deals with it when it does.  I have enough customer
> support experience to know that a client is never really satisfied until
> you acknowledge their problem.

Then you likely also have enough experience to know that once the 
customer has made the decision you accept their call.  As a consultant 
you move on after having done your duty bringing the issue to light. 
The same applies here -- it's not changing, so you (generic you) accept 
it and move on.  The community has dealt with the issue by acknowledging 
that differing opinions exist and the BDFL makes the final call, which 
is certainly something the community accepts.  I imagine a PEP could be 
submitted suggesting change, and it hasn't been done because the outcome 
is certain.

Otherwise, there's always whython...

http://writeonly.wordpress.com/2010/04/01/whython-python-for-people-who-hate-whitespace/

Emile

On Wed, 03 Nov 2010 18:49:06 +0000, Tim Harig wrote:

>> Actually I agree with you about tabs. I think tabs are far more logical
>> and sensible. But I'm stuck with broken tools that don't deal with
>> tabs,
> 
> Where you not the one a few posts back telling Seebs that he needed to
> change his broken tools?

Yes, and I also said that I sympathized with him if he couldn't.

 
>>> It is a big mistake that whenever the issue arises, the community
>>> effectively attacks anybody who might have disagreements with the
>>> tradeoffs made for the Python language.  This tends to set people on
>>> the defensive and gives them a bad taste about the language as a
>>> whole.
>>
>> That's very insightful. Why don't you apply some of that insight to the
>> other side? It is *incredibly* annoying to see the same old people
>> making the same old snide remarks about the same old issues over and
>> over again, particularly when:
> 
> A large part of the reason that the issue keeps coming up is that the
> community never really deals with it when it does.

No. The community does deal with it. It deals with it by saying "It isn't 
going to change." If you want a language that forces you to wrap ever 
block in BEGIN END tags, you have a thousand choices. Python is not one 
of them. What is so hard to understand about this?


> I have enough
> customer support experience to know that a client is never really
> satisfied until you acknowledge their problem.  Until the problem is
> acknowledged, the client will have put up psychological communcation
> block that prevents them from hearing any workarounds that you might
> have.

Yes, well that too goes both ways. *I* have a psychological communication 
block that prevents me from hearing any complaints about the lack of 
braces from people who refuse to acknowledge that having to type braces 
is stupid and annoying, and that the use of braces in a language hurts 
readability.

Frankly, I DON'T CARE how often your editor breaks your source code. I 
don't care about Seeb's mail server that converts his Python code to 
HTML. I don't give a rat's arse about how many times some buggy ftp 
client has mangled the indentation on Python files. Not my problem. Your 
pain is not my pain, and any solution to these problems that involves 
changing the way I read and write Python code is an anti-solution to a 
non-problem to me.

Until the "Python is broken 'cos it has no braces" crowd acknowledge this 
fact, I just harden my heart against their complaints. Why should *I* 
have to acknowledge their issues when they don't acknowledge mine?



-- 
Steven

On Wed, 03 Nov 2010 01:25:56 +0000, Seebs wrote:

> Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
> *extremely common* bad thing, 

I question that.

You've claimed that you have to deal with broken indentation on a regular 
basis. I've *never* had to deal with broken whitespace, except for 
certain websites that mangle leading whitespace when you post a comment. 
So I don't post code on those websites.


> and I fundamentally don't think it was a
> good choice to build a system with no redundancy against it.

Python does have some redundancy against indentation mangling. Not all 
combinations of indentation are legal.

# Not legal:
y = x + 1
    z = x*y

# Not legal:
if x:
do_something()

# Not legal:
    if x: do something()
    else:
do_something_else()


And so on. True, there are some failure modes which can't be easily 
recovered from without reading and understanding the code. That's okay. 
Such failure modes are vanishingly rare -- for every twenty thousand 
braces you avoid typing, you might, if you're unlucky, need to fix an 
instance of broken indentation.


> That
> "redundant" information saves our hides on a regular basis in an
> imperfect world.


So you say.


-- 
Steven

On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>> I agree with Seebs, Python is the only language I know that promotes the
>> use of spaces over tabs; 

> Really?

Yes.

> I'm not aware of *any* language that promotes tabs over spaces.

Makefiles.

> I 
> thought the tabs vs spaces war was mostly won by spaces over a decade ago 
> (apart from a few plucky freedom fighters who will never surrender).

No.  However, you've got a fallacy of the excluded middle here -- you're
ignoring the very large set of "doesn't care either way", and looking only
at things that prefer one or the other.

> So, I bite my lip, stop using broken tools that make dealing with space-
> indents painful, and just deal with it. And you know what? It's not so 
> bad after all.

I don't consider it broken for a tool to favor a more logical style which
is *actually* required by at least one format, and not a problem for anything
I've ever used except (sort of) Python.

In fact, Python works perfectly with tabs; it's just other Python
programmers who get fussy.  :)

> Their loss. I don't miss the flame wars over the One True Brace Style. 
> There are enough disagreements over coding conventions without adding to 
> them.

I don't miss them, or care about them; after all, I can just run indent/cb
to format something however I like, and run it again to match any given
coding style standard.  Problem solved.

> * it's not an issue for thousands of other users;

This is a non-argument.  That something isn't a problem for other people
makes no difference to the people for whom it's a problem.

> * even if it were an issue, if you use the right tool for the job, the 
> issue disappears;

I have never found any other editor that I like as much as the one I use
now.

> * and even if there is no right tool for the job, the feature isn't going 
> to change;

I think you miss the point of the observation.  I'm not expecting it to
change; I'm pointing out that insisting that it's not a problem is
*insulting* to the people for whom it is a problem.

> * and even if it would change, the people doing the whinging aren't going 
> to volunteer to make the change.

Oh, I'd happily contribute code if it'd matter.  But it wouldn't.

>> It would be much better if the community would simply acknowledge that
>> this is a tradeoff the the language has made and one which is often
>> misunderstood by many first time Python programmers.

> Been there, done that. This is *old news*.

I haven't seen it done yet.  I've seen a whole lot of people tell me that
an editor I've been using for twenty years is "broken" because I found
a program that is brittle with regards to its inputs that is prone to
being triggered by a behavior which has been free of problems (and indeed
in some cases *mandatory*) for everything else.  I've seen people smugly
tell me that I'd love this if I just tried it.  That didn't work for
pickles, it didn't work for Player-vs-Player fighting in video games,
and it's not gonna work for the lack of end markers.

Explicit is better than implicit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Wed, 03 Nov 2010 02:40:11 +0000, Seebs wrote:
>> Sure, but there's also no way for you to spot that something looks
>> suspicious.  In Python, if something is misindented, it does what you
>> told it to do, and there's no way for you to tell, by looking at it,
>> that it isn't what was intended.  In C, if something is misindented, it
>> does what you told it to do, but it's obvious looking at the code that
>> something went wrong.

> If it's that obvious, why do people keep causing those indentation-
> related bugs in C?

I don't think they do.  I can't remember the last time I've seen one.

> I'm glad for you that you have a finely trained attention to detail that 
> is able to instantly spot misindented C code (or is that misplaced braces 
> and correctly indented?), but it is a notoriously common error which 
> suggests that it's not anywhere near as obvious as you think.

It's "notoriously common", but can you show me an actual example of
it happening in real code?  Not a "hey guys look how misleading this
would be" example conjured up for illustration, but an *actual* example
in live code?

I can't remember one, except I think maybe I saw one somewhere in...
hmm.  No, wait, that was perl.

>> This level of dogmatism about what should always be the case is not
>> conducive to good software engineering practices.

> I question that assertion. Good engineering practices is about setting 
> best practices, and following them, not avoiding them because there might 
> be the odd exception here and there.

I don't think I buy this.  I've seen a whole lot of good writers and good
programmers, and in both groups, they consistently report that you have
to know how the rules work before you break them.

> The language shouldn't make 
> everyone carry the burden of supporting two-page functions all the time, 
> just to save you an insignificant amount of trouble on the vanishingly 
> rare occasion you need a function that is two pages long.

I don't think there's a particularly big burden there.

Explicit is better than implicit.  It is *better* to explicitly mark the
ends of things than to have it be implicit in dropping indentation.  That's
not a burden, it's good engineering practice.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Wed, 03 Nov 2010 01:25:56 +0000, Seebs wrote:
>> Whitespace damage is, indeed, wrong.  It's a bad thing.  It is an
>> *extremely common* bad thing, 

> I question that.

> You've claimed that you have to deal with broken indentation on a regular 
> basis.

I'd guess I see something which got screwed up somehow every couple of
weeks, usually while refactoring stuff.

>> and I fundamentally don't think it was a
>> good choice to build a system with no redundancy against it.

> Python does have some redundancy against indentation mangling. Not all 
> combinations of indentation are legal.

True, but it doesn't seem to catch the most common failure modes.

> And so on. True, there are some failure modes which can't be easily 
> recovered from without reading and understanding the code. That's okay. 
> Such failure modes are vanishingly rare -- for every twenty thousand 
> braces you avoid typing, you might, if you're unlucky, need to fix an 
> instance of broken indentation.

This is ridiculous overstatement.  Moving a single block of overly-nested
code out into a separate method could generate several indentation
mishaps if Something Goes Wrong, which it does sometimes.  I haven't
written more than a couple hundred blocks in Python, so I'm a factor of a
hundred out from twenty thousand braces, and I've had six or seven
indentation problems.

And yes, I can just recreate it, but it takes more effort, since I can't
do things like just handing it to an automated tool that can correct
it completely automatically.

Furthermore, I don't WANT to skip closing braces.  EXPLICIT IS BETTER
THAN IMPLICIT.  I *WANT* to have the beginnings and ends marked.

I want end braces or "end" or something at the end of a block for
the same reason that I prefer:
	x = "hello, world"
to
	x = "hello, world
where we just assume the string ends at the end of the line.

>> That
>> "redundant" information saves our hides on a regular basis in an
>> imperfect world.

> So you say.

Well, it works for me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-03, Seebs <usenet-nospam@seebs.net> wrote:

> Explicit is better than implicit.  It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation.  That's
> not a burden, it's good engineering practice.

Dededenting does explicitly mark the end of a block.

-- 
Grant Edwards               grant.b.edwards        Yow! What PROGRAM are they
                                  at               watching?
                              gmail.com            

On 2010-11-03, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-03, Seebs <usenet-nospam@seebs.net> wrote:
>> Explicit is better than implicit.  It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation.  That's
>> not a burden, it's good engineering practice.

> Dededenting does explicitly mark the end of a block.

If you can't point to the token, it's implicit.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Wed, 03 Nov 2010 18:49:06 +0000, Tim Harig wrote:
>>> Actually I agree with you about tabs. I think tabs are far more logical
>>> and sensible. But I'm stuck with broken tools that don't deal with
>>> tabs,
>> 
>> Where you not the one a few posts back telling Seebs that he needed to
>> change his broken tools?
>
> Yes, and I also said that I sympathized with him if he couldn't.

Perhaps it would be more constructive, for everybody, to make suggestions
on how to reliably transfer code using channels that distort whitespace.

>>> That's very insightful. Why don't you apply some of that insight to the
>>> other side? It is *incredibly* annoying to see the same old people
>>> making the same old snide remarks about the same old issues over and
>>> over again, particularly when:
>> 
>> A large part of the reason that the issue keeps coming up is that the
>> community never really deals with it when it does.
>
> No. The community does deal with it. It deals with it by saying "It isn't 
> going to change." If you want a language that forces you to wrap ever 
> block in BEGIN END tags, you have a thousand choices. Python is not one 
> of them. What is so hard to understand about this?

Please to not mix my contentions with somebody else's.  I have not,
anywhere in this thread, asked to change the language.  I certainly
didn't say *anything* about adding "BEGIN END" tags to the code itself.
I did say that I found code folding markers in the comments to be a
useful form for expressing code structure; but, that has nothing to with
chainging Python itself.  I also expressed my opinion that I felt spaces
for indenting was a poor choice for the standard; but, since it is also
not part of the language proper, it can safely be ignored.

What I did suggest was a more constructive way of dealing with these
criticisms.  You said that you found it "*incredibly* annoying" to have
this to see the same old "snide remarks" from "the same old people."  I
merely suggested that if the community changes its attitude towards those
making those remarks, that it might go a long way towards silencing some of
those descents.  The fact that you are unwilling to make these changes
makes me question your conviction when you claim to be so annoyed.

>> I have enough
>> customer support experience to know that a client is never really
>> satisfied until you acknowledge their problem.  Until the problem is
>> acknowledged, the client will have put up psychological communcation
>> block that prevents them from hearing any workarounds that you might
>> have.
>
> Yes, well that too goes both ways. *I* have a psychological communication 
> block that prevents me from hearing any complaints about the lack of 
> braces from people who refuse to acknowledge that having to type braces 
> is stupid and annoying, and that the use of braces in a language hurts 
> readability.

I understand that you don't like braces; but, I have nowhere advocated
adding them to the Python langauge.  That is a different argument that you
are having with Seebs.

> Frankly, I DON'T CARE how often your editor breaks your source code. I 

Only you have even mentioned editors in this thread.

> don't care about Seeb's mail server that converts his Python code to 
> HTML. I don't give a rat's arse about how many times some buggy ftp 
> client has mangled the indentation on Python files. Not my problem. Your 

Nobody else mentioned ftp servers in this either; but, I must admit that
you are doing a good job of providing evidence for the alternate viewpoint.

> pain is not my pain, and any solution to these problems that involves 
> changing the way I read and write Python code is an anti-solution to a 
> non-problem to me.

Then why bother adding to the noise in this thread at all since it has
nothing to do with you?  I see however, since you have brought all this
baggage to the table that was not otherwise in the thread, that you
obviously have a axe to grind.

> Until the "Python is broken 'cos it has no braces" crowd acknowledge this 
> fact, I just harden my heart against their complaints. Why should *I* 
> have to acknowledge their issues when they don't acknowledge mine?

Then please state your Python language issues rather simply grinding your axe
against those who are stating theirs.

On Wed, 03 Nov 2010 20:35:20 +0000, Seebs wrote:

>>> This level of dogmatism about what should always be the case is not
>>> conducive to good software engineering practices.
> 
>> I question that assertion. Good engineering practices is about setting
>> best practices, and following them, not avoiding them because there
>> might be the odd exception here and there.
> 
> I don't think I buy this.  I've seen a whole lot of good writers and
> good programmers, and in both groups, they consistently report that you
> have to know how the rules work before you break them.

Yes. How does that contradict what I said?

There is a huge difference between knowing when to break the rules, and 
avoiding the rules because there might someday be an exception.


>> The language shouldn't make
>> everyone carry the burden of supporting two-page functions all the
>> time, just to save you an insignificant amount of trouble on the
>> vanishingly rare occasion you need a function that is two pages long.
> 
> I don't think there's a particularly big burden there.

Good for you.

 
> Explicit is better than implicit.

Ah, argument by misunderstanding the Zen!


> It is *better* to explicitly mark the
> ends of things than to have it be implicit in dropping indentation. 
> That's not a burden, it's good engineering practice.

Python does explicitly mark blocks. It does it by changes in indentation. 
An indent is an explicit start-block. An outdent is an explicit end-
block. There is nothing implicit in a change in indent level.

To illustrate the difference, this is how a hypothetical language might 
use implicit end of blocks:


if condition:
true_clause()
another_true_clause()
else:
false_clause()


The if block ends implicitly when you reach an else statement, and the 
else clause implicitly ends... where?

It gets worse:

if condition:
if another_condition:
true_clause()
else:
false_clause()
another_clause()


Such a hypothetical language might decide on a rule that else will always 
match the closest if, or the outermost if that is legal. That would be an 
implicit end of block. This is not even within the same galaxy as what 
Python does.

It simply isn't possible to have implicit start/end block markers, unless 
you restrict your language in ways that exclude most blocks. E.g. if all 
if blocks were restricted to a single statement, then you could have an 
implicit block -- the block in one statement. Stating that Python uses 
implicit block markers is simply wrong.


-- 
Steven

On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au> wrote:
> Yes. How does that contradict what I said?

Once you understand that you do have to break the rules occasionally,
it is a good idea to design things that will be robust when the rules
are broken.

> Ah, argument by misunderstanding the Zen!

I see.  So explicit boundaries are a good thing, except when they are
one specific special case.

Let us imagine a hypothetical mirror-universe person, who is otherwise
like you, but:

1.  Has a goatee.
2.  Actually hates the indentation rules, wishes Python had braces,
but has become emotionally invested in defending the status quo because
if he had to suffer, dammit, everyone else should have to suffer too.

You have not yet made a single argument that he wouldn't have made
too.

>> It is *better* to explicitly mark the
>> ends of things than to have it be implicit in dropping indentation. 
>> That's not a burden, it's good engineering practice.

> Python does explicitly mark blocks. It does it by changes in indentation. 
> An indent is an explicit start-block. An outdent is an explicit end-
> block. There is nothing implicit in a change in indent level.

What's the token that marks the end of a block, corresponding to the
colon used to introduce it?

> It simply isn't possible to have implicit start/end block markers, unless 
> you restrict your language in ways that exclude most blocks. E.g. if all 
> if blocks were restricted to a single statement, then you could have an 
> implicit block -- the block in one statement. Stating that Python uses 
> implicit block markers is simply wrong.

No, it isn't.  There's no token telling you where the block ended.

C *allows* implicit blocks, and this is widely regarded as a key flaw.
However, it also allows you to explicitly mark blocks in a way which
is robust against common errors, allowing software to automatically
fix up differences between, say, competing indentation styles.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 11/03/2010 02:39 PM, Seebs wrote:
> Furthermore, I don't WANT to skip closing braces.  EXPLICIT IS BETTER
> THAN IMPLICIT.  I *WANT* to have the beginnings and ends marked.

I suggest, then that Pascal or Ruby would suit your needs better than
Python.

> I want end braces or "end" or something at the end of a block for
> the same reason that I prefer:
> 	x = "hello, world"
> to
> 	x = "hello, world
> where we just assume the string ends at the end of the line.

Not even close to the same thing, sorry.

As for refactoring code, vim makes it really easy to move blocks in and
out.  The only time I could see this becoming an issue is if functions
or blocks of code are too long to see on a page at once.  If this is the
case, break them up.  Sounds to me like your problems with refactoring
and indention in python could be do to these kinds of design issues.
Having curly braces certainly doesn't help in these situations either.
More than once I've had C code I was refactoring that broke due to the
fact that while trying to move blocks around I misplaced a brace, an
issue I never have in Python.

In the meantime, whitespace structure is one of the things about Python
that I like the *most* about the language.  Being able to crank out
executable pseudo-code is pretty addictive.  And I never write
pseudo-code on paper with begin and end blocks cause it's too much
effort when scribbling by hand.

On Wed, 03 Nov 2010 20:30:43 +0000, Seebs wrote:

> I'm not expecting it to change;

Then why talk about it? Just to hear the sound of your voice? (Or see the 
font of your writing?) To waste our time? To feel more virtuous than 
those who don't see your point of view?

If you don't expect a change, what's the point of this discussion?


> I'm pointing out that insisting that it's not a problem is
> *insulting* to the people for whom it is a problem.


And insisting that it is a problem is equally insulting to those for whom 
it is not a problem.



-- 
Steven

On Wed, 03 Nov 2010 18:49:06 -0000, Tim Harig <usernet@ilthio.net> wrote:

> On 2010-11-03, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au>  
> wrote:
>> On Tue, 02 Nov 2010 19:26:56 +0000, Tim Harig wrote:
>>
>>> I agree with Seebs, Python is the only language I know that promotes  
>>> the
>>> use of spaces over tabs;
>>
>> Really? I'm not aware of *any* language that promotes tabs over spaces.  
>> I
>> thought the tabs vs spaces war was mostly won by spaces over a decade  
>> ago
>> (apart from a few plucky freedom fighters who will never surrender).
>
> Python is the only language that I know that *needs* to specify tabs  
> versus
> spaces since it is the only language I know of which uses whitespace
> formating as part of its syntax and structure.  Mixed usage may be  
> annoying
> in other languages; but, it breaks Python.

I regard this as a strength.  I have wasted far too much time at work  
writing review comments that could be paraphrased as "your broken editor  
settings have made this (C code) unreadable."

-- 
Rhodri James *-* Wildebeest Herder to the Masses

On 11/03/10 15:59, Seebs wrote:
>> Dededenting does explicitly mark the end of a block.
>
> If you can't point to the token, it's implicit.  :)

Just because you asked for it to be pointed to:

http://svn.python.org/view/python/trunk/Include/token.h?view=markup

The DEDENT token is explicitly defined as the number "6", FWIW...

:)

-tkc

On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au> wrote:
> On Wed, 03 Nov 2010 20:30:43 +0000, Seebs wrote:
>> I'm not expecting it to change;

> Then why talk about it?

Because I find technical questions interesting in and of themselves.  I
will happily talk with people about the reasons for which the C preprocessor
is the way it is, even though it's never going to change and we all
hate it like poison.

>> I'm pointing out that insisting that it's not a problem is
>> *insulting* to the people for whom it is a problem.

> And insisting that it is a problem is equally insulting to those for whom 
> it is not a problem.

No, it isn't.

A friend of mine is colorblind.  For him, certain red/green pairings are
indistinguishable.  For me to insist that it is not a problem that a
user interface uses those to distinguish two things is insulting to
him; I am dismissing a very real problem.  For him to insist that it
is a problem for him is in no way insulting me.  He's not saying that it's
a problem for me.  He's merely saying that *there exist* people for whom
it is a problem.

No one has claimed that this is a problem *for everybody*.  Just that
there exist real-world workflows for which it is a problem, or people
for whom it is a problem.

This is an asymmetrical situation.  The opposite of "it's never a
problem for anybody" isn't "it is always a problem for everybody"
but "it is at least sometimes a problem for at least some people."

The reality is, the indentation-instead-of-markers thing *does* sometimes
lead to problems.  We could blame it on tools, but the tools could just as
easily blame the language for being brittle.  Given the degree to which
the rest of the world has standardized on not caring how *much*
whitespace is between things (though sometimes caring whether or not
there's *any* whitespace between them), it seems to me that the odd
man out is the one who is creating the burden.

Once many file formats exist which don't care how many spaces you
use, and many tools have been developed with those file formats in
mind, coming up with a new file format which cares how many spaces you
use seems a little short-sighted.  Demanding that all tools be changed
to fit a new paradigm is a pretty big demand to place on people.

On the whole, I don't personally think the benefits have been worth it.
I think Python would be a better, richer, language if it used explicit
end tokens of some sort.  Maybe it wouldn't.  I do know, though, that
of the programmers I know outside the Python newsgroup, not a single
one likes that aspect of Python.  It is consistently regarded as an
annoying quirk.  Some use Python anyway; it has merits, certainly.  If
I were offered a choice between Python and PHP for a project, I would
*absolutely* pick Python.  (Subject, of course, to the assumption that
the project would in some way involve computers, or programming, or
that I would at some point have to either write code for the project
use it, or possibly come within twenty feet of someone who was working
on it; outside of those limitations, I might consider PHP.)

I feel the same way about pretty much every language I use.  C would
be a much better language if the macro processor weren't such a giant
filesystem verification stage for a filesystem distributed across
multiple machines*.  They all have flaws.

Python's the only language I use where an obvious flaw, which is repeatedly
observed by everyone I know who uses the language, is militantly and
stridently defended by dismissing, insulting, and attacking the character
and motives of anyone who suggests that it might be a bit of a nuisance.

I suspect part of that is simply because it *is* a tradeoff, and there
are good reasons for it.  It offers some advantages.  It's not something
that you'd be insane to like; the problems are easily mitigated once you
know about them, and the benefits are worth it.  If I worked with a lot
more novice-level C programmers who hadn't yet had the importance of
careful style drilled into them, I might well find the indentation problems
people keep talking about to be a real thing, possibly even a very
serious one.

But the fact remains, being brittle in the face of whitespace changes *is*
a flaw.  It breaks code under circumstances which are, for better or
worse, common.  As I pointed out before:  There is a *REASON* that diff
has an option for ignoring whitespace changes -- because they are common
enough that such an option is commonly useful for distinguishing between
real changes and inadvertant ones.

Note that "whitespace indentation" in and of itself isn't the thing I'm
describing as a flaw; it's the side-effect of being brittle when whitespace
changes.  The indentation thing as a whole has some definite plusses, and
it's a tradeoff that I think may even be a good fit for a language
specifically focused on easier readability.

-s
[*] clusterfsck.
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Seebs <usenet-nospam@seebs.net> writes:

> On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au> wrote:
> > Python does explicitly mark blocks. It does it by changes in
> > indentation. An indent is an explicit start-block. An outdent is an
> > explicit end- block. There is nothing implicit in a change in indent
> > level.
>
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?

You have introduced this requirement for tokens; it's fallacious. The
direct answer is: tokens aren't part of the requirement to be explicit.

The more general answer is: the block is explicitly ended where the
indentation ends.

-- 
 \     “I must say that I find television very educational. The minute |
  `\       somebody turns it on, I go to the library and read a book.” |
_o__)                                                    —Groucho Marx |
Ben Finney

Seebs <usenet-nospam@seebs.net> writes:

> Furthermore, I don't WANT to skip closing braces. EXPLICIT IS BETTER
> THAN IMPLICIT. I *WANT* to have the beginnings and ends marked.

Python doesn't require that. You're going to be disappointed by most
Python code if that's what you want.

Which is not a failing of Python.

-- 
 \       “Few things are harder to put up with than the annoyance of a |
  `\                  good example.” —Mark Twain, _Pudd'n'head Wilson_ |
_o__)                                                                  |
Ben Finney

On 2010-11-03, Michael Torrie <torriem@gmail.com> wrote:
> I suggest, then that Pascal or Ruby would suit your needs better than
> Python.

In the absence of network effects, I'd just be using Ruby.  I have reason
to work with projects that have a lot of existing Python, though, so I
use it too.

> As for refactoring code, vim makes it really easy to move blocks in and
> out.

Yes, though I mostly use nvi, same thing -- basically.  The issue I've
had is that the automatic-tab thing (which I actively want for everything
else I edit) tends to make it quirky.

> The only time I could see this becoming an issue is if functions
> or blocks of code are too long to see on a page at once.  If this is the
> case, break them up.  Sounds to me like your problems with refactoring
> and indention in python could be do to these kinds of design issues.
> Having curly braces certainly doesn't help in these situations either.
> More than once I've had C code I was refactoring that broke due to the
> fact that while trying to move blocks around I misplaced a brace, an
> issue I never have in Python.

For me, I'd rather have the compiler choke because I have mismatched
braces than have the code run apparently just fine except that something
has unintentionally moved in or out of an else clause because there was
no marker.  I've had both happen, probably.

> In the meantime, whitespace structure is one of the things about Python
> that I like the *most* about the language.  Being able to crank out
> executable pseudo-code is pretty addictive.  And I never write
> pseudo-code on paper with begin and end blocks cause it's too much
> effort when scribbling by hand.

I never write on paper anyway.  :)

Anyway, I'm not disputing that there are things that it makes nicer.  I'm
just observing that there exists a category of failures which is completely
unique to Python, which no other language (except BF, which I'm not sure
I ought to count) has, which tends to show up occasionally until you've
gotten all the changed tools and habits, and even then can show up when
dealing with other people who use tools which, well, work perfectly for
everything else.  But not for this.

Only other tool I know with a comparable dependance on spacing is Makefiles,
and I have never in my life met someone who used them and didn't think
that was a loathesome error which should never have made it into
production code.  Python's not nearly as bad, actually.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

In message <slrnid0pgs.1028.usenet-nospam@guild.seebs.net>, Seebs wrote:

> The question is *why* diff has that option.
> 
> The answer is because whitespace changes (spaces to tabs, different
> tab stops, etcetera) are an extremely common failure mode, such that
> it's quite common for files to end up with unintentional whitespace
> changes.

Except the diff option is to *ignore* such differences, not highlight them.

In message <slrnid0ked.t7k.usenet-nospam@guild.seebs.net>, Seebs wrote:

> It is extremely useful to me to have spaces converted to tabs
> for every other file I edit.

I’m thinking of going the other way. After many years of treating tabs as 
four-column steps, I might give up on them and use spaces everywhere.

On 11/3/2010 4:09 PM Seebs said...

> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?
>


My thoughts tend more towards 'can we get Guido to eliminate the colon 
requirements' -- The indent level of the next line ought to suffice.

Seriously.

Emile

On 2010-11-04, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <slrnid0pgs.1028.usenet-nospam@guild.seebs.net>, Seebs wrote:
>> The answer is because whitespace changes (spaces to tabs, different
>> tab stops, etcetera) are an extremely common failure mode, such that
>> it's quite common for files to end up with unintentional whitespace
>> changes.

> Except the diff option is to *ignore* such differences, not highlight them.

Yes.  That's because those changes are irrelevant, so people don't
care about them, so they want an option to handle the common case where
whitespace got changed but no one cares about that.

But unintentional whitespace changes are common enough that you *need*
the ability to filter them out and just look at "real" changes.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-04, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <slrnid0ked.t7k.usenet-nospam@guild.seebs.net>, Seebs wrote:
>> It is extremely useful to me to have spaces converted to tabs
>> for every other file I edit.

> I???m thinking of going the other way. After many years of treating tabs as 
> four-column steps, I might give up on them and use spaces everywhere.

I *absolutely must* use tabs for Makefiles.

For code in most other languages, it's merely a factor of 8 improvement
in storage.  :)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-04, Emile van Sebille <emile@fenx.com> wrote:
> On 11/3/2010 4:09 PM Seebs said...
>
>> What's the token that marks the end of a block, corresponding to the
>> colon used to introduce it?
>>
>
>
> My thoughts tend more towards 'can we get Guido to eliminate the colon 
> requirements' -- The indent level of the next line ought to suffice.

But without the colon, how are people who write programming editors
going to know when to increase the indentation level as I enter code?

> Seriously.

Just as seriously.

Syntactic sugar isn't just for humans...

-- 
Grant

On 2010-11-04, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-04, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>> In message <slrnid0ked.t7k.usenet-nospam@guild.seebs.net>, Seebs wrote:
>>> It is extremely useful to me to have spaces converted to tabs
>>> for every other file I edit.
>
>> I???m thinking of going the other way. After many years of treating tabs as 
>> four-column steps, I might give up on them and use spaces everywhere.

I quit using tabs (except for Makefiles) about 30 years ago.

> I *absolutely must* use tabs for Makefiles.

And my editor (emacs) knows that.  It uses tabs in Makefiles and
spaces everywhere else.

> For code in most other languages, it's merely a factor of 8 improvement
> in storage.  :)

That's only true if your source code consists entirely of tabs.

;)

-- 
Grant

On Wed, 03 Nov 2010 23:09:10 +0000, Seebs wrote:

> On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au>
> wrote:
>> Yes. How does that contradict what I said?
> 
> Once you understand that you do have to break the rules occasionally, it
> is a good idea to design things that will be robust when the rules are
> broken.

That does not follow.

As a general rule, one should not expect that electronic equipment should 
be safe to operate under water. But there are exceptional cases. So what 
should we do?

(1) Insist that all consumer electronic equipment is designed to operate 
under water? (All blocks need redundant START/END tags just in case 
you're operating in an environment where indentation can't be trusted.)

(2) Tell people not to drop their toaster into the bath tub, and leave it 
up to the exceptional cases to deal with the need for water-proof 
electronics in whatever way they see fit? (Trust the indentation, tell 
people not to mangle their source files with dodgy mail servers, and if 
you need redundant tags, build your own solution.)



>> Ah, argument by misunderstanding the Zen!
> 
> I see.  So explicit boundaries are a good thing, except when they are
> one specific special case.

INDENT/OUTDENT is an explicit boundary.


> Let us imagine a hypothetical mirror-universe person, who is otherwise
> like you, but:
> 
> 1.  Has a goatee.
> 2.  Actually hates the indentation rules, wishes Python had braces, but
> has become emotionally invested in defending the status quo because if
> he had to suffer, dammit, everyone else should have to suffer too.

I had to suffer?

Funny, I hardly noticed.


 
> You have not yet made a single argument that he wouldn't have made too.

The arguments Evil-Steven would make would be your arguments:

* redundant BEGIN/END tags make blocks robust in environments where 
indentation can't be trusted;

* there are tools out there that assume that indentation is meaningless, 
and some people want to use those tools, so the language is poorly 
designed;

I *understand* your arguments, I just don't value them. But in fact, non-
evil Steven made the opposite arguments:

Re extra redundancy: you aren't going to need it often enough to make up 
for the extra effort of dealing with BEGIN/END tags that can contradict 
the indentation.

Re tools: if the tools don't fit your use-case, your tools are broken, 
and you should change your tools.



>>> It is *better* to explicitly mark the ends of things than to have it
>>> be implicit in dropping indentation. That's not a burden, it's good
>>> engineering practice.
> 
>> Python does explicitly mark blocks. It does it by changes in
>> indentation. An indent is an explicit start-block. An outdent is an
>> explicit end- block. There is nothing implicit in a change in indent
>> level.
> 
> What's the token that marks the end of a block, corresponding to the
> colon used to introduce it?

Your assumption is incorrect. Blocks are introduced by an increase in 
indentation level, not by a colon. The colon is enforced, but it's there 
for the benefit of readability rather than to mark a new block. You can 
write:

if condition: true_clause()
else: false_clause()

No blocks are started, the clauses are limited to a single line, but the 
colons are still required.

To end the block, you need a decrease in indentation limit. In fact, the 
Python parser actually places overt INDENT/OUTDENT tokens into the token 
stream.

# From token.py:
INDENT = 5
DEDENT = 6


>> It simply isn't possible to have implicit start/end block markers,
>> unless you restrict your language in ways that exclude most blocks.
>> E.g. if all if blocks were restricted to a single statement, then you
>> could have an implicit block -- the block in one statement. Stating
>> that Python uses implicit block markers is simply wrong.
> 
> No, it isn't.  There's no token telling you where the block ended.

I disagree, but for the sake of the argument let's suppose you are 
correct. So what?

x = 123+456

There's no tokens telling you where the ints 123 and 456 begin and end 
either. So where's the problem?

Signals, or tokens if you like, can be explicitly made either by placing 
a distinct marker (a delimiter or separator), or by a change of state. In 
the case of ints, the explicit end-of-token is a change of state, not a 
marker:

digit digit digit non-digit

There's no need for a distinct End Of Int marker, because the change of 
state is explicit enough. But this is not the case for strings, which you 
mentioned in an earlier post. Strings require a special BEGIN/END tag 
because they may be terms in expressions and you can't assume they will 
end at the end of the line (a change of state).

If you have an environment where strings do end at the end of the line, 
such as INI files, you can avoid the delimiters:

[section]
x = Hello world.
y = Goodnight Gracie!


but in a general purpose programming language where strings can be terms 
in expressions, you need delimiters.

Blocks are more like ints than strings. They don't need delimiters, 
because they start and end according to an explicit change of state.


-- 
Steven

On Wed, 03 Nov 2010 23:42:55 +0000, Seebs wrote:

> No one has claimed that this is a problem *for everybody*.  Just that
> there exist real-world workflows for which it is a problem, or people
> for whom it is a problem.

And people have suggested that if your workflow leads to indentation 
being mangled and your source code no longer running, the solution is to 
change the workflow. If you can't change the workflow, you have my 
sympathy, but that's not Python's fault, and Python isn't designed for 
your use-case of web servers that convert your source code to HTML and 
text editors that mangle indentation.

Nor is Python designed for use on computers where the file system 
randomly corrupts files, or a work-flow where your Pointy-Haired boss 
keeps making random changes to production scripts in an effort to prove 
he knows best. If you have such a work-flow, don't suggest that we should 
add error-correcting codes to the language in order to fix your problem. 
We can sympathize with your troubles while still saying Not Our Problem.


> Given the
> degree to which the rest of the world has standardized on not caring how
> *much* whitespace is between things (though sometimes caring whether or
> not there's *any* whitespace between them), it seems to me that the odd
> man out is the one who is creating the burden.

What burden? You keep talking about this burden of not-having-to-type-
braces, but I don't see any burden, and nor do the majority of Python 
programmers.

What we see is dozens of languages, and thousands of people, who have 
built all these wonderful devices and tools for helping them carry a 
refrigerator on their head (a bar fridge, naturally, it would be foolish 
to carry a full-sized fridge and freezer combo). That's fine if you need 
to carry a fridge on your head, and I'm really glad that your tools take 
90% of the weight for you. I'm sure you hardly even notice it any more.

But then you start arguing that it's *really important* to carry a fridge 
on your head *everywhere* because you never know when you'll be somewhere 
where you MUST HAVE a fridge, and all hell will break loose if you don't 
have one, well, we just think you're a bit strange.

It's not that we don't think fridges are useful. And we understand the 
logic -- yes, if you need a fridge and don't have one, bad things will 
happen, but why limit it to fridges? Why not a sewing machine, and a jack 
hammer, and a piano, and ... there's no limit to the number of things you 
might need, and the difference in risk between not having any of them and 
not having any of them bar one is negligible.

And then you start telling us how we're the weird ones because we have 
the "burden" of not-carrying-a-fridge everywhere!



-- 
Steven

On 2010-11-04, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au> wrote:
> And people have suggested that if your workflow leads to indentation 
> being mangled and your source code no longer running, the solution is to 
> change the workflow.

Yup.

But it strikes me as unmistakably a shortcoming of Python (and Makefiles,
for that matter) that code for them can't survive a common failure mode
that everything else I use can.

> What burden?

The burden of using different tools because suddenly the version of vi
I've been using since 1990 is magically "broken" even though it's never
caused a problem before.

> You keep talking about this burden of not-having-to-type-
> braces, but I don't see any burden, and nor do the majority of Python 
> programmers.

Of course not.  Most of the people who find it annoying *don't use Python*.

Of the programmers I know who don't use Python, 100% have cited the annoyance
value *to them* of the whitespace thing as the main reason they don't.  Of
the programmers I know outside this newsgroup who *do* use Python, 100% have
said the whitespace thing is annoying and they wish Python didn't have it,
but they have to use Python for some externally-imposed reason, so they put
up with it.

Outside of people who seem to be deeply emotionally invested in insisting
that it is never, at all, in ANY way, for ANY person, annoying, it seems
to be pretty consistent to observe that, benefits or no benefits, it has
some kind of non-zero annoyance value.

Other languages I use are mostly amenable to the development of tools
to automatically indent code.  Makefiles and Python are the only two
exceptions... And if I were an advocate for a language, the fact that it's
lumped itself in with Makefiles in a significant way would be a weakness
I'd feel obliged to be up front about.  :)

The underlying issue is this:

* Not having to type braces:  Yay!
* Having structure map to functionality:  Some people quite like it, and
  certainly there exists a class of theoretical errors which it prevents.
* Not being able to write an auto-indenter, ever, because it is by
  design theoretically impossible:  Annoying.

I guess if people could show me some of these errors in other languages
where indentation is misleading and bugs resulted, I'd be more persuaded
by the second point there.  As is, I find the brittleness more annoying
than I've ever found braces or 'end' or whatever.  It's not annoying
enough for me to refuse to use the language when there are other
compelling reasons to, but it's certainly annoying enough that I'll never
use Python for something where I have unfettered choice of language.  It's
less fun to program in, for me.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On Wed, Nov 03, 2010 at 11:37:03AM +0000, Steven D'Aprano wrote:
> On Wed, 03 Nov 2010 12:01:06 +1300, Lawrence D'Oliveiro wrote:
> 
> > In message <ianem3$cuq$1@reader1.panix.com>, Grant Edwards wrote:
> 
> >> Other languages have similar problems if you remove salient bits of
> >> syntax before comparing two source files files.
> > 
> > But other languages don???t make those ???salient bits of syntax??? invisible.
> > I.e. they are actually ???salient???.
> 
> (1) Indentation is visible. Compare:
> 
> 
>     This line has leading visible whitespace.
> 
> This line has leading invisible characters.
> 
> See the difference?

Unless, your code is split over different pages, as when it is printed in a book.
You also need to see the next piece of code to notice the dedention.

e.g. I have the following code at the bottom of my editor.

  for i := 0 to 9 do
    some(code);
    more(code);
  end;

I can by just looking at this code notice that I'm looking at the whole for block.


But when I have similar python code at the bottom of the page.

  for i in xrange(10):
    some(code)
    more(code)

Then I can't make out whether I'm looking at the whole for suite or not.

Indentation may be visible, but it is not context-free visible, It only
becomes visible by looking by introducing context. So because it is only
visible by looking at the context I would say the end of a block i made
implicitly and not explicitly

-- 
Antoon Pardon

Antoon Pardon wrote:
> Unless, your code is split over different pages, as when it is printed in a book.
> You also need to see the next piece of code to notice the dedention.
>
> e.g. I have the following code at the bottom of my editor.
>
>   for i := 0 to 9 do
>     some(code);
>     more(code);
>   end;
>
> I can by just looking at this code notice that I'm looking at the whole for block.
>
>
> But when I have similar python code at the bottom of the page.
>
>   for i in xrange(10):
>     some(code)
>     more(code)
>
> Then I can't make out whether I'm looking at the whole for suite or not.
These code pieces are not equivalent -- you have four lines of code in 
the first piece, only three lines in the python piece; in other words, 
if the "end;" were not on screen, you would still have no idea if it was 
the whole block or not; in still other words, the "end;", just like the 
dedented line, provides the context.

~Ethan~

On 2010-11-04, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-04, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au> wrote:
>> And people have suggested that if your workflow leads to indentation 
>> being mangled and your source code no longer running, the solution is to 
>> change the workflow.
>
> Yup.
>
> But it strikes me as unmistakably a shortcoming of Python (and Makefiles,
> for that matter) that code for them can't survive a common failure mode
> that everything else I use can.

I think the issue is that for whatever reason, white-space mangling is
"a common failure mode" for you.  I don't ever remember it happening
to me.  If whitespace mangling is common for you, then you just
shouldn't be using Python any more than somebody who works on a system
that randomly changes/deletes the strings "begin" and "end" should be
using Pascal.

-- 
Grant Edwards               grant.b.edwards        Yow! PEGGY FLEMMING is
                                  at               stealing BASKET BALLS to
                              gmail.com            feed the babies in VERMONT.

Grant Edwards wrote:
> On 2010-11-04, Emile van Sebille <emile@fenx.com> wrote:
>> On 11/3/2010 4:09 PM Seebs said...
>>
>>> What's the token that marks the end of a block, corresponding to the
>>> colon used to introduce it?
>>>
>>
>> My thoughts tend more towards 'can we get Guido to eliminate the colon 
>> requirements' -- The indent level of the next line ought to suffice.
> 
> But without the colon, how are people who write programming editors
> going to know when to increase the indentation level as I enter code?
> 
Hopefully by the keywords used to introduce the block: if, elif, else, 
for, while, with, etc. etc.  It is not legal to start a new indented 
block just by appending a colon to the previous line.

~Ethan~

On Fri, Nov 05, 2010 at 06:29:11AM -0700, Ethan Furman wrote:
> Antoon Pardon wrote:
> >Unless, your code is split over different pages, as when it is printed in a book.
> >You also need to see the next piece of code to notice the dedention.
> >
> >e.g. I have the following code at the bottom of my editor.
> >
> >  for i := 0 to 9 do
> >    some(code);
> >    more(code);
> >  end;
> >
> >I can by just looking at this code notice that I'm looking at the whole for block.
> >
> >
> >But when I have similar python code at the bottom of the page.
> >
> >  for i in xrange(10):
> >    some(code)
> >    more(code)
> >
> >Then I can't make out whether I'm looking at the whole for suite or not.
> These code pieces are not equivalent -- you have four lines of code
> in the first piece, only three lines in the python piece; in other
> words, if the "end;" were not on screen, you would still have no
> idea if it was the whole block or not; in still other words, the
> "end;", just like the dedented line, provides the context.

That one piece of code is only three lines and the other is four
doesn't make them not equivallent. Adding a fourth (empty) line
to the python example wouldn't have changed things significantly.

These two pieces are equivallent in any significant way. Both
are examples of a for loop, one with its block the other with
its suite. They are both complete for-statements as defined by
the respective grammes. Both perform the same functionality.

The complete for-statement is all you need to see, to know
you are seeing the complete for-statement in the first example.
So all you need is in context information.

To know you see the complete for statement in python, you need
to see more than just the complete for-statement. You need out
of context information.

-- 
Antoon Pardon

On 2010-11-05, Ethan Furman <ethan@stoneleaf.us> wrote:
> Grant Edwards wrote:
>> On 2010-11-04, Emile van Sebille <emile@fenx.com> wrote:
>>> On 11/3/2010 4:09 PM Seebs said...
>>>> What's the token that marks the end of a block,
>>>> corresponding to the colon used to introduce it?
>>>
>>> My thoughts tend more towards 'can we get Guido to eliminate
>>> the colon requirements' -- The indent level of the next line
>>> ought to suffice.
>> 
>> But without the colon, how are people who write programming
>> editors going to know when to increase the indentation level
>> as I enter code?
>
> Hopefully by the keywords used to introduce the block: if,
> elif, else, for, while, with, etc. etc.  It is not legal to
> start a new indented block just by appending a colon to the
> previous line.

The handsome ':' terminator of if/elif/if statements allows us to
omit a newline, conserving vertical space. This improves the
readability of certain constructs.

if x: print(x)
elif y: print(y)
else: print()

versus

if x
    print(x)
elif y
    print(y)
else
    print()

Beauty-is-in-the-eye-of-the-BDFLly-yours,

-- 
Neil Cerutti

On 04 Nov 2010 08:17:10 GMT
Seebs <usenet-nospam@seebs.net> wrote:
> Outside of people who seem to be deeply emotionally invested in insisting
> that it is never, at all, in ANY way, for ANY person, annoying, it seems
> to be pretty consistent to observe that, benefits or no benefits, it has
> some kind of non-zero annoyance value.

Who are these people that believe that no one finds indentation as
syntax annoying?  I haven't seen any evidence in this group.  Let's
leave the straw men out of this.  Many of us don't find it annoying
ourselves, that's for sure but we aren't trying to read anyone else's
mind.  We're all pretty sure that *you* find it annoying but there is
no telepathy involved there.

> * Not having to type braces:  Yay!

Which I always found annoying given that I was already adding signals
(indentation) that I was starting a block.

> * Having structure map to functionality:  Some people quite like it, and

Some of us think that it is a contender for the single greatest thing
about Python.

> * Not being able to write an auto-indenter, ever, because it is by
>   design theoretically impossible:  Annoying.

Right.  And in C you can never write an auto-bracer for exactly the
same reason.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On 10/31/2010 6:52 AM, jf wrote:
> Le 31/10/2010 13:10, Martin v. Loewis a �crit :
>>> I've a project with tabs and spaces mixed (yes I know it's bad).
>>>
>>> I edit each file to remove tabs, but it's so easy to make a mistake.
>>> Do you know a tools to compare the initial file with the cleaned one to
>>> know if the algorithms are the same ?
>>
>> Tools/scripts/reindent.py of the standard Python distribution normalizes
>> white space in source code.
>
> So great, you save my time !
> Should I be worry about this comment in reindent.py "So long as the
> input files get a clean bill of health from tabnanny.py, reindent should
> do a good job." ?

    Are both of those tools consistent with the interpretation of mixed 
tabs and spaces in Python 3.x?

    The current CPython parser front end is smart about this.  Tabs
and spaces can be mixed provided that the semantics of the program
do not depend on the width of a tab.  This was not the case in
early 2.x versions.  (When did that go in?)

    The key to doing this right is to compare the whitespace of an
indented line with the line above it.  The longer whitespace string must
start with the shorter whitespace string, whether it's tabs, spaces, or
any combination thereof.  If it does not, the indentation is ambiguous.
For all unambiguous cases, you can then convert tabs to spaces or vice
versa with any number of spaces to tabs, and the semantics of the
program will not change.

    It's not clear whether "tabnanny" or "reindent" have smart semantics
like CPython.  The documentation doesn't say.  If they don't, they
should, or it should be documented that they're broken.

				 John Nagle

Seebs <usenet-nospam@seebs.net> writes:

> Python's the only language I use where an obvious flaw, which is
> repeatedly observed by everyone I know who uses the language, is
> militantly and stridently defended by dismissing, insulting, and
> attacking the character and motives of anyone who suggests that it
> might be a bit of a nuisance.

So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
a pretty similar reaction.

My observations on this general discussion.

  * Python is far from unique in its use of significant whitespace.
    Miranda was inferring program structure from indentation in 1985.
    Haskell and F# are more modern examples.

  * I don't have many problems with tools trashing whitespace in Python
    programs, though I have seen web forum software mangling
    indentation; since this makes nontrivial chunks of almost any
    programming language illegible, I'm more than willing to blame the
    forum software for this.  I haven't personally seen indentation
    trashed by email software, for example (though I steer well clear of
    people who try to send me HTML mail).

  * I /do/ have a significant problem with cutting and pasting code in
    Python.  In most languages, I can haul a chunk of code about, hit
    C-M-q, and Emacs magically indents the result properly.  This is,
    unfortunately, impossible with Python.  It has caused me real bugs,
    and I have to be extra careful to fix the indentation up.

  * I've just noticed that Emacs's Python mode has a magic keystroke
    which appears to do the right thing for cut-and-pasted code.  This
    is symptomatic of a bigger problem: simply by being different from
    the mainstream, Python requires that one work with it differently.
    It requires different tools, and different techniques.  Many
    languages use some kind of brackets to mark substructure, so tools
    have become good at handling bracketed substructure, whether for
    automatic indentation or navigation.  Python marks (some)
    substructure differently, so users need to learn new techniques or
    tools for working with it.

I /like/ Python.  I use it frequently.  I /don't/ want to change its
structure marked by indentation.  I'm /willing/ to put up with some
inconvenience because Python makes up for it in other ways.  But there
/is/ inconvenience, and it does need putting up with.  I think the
benefits are worth the costs; others may disagree.

-- [mdw], a smug Lisp weenie at heart.

Tim Harig <usernet@ilthio.net> writes:

> Python is the only language that I know that *needs* to specify tabs
> versus spaces since it is the only language I know of which uses
> whitespace formating as part of its syntax and structure.

You need to get out more.  Miranda, Gofer, Haskell, F#, make(1), and
many others, all use indentation to indicate structure; YAML isn't a
programming language, but it also uses indentation to indicate
structure, as do a number of wiki markup languages; there are also
representations of Lisp S-expressions which use indentation instead of
parentheses.

> Mixed usage may be annoying in other languages; but, it breaks Python.

I disagree.  The Haskell '98 report specifies (correctly) that tabs are
every eight columns, and a tab moves to the next tab stop.  Python makes
the same specification; it's just the users who actually want to stamp
out tabs.

Flamebait: it's not the tabs that cause the problem: it's that some
people are under the mistaken impression that the position of tab stops
in text files is a matter for local preference.

-- [mdw]

On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> * Not being able to write an auto-indenter, ever, because it
>> is by design theoretically impossible:  Annoying.
>
> Right.  And in C you can never write an auto-bracer for exactly
> the same reason.

It's not right, actually. Auto-indent is fairly easy in
Python. Auto-dedent is the impossible part.

-- 
Neil Cerutti

On 2010-11-04, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>>> * Not being able to write an auto-indenter, ever, because it
>>> is by design theoretically impossible:  Annoying.
>>
>> Right.  And in C you can never write an auto-bracer for exactly
>> the same reason.
>
> It's not right, actually. Auto-indent is fairly easy in
> Python. Auto-dedent is the impossible part.

I think in common usage the term "auto-intender" refers to a program
that can automatically control source indentation (which inclulde both
"indenting" and "dindenting" source lines).

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having BEAUTIFUL
                                  at               THOUGHTS about the INSIPID
                              gmail.com            WIVES of smug and wealthy
                                                   CORPORATE LAWYERS ...

On 04/11/2010 16:49, Mark Wooding wrote:
> Seebs<usenet-nospam@seebs.net>  writes:
>
>> Python's the only language I use where an obvious flaw, which is
>> repeatedly observed by everyone I know who uses the language, is
>> militantly and stridently defended by dismissing, insulting, and
>> attacking the character and motives of anyone who suggests that it
>> might be a bit of a nuisance.
>
> So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
> a pretty similar reaction.
>
> My observations on this general discussion.
>
>    * Python is far from unique in its use of significant whitespace.
>      Miranda was inferring program structure from indentation in 1985.
>      Haskell and F# are more modern examples.
>
occam was doing it in 1983.

>    * I don't have many problems with tools trashing whitespace in Python
>      programs, though I have seen web forum software mangling
>      indentation; since this makes nontrivial chunks of almost any
>      programming language illegible, I'm more than willing to blame the
>      forum software for this.  I haven't personally seen indentation
>      trashed by email software, for example (though I steer well clear of
>      people who try to send me HTML mail).
>
If you don't use <pre> ... </pre> or some such then any programming
language is going to look bad!

[snip]

On 11/4/2010 7:15 AM Neil Cerutti said...
> The handsome ':' terminator of if/elif/if statements allows us to
> omit a newline, conserving vertical space. This improves the
> readability of certain constructs.
>
> if x: print(x)
> elif y: print(y)
> else: print()
>

Analogously, x+=1;y=f(x);return

We don't have to eliminate ':'s.

Emile

On 2010-11-04, Mark Wooding <mdw@distorted.org.uk> wrote:
> Tim Harig <usernet@ilthio.net> writes:
>
>> Python is the only language that I know that *needs* to specify tabs
>> versus spaces since it is the only language I know of which uses
>> whitespace formating as part of its syntax and structure.
>
> You need to get out more.  Miranda, Gofer, Haskell, F#, make(1), and

I have never heard of Gofer.

I have heard the name Miranda and I know that it is a (purely?) functional
language; but, that is all that I know.

I took a cursory look at Haskell a while back; but, I ultimately chose to
learn Erlang instead as its error management constructs had real world
application for me.

I also looked at F# and Scala; but, neither are really applicable on my
chosen platform.  With F# being such a new language, I suspect that it
borrowed its indent practices either from Haskell or from Python.

I already introduced the make tab oriented syntax and Seebs has labeled it
as a major anti-pattern.

I am also aware of other langauges such as Boo; but, I don't really
consider them individually relevant to the conversation as they are
explicitly using a Python based syntax.  For this discussion I merely group
them with Python.

>> Mixed usage may be annoying in other languages; but, it breaks Python.
>
> I disagree.  The Haskell '98 report specifies (correctly) that tabs are
> every eight columns, and a tab moves to the next tab stop.  Python makes
> the same specification; it's just the users who actually want to stamp
> out tabs.

So, your telling me that mixing tabs and spaces is considered a good
practice in Haskell?  No, mixing tabs and spaces in Python isn't illegal;
but, I have never seen good outcomes from doing so.  No matter how you
define a tab, most people do not have their editor configured to show them
the difference between a tab stop and the equivilant number of spaces.
I have never experienced ill effects from using tabs alone.

> Flamebait: it's not the tabs that cause the problem: it's that some
> people are under the mistaken impression that the position of tab stops
> in text files is a matter for local preference.

I would argue that text files do not have tab stops -- text editors do.  So
long as you use tabs for all of your indenting, it is quite safe to set the
editors tab stops however one likes since the editor's tab stop doesn't
effect the output of the file.  That way, everybody can edit their code
using an apparent indent level that is comfortable for them without being
disruptive to the code.  It is a win-win situation for everybody.

On 2010-11-04, Neil Cerutti <neilc@norwich.edu> wrote:
> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
Seebs Wrote:
>>> * Not being able to write an auto-indenter, ever, because it
>>> is by design theoretically impossible:  Annoying.
>>
>> Right.  And in C you can never write an auto-bracer for exactly
>> the same reason.
>
> It's not right, actually. Auto-indent is fairly easy in
> Python. Auto-dedent is the impossible part.

What Seebs is refering to is that it is difficult or impossible to
re-indent Python source automatically after the indent structure has been
broken (such as his email being converted to html on the server or a web
forum without the possibility of <pre> or [code] tags).  When C becomes
so obfiscated, you can run it through indent to recover the structure of
the source to something that you are familiar with (I actually think macros
could cause problems; but, Seebs has already admitted weaknesses in the C
preprocessor.).  The same is not always true for Python where information
about the code structure may be destroyed.

On 2010-11-04, MRAB <python@mrabarnett.plus.com> wrote:
> On 04/11/2010 16:49, Mark Wooding wrote:
>> Seebs<usenet-nospam@seebs.net>  writes:
>>    * I don't have many problems with tools trashing whitespace in Python
>>      programs, though I have seen web forum software mangling
>>      indentation; since this makes nontrivial chunks of almost any
>>      programming language illegible, I'm more than willing to blame the
>>      forum software for this.  I haven't personally seen indentation
>>      trashed by email software, for example (though I steer well clear of
>>      people who try to send me HTML mail).
>>
> If you don't use <pre> ... </pre> or some such then any programming
> language is going to look bad!

Looking bad and being unrecoverable are two different things.

On 2010-11-04, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-04, Neil Cerutti <neilc@norwich.edu> wrote:
>> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>>>> * Not being able to write an auto-indenter, ever, because it
>>>> is by design theoretically impossible:  Annoying.
>>>
>>> Right.  And in C you can never write an auto-bracer for
>>> exactly the same reason.
>>
>> It's not right, actually. Auto-indent is fairly easy in
>> Python. Auto-dedent is the impossible part.
>
> I think in common usage the term "auto-intender" refers to a
> program that can automatically control source indentation
> (which inclulde both "indenting" and "dindenting" source
> lines).

Thanks for the correction. Autoindent doesn't mean that to me
(I'm a vi user), but I should have figured out what he meant from
the context.

-- 
Neil Cerutti

On Thu, 4 Nov 2010 17:55:55 +0000 (UTC)
Tim Harig <usernet@ilthio.net> wrote:
> What Seebs is refering to is that it is difficult or impossible to
> re-indent Python source automatically after the indent structure has been
> broken (such as his email being converted to html on the server or a web

Right.  If you mangle spaces in Python or mangle braces in C then
recovery becomes impossible.  I don't think anyone is contesting that.
What we question is the idea that somehow Python is special in this
regard.  If you move files around in ways that change them then your
tools are broken.  The fact that the breakage is somewhat "friendlier"
to some types of files is interesting but irrelevant.  What would you
say to a file transfer program that changed Word documents?  What about
executable files?

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Tim Harig <usernet@ilthio.net> writes:

> So, your telling me that mixing tabs and spaces is considered a good
> practice in Haskell?

It doesn't seem to be a matter which is discussed much.  I think Haskell
programmers are used to worrying their brains with far more complicated
things like wobbly[1] types.

> I would argue that text files do not have tab stops -- text editors
> do.  So long as you use tabs for all of your indenting, it is quite
> safe to set the editors tab stops however one likes since the editor's
> tab stop doesn't effect the output of the file.

This is wishful thinking.  Firstly, code written with a narrow
indentation offset (e.g., two spaces) can take up an uncomfortable width
when viewed with a wider offset.

Secondly, if you want other parts (e.g., per-line comments) of lines
with different indentations to align, then you'll have to take into
account the tab width.  Technically, you could arrange that between any
pair of alignment points of any pair of lines there are the same number
of tab characters; but this is also doomed to uncomfortably wide lines;
it also suffers because it imposes an /a priori/ upper bound on the
indentation level.

[1] Proper technical term.  I kid you not.

-- [mdw]

On 2010-11-04, Mark Wooding <mdw@distorted.org.uk> wrote:
> Tim Harig <usernet@ilthio.net> writes:
> This is wishful thinking.  Firstly, code written with a narrow
> indentation offset (e.g., two spaces) can take up an uncomfortable width
> when viewed with a wider offset.

I can accept that as a trade-off.  People have different ideas about
acceptable column width anyway.  I use 8 space tab stops and target 
to no more then 80 columns.  If somebody uses 2 space tab stops, its going
to go over the 80 columns a little bit; but, not so much as cause a major
issue.

> Secondly, if you want other parts (e.g., per-line comments) of lines
> with different indentations to align, then you'll have to take into
> account the tab width.  Technically, you could arrange that between any
> pair of alignment points of any pair of lines there are the same number
> of tab characters; but this is also doomed to uncomfortably wide lines;
> it also suffers because it imposes an /a priori/ upper bound on the
> indentation level.

I use simple comments that are not effected by white space.  I don't waste
my time trying to make comments look artistic.  They are there to convey
information; not to look pretty.  I really detest having to edit other
peoples comment formatting where you have to re-align everything if the
length of any of comment lines change.

On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On Thu, 4 Nov 2010 17:55:55 +0000 (UTC)
> Tim Harig <usernet@ilthio.net> wrote:
>> What Seebs is refering to is that it is difficult or impossible to
>> re-indent Python source automatically after the indent structure has been
>> broken (such as his email being converted to html on the server or a web
>
> Right.  If you mangle spaces in Python or mangle braces in C then
> recovery becomes impossible.  I don't think anyone is contesting that.

Examples of communication channels that mangle white space abound.  I don't
know of any that mangle either braces or pascal style start/end blocks.

You are the one who seems to be on a crusade against against braces.  It
would seem to me, that if you want people to accept that white space
formatting is superior, that you would be looking for a simple way to solve
the white space mangling problem.

> What we question is the idea that somehow Python is special in this
> regard.  If you move files around in ways that change them then your
> tools are broken.  The fact that the breakage is somewhat "friendlier"

The world is full of broken tools that many of us have to use; but, why
should we accept that your choice is superior when other choices manage to
work with these tools without issues.

> tools are broken.  The fact that the breakage is somewhat "friendlier"
> to some types of files is interesting but irrelevant.  What would you
> say to a file transfer program that changed Word documents?  What about
> executable files?

Transfering binary programs has always been an issue and using text based
communications (preferably human readable) has always been considered a
good design decision.  I put up with Python's white space idiosyncrasies;
I wouldn't even bother looking at a language that requires me to enter
the source in binary.  I also consider the move toward XML based document
formats a move in the right direction.

On Thu, 4 Nov 2010 19:37:25 +0000 (UTC)
Tim Harig <usernet@ilthio.net> wrote:
> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> You are the one who seems to be on a crusade against against braces.  It

You totally misunderstand me.  I am not on a crusade of any sort.  I am
happy with Python and the number of other people who are happy with it
is interesting but does not change my life in any significant way.  As
long as there are enough people using it to keep it alive that's all I
care about.  If no one was on a crusade to convince people that
indentation as syntax (can we call is IAS from now on?) was evil then I
wouldn't be posting anything at all on the subject.  I am being totally
reactionary here.

> would seem to me, that if you want people to accept that white space
> formatting is superior, that you would be looking for a simple way to solve
> the white space mangling problem.

I might if it was a problem for me.

> The world is full of broken tools that many of us have to use; but, why
> should we accept that your choice is superior when other choices manage to
> work with these tools without issues.

You don't have to accept anything.  Choose your own tools.  I happen to
choose Python and the tools that I choose to use work fine for me.

> the source in binary.  I also consider the move toward XML based document
> formats a move in the right direction.

Don't get me started on XML.  ;-)

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> Right.  If you mangle spaces in Python or mangle braces in C then
> recovery becomes impossible.  I don't think anyone is contesting that.
> What we question is the idea that somehow Python is special in this
> regard.  If you move files around in ways that change them then your
> tools are broken.  The fact that the breakage is somewhat "friendlier"
> to some types of files is interesting but irrelevant.

Again, why does "diff -b" exist?

It exists because so many things change whitespace unintentionally that
it's a common failure mode.  Thus, people developing data file formats
often put substantial effort into *guaranteeing* that they will survive
changes to the contents of blocks of whitespace -- it won't matter
whether you used spaces or tabs, or how many spaces there are.  This
is done because, if you don't do it, your files sometimes get broken.

I have never heard of a problem where sending something via a common
commercial mail client with its default settings resulted in the
destruction of braces.  I have regularly seen people report that one
mail client or another is losing or adding spaces, converting tabs
to spaces, converting spaces to tabs, or whatever.

To some extent, it may be largely a matter of convention; it is
conceivable that, had Python been a major and influential language
in 1970, tools in general would be much more careful about preserving
spaces.  But that's not what happened.  Python was created in a world
where the decision had already been made by many engineers (often
poor ones) that it was not a big deal to mess up spacing a bit.

I'd guess this decision goes back to early typesetting.  Spaces
are fungible; other content isn't.  The distinction that is tracked
is "was there space between these characters or not".  Given that
widespread presupposition, and that many file formats have been
adapted to that, I don't think it was a good choice to build
something which would be broken by that common failure mode.

It's not as though widespread spacing problems are a surprise.  They
are so commonplace that multiple utility programs provide, as standard
options, features to work around them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-04, Mark Wooding <mdw@distorted.org.uk> wrote:
> Seebs <usenet-nospam@seebs.net> writes:
>> Python's the only language I use where an obvious flaw, which is
>> repeatedly observed by everyone I know who uses the language, is
>> militantly and stridently defended by dismissing, insulting, and
>> attacking the character and motives of anyone who suggests that it
>> might be a bit of a nuisance.

> So you've not tried Lisp, then?  Dissing Lisp's parentheses tends to get
> a pretty similar reaction.

I don't use it.  I'm also not as sure that the parens are an obvious
flaw -- I am not aware of whole categories of software which regularly
destroy parens.

>   * I /do/ have a significant problem with cutting and pasting code in
>     Python.  In most languages, I can haul a chunk of code about, hit
>     C-M-q, and Emacs magically indents the result properly.  This is,
>     unfortunately, impossible with Python.  It has caused me real bugs,
>     and I have to be extra careful to fix the indentation up.

That was the thing which bit me the worst.  I had a fairly large block
of code in a first-pass ugly program.  I wanted to start refactoring
it, so I moved a big hunk of code into a method (with plans to further
refactor).  It took about fifteen minutes to redo the logic.

> I /like/ Python.  I use it frequently.  I /don't/ want to change its
> structure marked by indentation.  I'm /willing/ to put up with some
> inconvenience because Python makes up for it in other ways.  But there
> /is/ inconvenience, and it does need putting up with.  I think the
> benefits are worth the costs; others may disagree.

That makes sense to me.  I think it depends a lot on what I compare
Python to.  I get along quite well with Ruby, but I loathe PHP.  Comparing
Python to Ruby, I find the indentation quite annoying.  Comparing Python to
PHP, I find the indentation a very mild price to pay for my sanity.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Tim Harig <usernet@ilthio.net> writes:

> I use simple comments that are not effected by white space.  I don't
> waste my time trying to make comments look artistic.  They are there
> to convey information; not to look pretty.  I really detest having to
> edit other peoples comment formatting where you have to re-align
> everything if the length of any of comment lines change.

I view source code as primarily a means of communication with human
readers, and only secondarily as being machine readable.  I therefore
think it's worth the effort to make source code readily legible, for
example by making effective use of horizontal and vertical whitespace.
A long time ago, I spent a little while studying graphic design, so I
try to keep an eye on this sort of thing.

I'm interested in line length for two reasons: firstly, because I
believe that there's an optimum line length for easy and rapid reading,
which is probably a bit less than 80 columns; and secondly because I
find that I make more effective use of the available space on my screen
if I have several narrow columns rather than a few wide ones -- since
most lines in source files are short, a wide column ends up being mostly
empty on the right hand side, which is wasteful.

It's true that a source file is not the same as a typeset document: the
most obvious difference is that source files are modified over time,
sometimes by many hands, and that therefore some of the tradeoffs are
different.  I dislike `pretty' boxes around large comments, for example,
because maintaining the right hand edge is unnecessarily tedious.  But
sometimes careful alignment can help a reader spot a symmetry or find
his way through a repetitive section such a table more easily.

(Unfortunately, I appear to have strange ideas about what `legible'
means...)

-- [mdw]

On 2010-11-04, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> Right.  If you mangle spaces in Python or mangle braces in C then
>> recovery becomes impossible.  I don't think anyone is contesting that.
>> What we question is the idea that somehow Python is special in this
>> regard.  If you move files around in ways that change them then your
>> tools are broken.  The fact that the breakage is somewhat "friendlier"
>> to some types of files is interesting but irrelevant.
>
> Again, why does "diff -b" exist?
>
> It exists because so many things change whitespace unintentionally that
> it's a common failure mode.

It exists because so many people change whitespace intentionally in C
source code because no two C programmers seem able to agree on how to
format code.  Diff -b allows you to attempt to ignore semantically
null stylistic changes made by programmers.

-- 
Grant Edwards               grant.b.edwards        Yow! I'm having a RELIGIOUS
                                  at               EXPERIENCE ... and I don't
                              gmail.com            take any DRUGS

On 11/4/2010 4:17 AM, Seebs wrote:

I am sorry you feel compelled to use a language you so dislike. Not our 
fault though.

> Other languages I use are mostly amenable to the development of tools
> to automatically indent code.  Makefiles and Python are the only two
> exceptions...

If you add the normally redundant information in the form of explicit 
dedents (anything starting with '#' and distinguishable from normal 
comments), then it is not too hard to re-indent even after all indents 
have been removed. I believe this has been dome more than once. By using 
a stylized comment, the augmented code runs without preprocessing. I 
also believe at lease one person has written a preprocessor for 
'python-with-braces'.

-- 
Terry Jan Reedy

On 2010-11-04, Mark Wooding <mdw@distorted.org.uk> wrote:
> Tim Harig <usernet@ilthio.net> writes:
>
>> I use simple comments that are not effected by white space.  I don't
>> waste my time trying to make comments look artistic.  They are there
>> to convey information; not to look pretty.  I really detest having to
>> edit other peoples comment formatting where you have to re-align
>> everything if the length of any of comment lines change.
>
> I view source code as primarily a means of communication with human
> readers, and only secondarily as being machine readable.  I therefore
> think it's worth the effort to make source code readily legible, for
> example by making effective use of horizontal and vertical whitespace.
> A long time ago, I spent a little while studying graphic design, so I
> try to keep an eye on this sort of thing.

I agree that it should be clean, ledgible, and easy to parse; but, I can
that I can achieve this without making too many assumptions about
whitespace.  Think of it like the way HTML is *supposed* to work.  Ideally,
the web designer should stipulate the basic layout of the page; but,
details such as how wide the display is are better left to the browser to
figure out based on the actual conditions that it needs to display the
page.

> I'm interested in line length for two reasons: firstly, because I
> believe that there's an optimum line length for easy and rapid reading,
> which is probably a bit less than 80 columns; and secondly because I
> find that I make more effective use of the available space on my screen
> if I have several narrow columns rather than a few wide ones -- since
> most lines in source files are short, a wide column ends up being mostly
> empty on the right hand side, which is wasteful.

Don't get me wrong, I am not arguing against the eighty column stylistic
limit.  I totally agree with it within reason.

What I am arguing for is choice on how the code is displayed -- not how it
is actually written.  By using tabs, I can choose the trade-offs myself
when reading the code rather then being confined to how the writer made
their decision to view it.  Assuming that I have sufficient screen space,
I might choose a wider indent even though it might make the document wider
then 80 columns *when viewed*.  Other times, I may resign to view at the
shorter column width so that it fits in my window without side scrolling.
Either way, its my choice; and, when I am finished editing the file,
even if it exceeds 80 columns at my chosen column width, the file will
not exceed 80 columns, at the origional column width, in the actual
source as it is *written*.

Adjusting tab stops is merely for my viewing pleasure and it gives
everybody the choice to view it their way without effecting the code.  That
is why I prefer tabs.

On 2010-11-04, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-04, Seebs <usenet-nospam@seebs.net> wrote:
>> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>>> Right.  If you mangle spaces in Python or mangle braces in C then
>>> recovery becomes impossible.  I don't think anyone is contesting that.
>>> What we question is the idea that somehow Python is special in this
>>> regard.  If you move files around in ways that change them then your
>>> tools are broken.  The fact that the breakage is somewhat "friendlier"
>>> to some types of files is interesting but irrelevant.
>>
>> Again, why does "diff -b" exist?
>>
>> It exists because so many things change whitespace unintentionally that
>> it's a common failure mode.
>
> It exists because so many people change whitespace intentionally in C
> source code because no two C programmers seem able to agree on how to
> format code.  Diff -b allows you to attempt to ignore semantically
> null stylistic changes made by programmers.

I have seen huge patches caused by nothing more then some edit that
accidently added a trailing space to a large number of lines.  White space
mangling happens all the time without people even knowing about it.

On 2010-11-04, Grant Edwards <invalid@invalid.invalid> wrote:
> It exists because so many people change whitespace intentionally in C
> source code because no two C programmers seem able to agree on how to
> format code.  Diff -b allows you to attempt to ignore semantically
> null stylistic changes made by programmers.

I don't agree with this interpretation, just because the changes it
filters out are hardly ever intentional when I actually look at them.

They're a mix of space/tab changes which don't affect actual indentation,
trailing whitespace, and the like.

The kinds of changes that would be made by C programmers trying to change
source formatting are usually far beyond what "diff -b" would "fix".

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-04, Terry Reedy <tjreedy@udel.edu> wrote:
> I am sorry you feel compelled to use a language you so dislike. Not our 
> fault though.

I don't dislike it all that much.  What I dislike is being told that the
problems don't exist.

> If you add the normally redundant information in the form of explicit 
> dedents (anything starting with '#' and distinguishable from normal 
> comments), then it is not too hard to re-indent even after all indents 
> have been removed. I believe this has been dome more than once. By using 
> a stylized comment, the augmented code runs without preprocessing. I 
> also believe at lease one person has written a preprocessor for 
> 'python-with-braces'.

Yes.  They did this because there is no reason that anyone would ever
prefer it or find some benefit to it, of course.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Terry Reedy <tjreedy@udel.edu> writes:

> If you add the normally redundant information in the form of explicit
> dedents (anything starting with '#' and distinguishable from normal
> comments), then it is not too hard to re-indent even after all indents
> have been removed.

I actually use such a trick in emacs, not with comments but with "pass"
(emacs' python mode knows that pass end return end the current block).
It's extrememly useful in heavily nested code, or if I need to paste
some piece of code from one level to another. This lets my editor's
auto-indenter do the right thing. And I see immediately if/when I did
the nesting wrong.

I really like "indentation as structure" (code is more compact and
clearer), but I really hate that it relies on me putting the right
spaces at the right place. I would love to be able to put, e.g., a
period at the end of a line, to indicate that the next line is one level
upper. Something like:

for i in ... :
    for j in ... :
        whatever(i,j).
    .

No lost vertical space (except when I decide it), no ambiguity. It looks
to me like the exact opposite of ':'. End-of-line periods (or
exclamation marks) would let tools reindent correctly in all cases. I
don't think it conflicts with any other syntax.

-- Alain.

On Fri, 05 Nov 2010 11:21:57 +0100, Alain Ketterlin wrote:

> I really like "indentation as structure" (code is more compact and
> clearer), but I really hate that it relies on me putting the right
> spaces at the right place.

Er what? You really like indentation as structure, but you don't like 
putting in the indentation?


> I would love to be able to put, e.g., a
> period at the end of a line, to indicate that the next line is one level
> upper. Something like:
> 
> for i in ... :
>     for j in ... :
>         whatever(i,j).
>     .

How is that different from this?


for i in ... :
    for j in ... :
        whatever(i,j)


What's the point of the dots? Is that just to save you from having to hit 
shift-tab (or whatever your editor's decrease-indent command is)?


> No lost vertical space (except when I decide it), no ambiguity. 

What lost vertical space are you worried about?


> It looks
> to me like the exact opposite of ':'. End-of-line periods (or
> exclamation marks) would let tools reindent correctly in all cases. I
> don't think it conflicts with any other syntax.

for i in ... :
    for j in ... :
        n = 2.



-- 
Steven

On Thu, 04 Nov 2010 21:47:59 +0000, Tim Harig wrote:

> I have seen huge patches caused by nothing more then some edit that
> accidently added a trailing space to a large number of lines.  White
> space mangling happens all the time without people even knowing about
> it.

How does an edit accidentally add a trailing space to a large number of 
lines?

(1) The programmer shifted the cursor to the end of the line, pressed 
space, moved down a line, shift to eol, press space, repeat a large 
number of times. I don't call that an "accident".

(2) Some programmer used a tool that thought it was okay to add 
whitespace to the end of lines without being told to. I don't call that 
an accident either, I call that using a broken tool.

So we keep coming back to work-arounds for tools that mangle your data 
for no good reason...


-- 
Steven

On Thu, 04 Nov 2010 20:17:35 +0000, Seebs wrote:

>>   * I /do/ have a significant problem with cutting and pasting code in
>>     Python.  In most languages, I can haul a chunk of code about, hit
>>     C-M-q, and Emacs magically indents the result properly.  This is,
>>     unfortunately, impossible with Python.  It has caused me real bugs,
>>     and I have to be extra careful to fix the indentation up.
> 
> That was the thing which bit me the worst.  I had a fairly large block
> of code in a first-pass ugly program.  I wanted to start refactoring it,
> so I moved a big hunk of code into a method (with plans to further
> refactor).  It took about fifteen minutes to redo the logic.

Well there's your problem -- you are relying on tools that operate by 
magic.

Rather than re-create the logic, why not just hit Undo and then re-paste 
the code *without* the magic auto-reformat? Half a second, to undo and re-
paste, followed by 10 or 20 seconds to select the appropriate lines and 
*explicitly* re-indent the lines to the correct level.

For somebody who keeps tossing around the mantra that "explicit is better 
than implicit", you're amazingly reliant on a tool that performs massive, 
apparently irreversible formatting operations implicitly. And then rather 
than accept that your magic DWIM tool is unsuitable for the task you are 
putting it to, you then blame the data for not having error-correction 
codes that would allow *another* magic tool to fix the breakage caused by 
the first magic tool!


-- 
Steven

Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> writes:

>> I really like "indentation as structure" (code is more compact and
>> clearer), but I really hate that it relies on me putting the right
>> spaces at the right place.
>
> Er what? You really like indentation as structure, but you don't like 
> putting in the indentation?

Exactly. I want the extra safety belt of not relying on spaces only.

>> for i in ... :
>>     for j in ... :
>>         whatever(i,j).
>>     .
>
> How is that different from this?
>
> for i in ... :
>     for j in ... :
>         whatever(i,j)

At this point exactly, there's no way to know what the indentation of
the next line should be. My example above explicitely indicates the next
line should be at the same level as "for j ...".

Now suppose that, at this very place, you have to paste some other
if/for/while block whose original indentation is not exactly aligned
with the fragment above. No way to decide automatically how to align it
(under "for j"? under "whatever"?).

The dots I suggest are nothing more than tiny closing braces.

> What's the point of the dots? Is that just to save you from having to hit 
> shift-tab (or whatever your editor's decrease-indent command is)?

Redundancy. I often have deeply nested constructs, that I sometimes need
to move around. A real pain, compared to brace-based languages, where
constructs are explicitely terminated (i.e., not implicitely by the
start of the next construct). Have automatically indented source is a
useful and quick check.

>> No lost vertical space (except when I decide it), no ambiguity. 
>
> What lost vertical space are you worried about?

You've cut the part of my message where I say that python's (vertical)
compactness is one of its strong points.

>> It looks to me like the exact opposite of ':'. End-of-line periods
>> (or exclamation marks) would let tools reindent correctly in all
>> cases. I don't think it conflicts with any other syntax.

> for i in ... :
>     for j in ... :
>         n = 2.

You're right, I forgot this one (probably because I never use this kind
of elision). No big deal:

for i in ... :
    for j in ... :
        n = 2.
        m = 3. .
    for j in ... :
        f = 2 .
    ...

-- Alain.

On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Thu, 04 Nov 2010 21:47:59 +0000, Tim Harig wrote:
>
>> I have seen huge patches caused by nothing more then some edit that
>> accidently added a trailing space to a large number of lines.  White
>> space mangling happens all the time without people even knowing about
>> it.
>
> How does an edit accidentally add a trailing space to a large number of 
> lines?

Putting it back in context, it doesn't matter.  Seeb's point stands.
diff -b was designed because there are so many tools and channels that
mangle whitespace.  Changes in something such as brace style would make
non-whitespace changes that would not be eliminated by diff -b.

Probably the biggest reason for -b is for handling the differences in line
endings used on different platforms.

> (1) The programmer shifted the cursor to the end of the line, pressed 
> space, moved down a line, shift to eol, press space, repeat a large 
> number of times. I don't call that an "accident".

A search and replace operation could easily add extra whitespace and since
whitespace is not normally visible, the changes most likely go unnoticed.
The bottom line is that it happens and assigning blame really doesn't
change that fact.

> (2) Some programmer used a tool that thought it was okay to add 
> whitespace to the end of lines without being told to. I don't call that 
> an accident either, I call that using a broken tool.

Yep, there are probably thousands of tools that mangle whitespace.  In many
cases, such as differences in line endings, what they are doing is not even
wrong.  You can blame the tools all you like; but, they are not going away.

You keep trying to tell us that using whitespace is superior; but,
other languages manage to work with these thousands of imperfect
tools without issue.  The use of whitespace was a stylistic change and
stylistic holy wars exist because it is almost impossible to prove that
any reasonable style has benefit over another.  That whitespace causes
issues is verifiable.  I find it hard to concluded that that whitespace
based syntax is superior when it tells us that we cannot use thousands
of otherwise useful tools that other langauges manage to work with.
I find it hard to select a matter of taste with no verifiable benefit
over a verifiable disadvantage that happens to strike many people.

On 2010-11-05, Tim Harig <usernet@ilthio.net> wrote:
> On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
>> On Thu, 04 Nov 2010 21:47:59 +0000, Tim Harig wrote:
>>
>>> I have seen huge patches caused by nothing more then some edit that
>>> accidently added a trailing space to a large number of lines.  White
>>> space mangling happens all the time without people even knowing about
>>> it.

And how does that affect a Python program?  The same as it does a C
program.

>> How does an edit accidentally add a trailing space to a large number of 
>> lines?
>
> Putting it back in context, it doesn't matter.  Seeb's point stands.
> diff -b was designed because there are so many tools and channels that
> mangle whitespace.  Changes in something such as brace style would make
> non-whitespace changes that would not be eliminated by diff -b.
>
> Probably the biggest reason for -b is for handling the differences in line
> endings used on different platforms.

Different line-endings are tolerated by Python just as well as they
are by C.

-- 
Grant Edwards               grant.b.edwards        Yow! They collapsed
                                  at               ... like nuns in the
                              gmail.com            street ... they had no
                                                   teen appeal!

On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> On Thu, 4 Nov 2010 19:37:25 +0000 (UTC)
> Tim Harig <usernet@ilthio.net> wrote:
>> On 2010-11-04, D'Arcy J.M. Cain <darcy@druid.net> wrote:
>> You are the one who seems to be on a crusade against against braces.  It
>
> You totally misunderstand me.  I am not on a crusade of any sort.  I am

I appologize that I confused your name with Steven D'Aprano; but, your
positions are pretty much the same.

> care about.  If no one was on a crusade to convince people that
> indentation as syntax (can we call is IAS from now on?) was evil then I
> wouldn't be posting anything at all on the subject.  I am being totally
> reactionary here.

Neither of you are really adding anything to the conversation other then to
assert that you like whitespace syntax and that the problems do not effect
you.  Good for you; but, that doesn't help the people who are finding that
it presents problems.

>> would seem to me, that if you want people to accept that white space
>> formatting is superior, that you would be looking for a simple way to solve
>> the white space mangling problem.
>
> I might if it was a problem for me.

Good for you but telling us that doesn't really help those that do.  Your
stance is based an a stylistic preference.  Holy wars around style continue
to exist because, in most cases, it is almost impossible to prove the
advantages of one reasonable style over another.

It is, however, verifiable that white space syntax causes issues with a
large number of common tools.  I am a man of science.  When choosing
between the intangible and verifiable, I choose the verifable truth.

>> The world is full of broken tools that many of us have to use; but, why
>> should we accept that your choice is superior when other choices manage to
>> work with these tools without issues.
>
> You don't have to accept anything.  Choose your own tools.  I happen to
> choose Python and the tools that I choose to use work fine for me.

It is simply hard for me to accept that your solution is better when
it is telling us that we have to abandon thousands of tools that other
solutions manage to work with without difficulty.

On 2010-11-05, Alain Ketterlin <alain@dpt-info.u-strasbg.fr> wrote:
> Terry Reedy <tjreedy@udel.edu> writes:
>
>> If you add the normally redundant information in the form of explicit
>> dedents (anything starting with '#' and distinguishable from normal
>> comments), then it is not too hard to re-indent even after all indents
>> have been removed.
>
> I actually use such a trick in emacs, not with comments but with "pass"
> (emacs' python mode knows that pass end return end the current block).
> It's extrememly useful in heavily nested code, or if I need to paste
> some piece of code from one level to another. This lets my editor's
> auto-indenter do the right thing. And I see immediately if/when I did
> the nesting wrong.

Thank-you for your tip.  It is nice to know that some people are thinking
of ways to work around the trade-offs rather then just asserting that we
shouldn't use tools that happen to collide with Python.

On 2010-11-05, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-05, Tim Harig <usernet@ilthio.net> wrote:
>> On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
>>> On Thu, 04 Nov 2010 21:47:59 +0000, Tim Harig wrote:
>>>
>>>> I have seen huge patches caused by nothing more then some edit that
>>>> accidently added a trailing space to a large number of lines.  White
>>>> space mangling happens all the time without people even knowing about
>>>> it.
>
> And how does that affect a Python program?  The same as it does a C
> program.

I wasn't making any statement of C versus Python in this thread.  Those
have been covered elsewhere.  I was responding to your assertion:

	It exists because so many people change whitespace intentionally
	in C source code because no two C programmers seem able to agree
	on how to format code.	Diff -b allows you to attempt to ignore
	semantically null stylistic changes made by programmers.

That is clearly wrong.  If a C programmer changes the format of the code,
it is almost universally true that they will make changes that affect more
then just the whitespace on a single line.  Diff will register these
changes even with the -b option.  I provided a couple of common scenerios
that are more likely to have justified the -b option.

On 11/5/2010 3:41 AM, Steven D'Aprano wrote:
> On Thu, 04 Nov 2010 20:17:35 +0000, Seebs wrote:
>
>>>    * I /do/ have a significant problem with cutting and pasting code in
>>>      Python.  In most languages, I can haul a chunk of code about, hit
>>>      C-M-q, and Emacs magically indents the result properly.  This is,
>>>      unfortunately, impossible with Python.  It has caused me real bugs,
>>>      and I have to be extra careful to fix the indentation up.
>>
>> That was the thing which bit me the worst.  I had a fairly large block
>> of code in a first-pass ugly program.  I wanted to start refactoring it,
>> so I moved a big hunk of code into a method (with plans to further
>> refactor).  It took about fifteen minutes to redo the logic.
>
> Well there's your problem -- you are relying on tools that operate by
> magic.

    Not magic, just code understanding.

    INTERLISP's editor allowed the user to select a block of
LISP code and make it into a function.  The selected block
would be analyzed to determine which local variables it referenced,
and a new function would be created with those parameters.  The
block of code at the original point would then be replaced by
a call to the function.

    Today's editors are too dumb to do that right.  They're text
editors with the illusion of knowing something about the language,
not language editors which also format text.

				John Nagle

On 11/5/2010 11:13 AM Tim Harig said...
> It is simply hard for me to accept that your solution is better when
> it is telling us that we have to abandon thousands of tools that other
> solutions manage to work with without difficulty.

I only work with a few tools none of which alter or strip leading 
whitespace, and I don't try to transport python code in ways that allow 
harmful transformations to take place, eg, reinterpreted by html or 
email rendering engines, which aren't effective programming tools anyway.

So, which of your tools are you married to that are causing your issues?

If-you-got-a-bigger-hammer-you-could-drive-that-phillips-screw-into-anything-ly 
y'rs,

Emile

On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> How does an edit accidentally add a trailing space to a large number of 
> lines?

I would love to know the answer to this question.

However, empirically, it happens.

My guess would be cutting and pasting in some way.

> So we keep coming back to work-arounds for tools that mangle your data 
> for no good reason...

To some extent, this is true.

How about this.  How about we make the Python TCP Stack.  The Python TCP
Stack works on the same principles that you advocate for the Python
language.  For instance, if any packet it receives is malformed or
contrary to the applicable specs, it has a 95% chance of dropping the packet,
and a 5% chance of interpreting the packet as being of a different type
entirely.

This will NEVER be a problem, and is a good design, because handling
packets which contain any kind of spec violation is just work-arounds
for broken tools, right?

And the first thing we should do is *always* to ensure that, if anything
anywhere does not live up to our proposed specification, it causes us to
fail in spectacular ways.

Of course, to fully capture the feel of Python's choice here, we have
to include some common packet variant, which violates no RFCs, as
one of the "broken" ones on the grounds that it doesn't make sense to
us and isn't easy for a newcomer to read.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Thu, 04 Nov 2010 20:17:35 +0000, Seebs wrote:
>> That was the thing which bit me the worst.  I had a fairly large block
>> of code in a first-pass ugly program.  I wanted to start refactoring it,
>> so I moved a big hunk of code into a method (with plans to further
>> refactor).  It took about fifteen minutes to redo the logic.

> Well there's your problem -- you are relying on tools that operate by 
> magic.

Wrong.

> Rather than re-create the logic, why not just hit Undo and then re-paste 
> the code *without* the magic auto-reformat? Half a second, to undo and re-
> paste, followed by 10 or 20 seconds to select the appropriate lines and 
> *explicitly* re-indent the lines to the correct level.

There was no magic auto-reformat.  Where did you invent that from?  Why are
you making stuff up which I never said or referred to?

> For somebody who keeps tossing around the mantra that "explicit is better 
> than implicit", you're amazingly reliant on a tool that performs massive, 
> apparently irreversible formatting operations implicitly.

No, I am not.  No such tool was involved.  I never mentioned one, referred
to one, or hinted at one -- and have never used one, because I hate them.
In fact, it is ludicrous to imagine that I was using one, given that I've
stated in this very thread that so far as I know such a tool cannot
be created for Python.

Your decision to invent something I never referred to is not a problem with
my approach to the language.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-05, Emile van Sebille <emile@fenx.com> wrote:
> So, which of your tools are you married to that are causing your issues?

Python.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-05, Seebs <usenet-nospam@seebs.net> wrote:
> On 2010-11-05, Emile van Sebille <emile@fenx.com> wrote:
>> So, which of your tools are you married to that are causing your issues?
>
> Python.

I think you should quit using Python and choose a language that works
with whatever tools are causing all your white-space corruption
problems.

-- 
Grant Edwards               grant.b.edwards        Yow! My pants just went to
                                  at               high school in the Carlsbad
                              gmail.com            Caverns!!!

On Fri, 5 Nov 2010 18:13:44 +0000 (UTC)
Tim Harig <usernet@ilthio.net> wrote:
> > care about.  If no one was on a crusade to convince people that
> > indentation as syntax (can we call is IAS from now on?) was evil then I
> > wouldn't be posting anything at all on the subject.  I am being totally
> > reactionary here.
> 
> Neither of you are really adding anything to the conversation other then to

Well, whether I am adding anything is a judgement call.  That I don't
accept your premise doesn't mean that my postings are content free.

> It is, however, verifiable that white space syntax causes issues with a
> large number of common tools.  I am a man of science.  When choosing

The simple fact is that the combination of your tools and Python is
broken.  The combination of my tools and Python is not.  That's lucky
for me since I really, really like IAS.  That's unlucky for people who
have to work with tools that mangle code.  But don't crusade to change
my language.  Use Perl or C or even pybraces.

> It is simply hard for me to accept that your solution is better when
> it is telling us that we have to abandon thousands of tools that other
> solutions manage to work with without difficulty.

I am offering no solutions.  Why would I since I don't see a problem?

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

Tim Harig wrote:
> The use of whitespace was a stylistic change and
> stylistic holy wars exist because it is almost impossible to prove that
> any reasonable style has benefit over another.  That whitespace causes
> issues is verifiable.  I find it hard to concluded that that whitespace
> based syntax is superior when it tells us that we cannot use thousands
> of otherwise useful tools that other langauges manage to work with.
> I find it hard to select a matter of taste with no verifiable benefit
> over a verifiable disadvantage that happens to strike many people.

The verifiable benefit for me is ease of use, ease of thought, ease of 
typing... I realize these are not benefits for everyone, but they are 
for some -- and I would venture a guess that the ease of thought benefit 
is one of the primary reasons Python is popular.  I am definitely one of 
those that think indentation based structure is one of Python's best 
features.

I do acknowledge that if you don't think that way, it can be major 
hassle, and I sympathize.

~Ethan~

On Nov 5, 12:35=A0pm, John Nagle <na...@animats.com> wrote:
> =A0 =A0 INTERLISP's editor allowed the user to select a block of
> LISP code and make it into a function. =A0The selected block
> would be analyzed to determine which local variables it referenced,
> and a new function would be created with those parameters. =A0The
> block of code at the original point would then be replaced by
> a call to the function.
>
> =A0 =A0 Today's editors are too dumb to do that right. =A0They're text
> editors with the illusion of knowing something about the language,
> not language editors which also format text.

Eclipse does that.  Visual Studio does that.  As for Python, I hear
that Eric IDE has a plugin to do that, although I haven't tested it
myself.

Cheers,
Ian

On 2010-11-05, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-05, Seebs <usenet-nospam@seebs.net> wrote:
>> On 2010-11-05, Emile van Sebille <emile@fenx.com> wrote:
>>> So, which of your tools are you married to that are causing your issues?

>> Python.

> I think you should quit using Python and choose a language that works
> with whatever tools are causing all your white-space corruption
> problems.

Ahh, but that's the thing.  I'm married to it -- there's existing projects
I want to work on which are in Python.

Anyway, it was a sort of frivolous answer, but it's ha-ha-only-serious;
after all, there were no serious issues with any of these tools before.

There's a saying a friend of mine has; "a lack of communication is never
exclusively one party's fault."  This applies, in many cases, to things
like "issues" that occur when two programs clash in some aspect of their
designs.  In some cases, there might be a real and unambiguous standard
to be violated.  In others, though, you can have a problem which arises
from a clash in expectations between two programs, either of which is fine
on its own.

There is a clash between Python and the whole category of things which
sometimes lose whitespace.  Because that category is reasonably large,
and known to be large, and unlikely to vanish, many language designers
choose to build their languages to be robust in the face of minor changes
in whitespace.  Python chose not to, and that is a source of conflicts.

Were someone to invent a *new* text editor, which mangled whitespace, I
would accuse it of being gratuitously incompatible with Python; I tend
to regard compatibility, once you get past the standards, as a matter
of temporal precedence.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-05, Ethan Furman <ethan@stoneleaf.us> wrote:
> The verifiable benefit for me is ease of use, ease of thought, ease of 
> typing... I realize these are not benefits for everyone, but they are 
> for some -- and I would venture a guess that the ease of thought benefit 
> is one of the primary reasons Python is popular.  I am definitely one of 
> those that think indentation based structure is one of Python's best 
> features.

Could you explain more the "ease of thought" thing?  I haven't yet noticed
it, but it might be something to look out for as I get more experienced.

It certainly sounds like something that would be a benefit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-05, D'Arcy J.M. Cain <darcy@druid.net> wrote:
> The simple fact is that the combination of your tools and Python is
> broken.  The combination of my tools and Python is not.  That's lucky
> for me since I really, really like IAS.  That's unlucky for people who
> have to work with tools that mangle code.  But don't crusade to change
> my language.  Use Perl or C or even pybraces.

No one is crusading to change Python, or even suggesting that it should
be changed.

> I am offering no solutions.  Why would I since I don't see a problem?

One of the things many people try to do is develop the ability to "see"
problems that affect other people but possibly not themselves.  This allows
people to offer solutions to those problems, which is often viewed as
a kind of contribution to a community.  Certainly, it's more useful than
posting nothing more than "that's not a problem for me."

I can just see how well this attitude must work in other circumstances:
	Some Guy:  Oh, *!@#.  I think I just sprained my ankle.

	Darcy:  I didn't.

	Some Guy:  I don't think I can walk up these stairs.

	Darcy:  I don't have a problem with stairs.  Stop trying to
	change this path.  It works fine.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 11/5/2010 3:33 PM, D'Arcy J.M. Cain wrote:

> my language.  Use Perl or C or even pybraces.

http://timhatch.com/projects/pybraces/
"I work with a guy who hates Python's significant whitespace and wishes 
that he could just use curly braces."

> I am offering no solutions.

Except you just did ;-).
And using a braces encoding makes
it looks easier than I expected.

-- 
Terry Jan Reedy

On 05 Nov 2010 20:14:47 GMT
Seebs <usenet-nospam@seebs.net> wrote:
> I can just see how well this attitude must work in other circumstances:

I guess this message ends the topic for me.  Bye.

-- 
D'Arcy J.M. Cain <darcy@druid.net>         |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 425 1212     (DoD#0082)    (eNTP)   |  what's for dinner.

On Thu, 04 Nov 2010 19:37:25 +0000, Tim Harig wrote:

> Examples of communication channels that mangle white space abound.

Yes. So what? If your communication channel mangles your data, change 
your communication channel, don't expect users of clean communication 
channels to hand-enter error-correcting codes (braces) into the data.


> I
> don't know of any that mangle either braces or pascal style start/end
> blocks.
> 
> You are the one who seems to be on a crusade against against braces.  It
> would seem to me, that if you want people to accept that white space
> formatting is superior, that you would be looking for a simple way to
> solve the white space mangling problem.

Why is it the responsibility of the programming language syntax to 
correct the problem with Seebs' faulty mail server?

I've experienced the spilled-coke-on-the-keyboard problem more often than 
mangled whitespace, but you don't see me arguing that what every language 
needs is error-correcting codes that let me work with keyboards that have 
had Coke spilled on them.


[...]
> Transfering binary programs has always been an issue and using text
> based communications (preferably human readable) has always been
> considered a good design decision.  I put up with Python's white space
> idiosyncrasies; I wouldn't even bother looking at a language that
> requires me to enter the source in binary.  I also consider the move
> toward XML based document formats a move in the right direction.

Okay, now you have zero credibility.

XML is not a data format for human use, it is for use by machines. It is 
slow, inefficient, and uneditable by humans except for the most trivial 
cases.



-- 
Steven

On Thu, 04 Nov 2010 17:45:58 +0000, Tim Harig wrote:

>>> Python is the only language that I know that *needs* to specify tabs
>>> versus spaces since it is the only language I know of which uses
>>> whitespace formating as part of its syntax and structure.
[...]
> I am also aware of other langauges such as Boo; but, I don't really
> consider them individually relevant to the conversation as they are
> explicitly using a Python based syntax.  For this discussion I merely
> group them with Python.

You might as well say that C is the only language that uses tags around 
blocks, since for this discussion "I merely group" Pascal, Algol, Java, 
etc with C.



-- 
Steven

On Fri, 05 Nov 2010 18:45:39 +0000, Seebs wrote:

> On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au>
> wrote:
>> On Thu, 04 Nov 2010 20:17:35 +0000, Seebs wrote:
>>> That was the thing which bit me the worst.  I had a fairly large block
>>> of code in a first-pass ugly program.  I wanted to start refactoring
>>> it, so I moved a big hunk of code into a method (with plans to further
>>> refactor).  It took about fifteen minutes to redo the logic.
> 
>> Well there's your problem -- you are relying on tools that operate by
>> magic.
> 
> Wrong.

Really? Then how did the logic get screwed up from a mere copy-and-paste 
operation?

In context (which you deleted), you were agreeing with Mark Wooding who 
wrote:

"I /do/ have a significant problem with cutting and pasting code in 
Python.  In most languages, I can haul a chunk of code about, hit C-M-q, 
and Emacs magically indents the result properly.  This is, unfortunately, 
impossible with Python.  It has caused me real bugs, and I have to be 
extra careful to fix the indentation up."

[Aside: he isn't having problems with cutting and pasting code in Python, 
but in Emacs.]

You *agreed with him*, and related your story. In context, I think it was 
perfectly reasonable to conclude that you too used C-M-q in Emacs, which 
then "magically indents the result". Mark's words, not mine.

But perhaps you were using Notepad, and you just hit Ctrl-V, and 
something else mangled the code so badly you needed to spend 15 minutes 
re-creating the program logic. I am open to correction either way.


>> Rather than re-create the logic, why not just hit Undo and then
>> re-paste the code *without* the magic auto-reformat? Half a second, to
>> undo and re- paste, followed by 10 or 20 seconds to select the
>> appropriate lines and *explicitly* re-indent the lines to the correct
>> level.
> 
> There was no magic auto-reformat.  Where did you invent that from?  Why
> are you making stuff up which I never said or referred to?

Then how did the logic get mangled from a simple copy and paste operation?

What god-awful editor are you using that can't copy and paste text 
without mangling it?



-- 
Steven

On 2010-11-06, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Thu, 04 Nov 2010 19:37:25 +0000, Tim Harig wrote:
>> Examples of communication channels that mangle white space abound.

> Yes. So what?

So something which is broken by them is brittle.

And in every circumstance *other* than the syntax of Python, specifically,
we regard brittleness to common events as a flaw in a design.  For instance,
Makefiles require tabs to indent rules, and behave strangely if for some
reason you use spaces.  Many editors, though, can be configured to insert
spaces when you hit the tab key.  This setup is not intrinsically "broken",
it's just a matter of preference.  And yet, when used with make, it produces
cryptic failures.

Everyone, without exception, agrees that this is a flaw in the design of
make, and that the "tabs" rule should never have existed.

> If your communication channel mangles your data, change 
> your communication channel, don't expect users of clean communication 
> channels to hand-enter error-correcting codes (braces) into the data.

If you have to hand-enter them, perhaps you should get better tools,
as many tools don't require you to hand-enter them.

Ahh, but I forgot.  You only need to get "better" tools if you're talking
about why you *don't* find Python's design to be the one true pinnacle of
idealized and perfect engineering.  If you're talking about any other
language which works fine and is no hassle if you have suitable tools, it
is of course ridiculous to suggest that people should need to change
away from tools which currently suit them fine.

> Why is it the responsibility of the programming language syntax to 
> correct the problem with Seebs' faulty mail server?

It's not.  And honestly, if it were just one misconfigured mail server,
no one would probably ever start this conversation.  But instead it's
dozens of mail servers, dozens of web forums, dozens of editors, OCR
scanning of printouts, and dozens of other media in which it is easy
for small whitespace changes to creep in or appear.  All of which were
known to exist when the decision was made to design a new file format
to be brittle in the face of such changes.

> XML is not a data format for human use, it is for use by machines. It is 
> slow, inefficient, and uneditable by humans except for the most trivial 
> cases.

There are thousands of web pages which have been entered in something
which could easily be imagined to be a variant of XML.  For that matter,
OS X ".plist" files are often stored in XML, which is widely liked because
it gives you a nice, robust, human-readable format.  Which is amenable
to hand-editing if you want to tweak something.

XML isn't a *great* format for human use, and it's certainly been aimed
much more at use by machines.  However, there's a lot to be said for
designing machines to use formats which happen also to be easy for humans
to read, at the very least, and possibly even easy to write.

("Easy" being, of course a relative term.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-06, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au> wrote:
> On Fri, 05 Nov 2010 18:45:39 +0000, Seebs wrote:
>> On 2010-11-05, Steven D'Aprano <steve@REMOVE-THIS-cybersource.com.au>
>> wrote:
>>> Well there's your problem -- you are relying on tools that operate by
>>> magic.

>> Wrong.

> Really? Then how did the logic get screwed up from a mere copy-and-paste 
> operation?

I inserted four spaces in front of a bunch of lines.  :)

> [Aside: he isn't having problems with cutting and pasting code in Python, 
> but in Emacs.]

True.

> You *agreed with him*, and related your story. In context, I think it was 
> perfectly reasonable to conclude that you too used C-M-q in Emacs, which 
> then "magically indents the result". Mark's words, not mine.

Ahh, okay.  I can see how you would have inferred that, but no, that's
not what I did.

> What god-awful editor are you using that can't copy and paste text 
> without mangling it?

It's a side-effect of vi being, by default, configured to prefer to convert
things to tabs.  The particular vi I'm using doesn't, so far as I know
"recognize" file formats, and that default behavior is not merely tolerable
but *preferable* for all of the dozens of other kinds of files I edit.

I've since learned to work around it, but the fact remains that, given a
fairly common behavior, which is *preferable* for every other context, I
ended up with a file where an operation which would have worked for
re-indenting any other language I use didn't for re-indenting Python.
I've long since figured out ways to prevent that, but that wasn't the
point; the point was how much harder it was to fix indentation once it
had gotten mangled than it would be in, oh, any other programming language
or file format I've used.  (Even Makefiles are easier to fix, if only because
they're so much simpler.)

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 11/5/2010 4:09 PM, Seebs wrote:
> On 2010-11-05, Grant Edwards <invalid@invalid.invalid> wrote:
>> On 2010-11-05, Seebs <usenet-nospam@seebs.net> wrote:
>>> On 2010-11-05, Emile van Sebille <emile@fenx.com> wrote:
>>>> So, which of your tools are you married to that are causing your issues?
> 
>>> Python.
> 
>> I think you should quit using Python and choose a language that works
>> with whatever tools are causing all your white-space corruption
>> problems.
> 
> Ahh, but that's the thing.  I'm married to it -- there's existing projects
> I want to work on which are in Python.
> 
> Anyway, it was a sort of frivolous answer, but it's ha-ha-only-serious;
> after all, there were no serious issues with any of these tools before.
> 
> There's a saying a friend of mine has; "a lack of communication is never
> exclusively one party's fault."  This applies, in many cases, to things
> like "issues" that occur when two programs clash in some aspect of their
> designs.  In some cases, there might be a real and unambiguous standard
> to be violated.  In others, though, you can have a problem which arises
> from a clash in expectations between two programs, either of which is fine
> on its own.
> 
> There is a clash between Python and the whole category of things which
> sometimes lose whitespace.  Because that category is reasonably large,
> and known to be large, and unlikely to vanish, many language designers
> choose to build their languages to be robust in the face of minor changes
> in whitespace.  Python chose not to, and that is a source of conflicts.
> 
The whitespace-eating nanovirus was conquered in 2005, and is not
expected to reappear.

> Were someone to invent a *new* text editor, which mangled whitespace, I
> would accuse it of being gratuitously incompatible with Python; I tend
> to regard compatibility, once you get past the standards, as a matter
> of temporal precedence.
> 
> -s

If someone were to use a text editor which had always historically
mangled whitespace I would find myself wondering why they found it
necessary to restrict themselves to such stone-age tools.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

On 2010-11-06, Steve Holden <steve@holdenweb.com> wrote:
> If someone were to use a text editor which had always historically
> mangled whitespace I would find myself wondering why they found it
> necessary to restrict themselves to such stone-age tools.

I have yet to find an editor that allows me to, well, *edit*, more
comfortably than vi.

As to what it does with whitespace... What it does is exactly what
is most desireable in every other kind of file I edit.  I wouldn't
normally refer to it as "mangling" in the pejorative sense; it mostly
leaves spaces alone, but when preserving indentation from one line
to the next, uses tabs.  That, it turns out, is useful and desireable
in nearly all programming languages, and in particular, in all
the other programming languages I use.

I don't think it's fair to accuse tools of being "stone age" on the
grounds that they do something which most users want most of the
time by default.  The "no tabs, only spaces" thing is an interesting
idiosyncrasy of a particular community, which places a high value
on telling people to change everything about their computing
environment so they can appreciate how robust Python is when you
make a point of blaming any and all quirks or nuisances on tools.

We might as well insist that everyone use editors which automatically
add the braces to C code (such exist) when they complain about
the "effort" of typing matching braces.  Surely, if you have to
type braces by hand, the problem isn't with C, but with your
stone age editor?  Oh, wait.  That kind of smug dismissiveness
is considered rude unless it's done in *favor* of Python.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 11/06/10 03:27, Seebs wrote:
> On 2010-11-06, Steve Holden<steve@holdenweb.com>  wrote:
>> If someone were to use a text editor which had always historically
>> mangled whitespace I would find myself wondering why they found it
>> necessary to restrict themselves to such stone-age tools.
>
> I have yet to find an editor that allows me to, well, *edit*, more
> comfortably than vi.
>
> As to what it does with whitespace... What it does is exactly what
> is most desireable in every other kind of file I edit.  I wouldn't
> normally refer to it as "mangling" in the pejorative sense; it mostly
> leaves spaces alone, but when preserving indentation from one line
> to the next, uses tabs.  That, it turns out, is useful and desireable
> in nearly all programming languages, and in particular, in all
> the other programming languages I use.

I think in a previous thread, you mentioned that you use nvi. 
While I can't speak to the knobs-and-dials that nvi offers, in 
vim, you can twiddle the 'expandtab' option (along with the 
associated 'tabwidth' and 'shiftwidth' settings) to get whatever 
behavior is deemed "correct" for the project you're working on. 
So if I'm working on a project with PEP-8 4-spaces-per-indent, I'll

   :set sw=4 ts=4 et

and then if the file erroneously has tabs in it, I'll just issue

   :retab

to fix it[1].

-tkc


[1]
Yes, if you have string literals with tabs that you want to keep 
in them, the solution is a little more complex, but doable; 
though in such cases I'd recommend using "\t" instead of a 
literal tab.

In message <iapom0$k4d$1@speranza.aioe.org>, Tim Harig wrote:

> I agree with Seebs, Python is the only language I know that promotes
> the use of spaces over tabs; and there are equally picky syntaxs (ie,
> Makefiles) that mandate the use of tabs.

That’s widely conceded to be a misfeature of Make.

> I personally prefer tabs as it lets *me* decide how far the apparent
> indentations are in the code.

But they don’t. Other people can have different settings, and they will see 
different indentations for your code, so you don’t have control at all. The 
only way to ensure they see what you see is to use spaces, not tabs.

In message <iat59a$rem$1@reader1.panix.com>, Grant Edwards wrote:

> But without the colon, how are people who write programming editors
> going to know when to increase the indentation level as I enter code?

I hate editors (or editing modes) that think they know when to change 
indentation level on me. Hate, hate, hate.

In message <8jftftFelnU1@mid.individual.net>, Neil Cerutti wrote:

> The handsome ':' terminator of if/elif/if statements allows us to
> omit a newline, conserving vertical space. This improves the
> readability of certain constructs.
> 
> if x: print(x)
> elif y: print(y)
> else: print()

I would never do that. “Conserving vertical space” seems a stupid reason for 
doing it. In C, I even go the opposite way:

    if (x)
      {
        printf(..., x);
      }
    else if (y)
      {
        printf(..., y);
      }
    else
      {
        printf(...);
      } /*if*/

In message <87sjzige0r.fsf@benfinney.id.au>, Ben Finney wrote:

> Seebs <usenet-nospam@seebs.net> writes:
> 
>> On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au>
>> wrote:
>>
>>> Python does explicitly mark blocks. It does it by changes in
>>> indentation. An indent is an explicit start-block. An outdent is an
>>> explicit end- block. There is nothing implicit in a change in indent
>>> level.
>>
>> What's the token that marks the end of a block, corresponding to the
>> colon used to introduce it?
> 
> You have introduced this requirement for tokens; it's fallacious. The
> direct answer is: tokens aren't part of the requirement to be explicit.
> 
> The more general answer is: the block is explicitly ended where the
> indentation ends.

That’s implicit, not explicit.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:

> I would never do that. “Conserving vertical space” seems a stupid reason for 
> doing it.

Vertical space is a limiting factor on how much code one can see at a
time.  I use old-fashioned CRT monitors with 4x3 aspect ratios and
dizzyingly high resolution; I usually work with two columns of code, but
can get four if I give up on things like xterms.  I still find it rather
limiting: I have to remember everything which won't fit on the screen.

I've no idea how people manage with these ridiculous widescreen monitors.

-- [mdw]

On 2010-11-07, Mark Wooding <mdw@distorted.org.uk> wrote:
> Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:
>
>> I would never do that. "Conserving vertical space" seems a stupid
>> reason for doing it.
>
> Vertical space is a limiting factor on how much code one can see at a
> time.

And one study I read shoed that how much code one can see at a time
directly affects the number of bugs introduced while editing. The
more code you could see at a time, the better off you were (at least
as far as the measurements in that study went).  IOW, editing a loop
or other control structure where you couldn't see both ends was
problematic. Conserving vertical space avoids that problem.

> I use old-fashioned CRT monitors with 4x3 aspect ratios and
> dizzyingly high resolution; I usually work with two columns of code, but
> can get four if I give up on things like xterms.  I still find it rather
> limiting: I have to remember everything which won't fit on the screen.
>
> I've no idea how people manage with these ridiculous widescreen monitors.

Rotate them 90 degrees?  My monitors will do that mechanically, but
I've never bothered to try setting up X to handle it. (I bought 4:3
monitors before they got replaced by cheap 16:8 screens).

-- 
Grant

On 2010-11-07, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <87sjzige0r.fsf@benfinney.id.au>, Ben Finney wrote:
>
>> Seebs <usenet-nospam@seebs.net> writes:
>> 
>>> On 2010-11-03, Steven D'Aprano <steve-REMOVE-THIS@cybersource.com.au>
>>> wrote:
>>>
>>>> Python does explicitly mark blocks. It does it by changes in
>>>> indentation. An indent is an explicit start-block. An outdent is an
>>>> explicit end- block. There is nothing implicit in a change in indent
>>>> level.
>>>
>>> What's the token that marks the end of a block, corresponding to the
>>> colon used to introduce it?
>> 
>> You have introduced this requirement for tokens; it's fallacious. The
>> direct answer is: tokens aren't part of the requirement to be explicit.
>> 
>> The more general answer is: the block is explicitly ended where the
>> indentation ends.
>
> That's implicit, not explicit.

If you can _see_ it, how is it implicit?

-- 
Grant

On 11/7/2010 8:23 AM, Grant Edwards wrote:
[...]
> (I bought 4:3 monitors before they got replaced by cheap 16:8
> screens)

I think you'll find the new aspect ration is 16:9.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

In article <87oca1b8ba.fsf.mdw@metalzone.distorted.org.uk>,
 mdw@distorted.org.uk (Mark Wooding) wrote:

> Vertical space is a limiting factor on how much code one can see at a
> time.

Yup.  Over three decades of programming, my personal upper bound for how 
long a function should be has always been "fits on one screen".  In the 
old days, that meant a CRT with 24 lines (by 80 columns).  These days, 
it means about 100-120 lines (depending on how squinty-eyed I'm willing 
to go).  Thus, over the years, my idea of how long a function can be has 
grown several-fold.

I still try to keep things well under 100 lines per function.  I'm 
willing, however, to tolerate anything up to where I can no longer see 
the entire thing and the font is still big enough to read easily.

Of course, in the real old days, with 66 lines to an 11-inch page of 
line printer paper, and 8 foot high ceilings, you could tape about 500 
lines of code to the wall, but I digress :-)
 
> I've no idea how people manage with these ridiculous widescreen monitors.

My 15-inch laptop has 1680 x 1050 resolution (the new high-res flavor of 
the MacBook Pro).  I love it.  Mostly I use the screen real estate for 
one main shell window where I'm doing most of my work, and a variety of 
other windows (browser, pdf viewer, etc) which contain documents I'm 
referring to in support of what I'm doing in my main window.

At work, I've got two 1920 x 1080 monitors side-by-side.  I find I don't 
use the second monitor much.  I'll generally shove some windows over 
there which I watch, but almost never interact with.  Mostly things 
tailing log files or some other kind of status monitor function.

I also find that to keep the angle of view comfortable, I can't sit as 
close to the monitors as I usually keep my laptop screen.  So, I have to 
make the font size a little larger, which in turn means fewer lines of 
code visible.  Ergonomics is complicated.

I'm thinking of rotating the monitors 90 degrees, running them in 
side-by-side portrait mode.  I know X11 can handle the video rotation, 
but I'm not sure I've got the right mounting brackets.

Another factor is that the Mac display is sharp as a tack compared to my 
big LCD panels at work.  I think it's party the display hardware itself, 
and partly that the Mac's text rendering just blows Linux out of the 
water.  I can easily read text on my laptop at much smaller font sizes 
than I can on my desk monitors at work.

On 11/07/10 08:26, Steve Holden wrote:
> On 11/7/2010 8:23 AM, Grant Edwards wrote:
> [...]
>> (I bought 4:3 monitors before they got replaced by cheap 16:8
>> screens)
>
> I think you'll find the new aspect ration is 16:9.

Unless that's why they're cheap...

dual-16x9-widescreen-in-portrait-mode-is-a-wonderful-thing'ly,

-tkc

On 2010-11-07, Steve Holden <steve@holdenweb.com> wrote:
> On 11/7/2010 8:23 AM, Grant Edwards wrote:
> [...]
>> (I bought 4:3 monitors before they got replaced by cheap 16:8
>> screens)
>
> I think you'll find the new aspect ration is 16:9.

I knew that.  My keyboard didn't.

I recently bought a close-out Lenovo T500 Thinkpad from their outlet
because current models are now 16:9 instead of the older 16:10.  My
old 4:3 Thinkpad was still going strong, but I decided I'd better get
a 16:10 while I could -- though I'd still prefer a 4:3.

-- 
Grant

Seebs wrote:
> On 2010-11-05, Ethan Furman <ethan@stoneleaf.us> wrote:
>> The verifiable benefit for me is ease of use, ease of thought, ease of 
>> typing... I realize these are not benefits for everyone, but they are 
>> for some -- and I would venture a guess that the ease of thought benefit 
>> is one of the primary reasons Python is popular.  I am definitely one of 
>> those that think indentation based structure is one of Python's best 
>> features.
> 
> Could you explain more the "ease of thought" thing?  I haven't yet noticed
> it, but it might be something to look out for as I get more experienced.


Most if my programming experience is in FoxPro versions 2 and 6. 
Control structures start with if, for, do case, do while, with, 
procedure, and (I think) function.  Control structures end with endif, 
endfor, endcase, endwhile, endwith, endproc, and (I think) endfunc.

In Python, control structures start with if, for, while, try, def, and 
class, and each one ends with a dedent.

This really comes into play when developing -- want to change that if to 
a while?  Go ahead!  And no need to worry about tracking down the 
closing endif to change it to endwhile, plus it's less clutter on the 
screen.

I also really like the dynamic typing and not having to declare nor 
pre-initialize variable names, as well as the lack of a true global 
namespace.

All in all, I am able to think about the code and what I want to do, and 
not think about the compiler/interpreter and keeping it happy.

Hope this helps.

~Ethan~

Lawrence D'Oliveiro wrote:
> In message <iapom0$k4d$1@speranza.aioe.org>, Tim Harig wrote:
 >>
>> I personally prefer tabs as it lets *me* decide how far the apparent
>> indentations are in the code.
> 
> But they don’t. Other people can have different settings, and they will see 
> different indentations for your code

That's exactly the point -- each person can decide what level of 
indentation they prefer to look at.

~Ethan~

On 11/7/2010 10:46 AM, Grant Edwards wrote:
> On 2010-11-07, Steve Holden <steve@holdenweb.com> wrote:
>> On 11/7/2010 8:23 AM, Grant Edwards wrote:
>> [...]
>>> (I bought 4:3 monitors before they got replaced by cheap 16:8
>>> screens)
>>
>> I think you'll find the new aspect ration is 16:9.
> 
"aspect ration". Sheesh.

> I knew that.  My keyboard didn't.
> 
> I recently bought a close-out Lenovo T500 Thinkpad from their outlet
> because current models are now 16:9 instead of the older 16:10.  My
> old 4:3 Thinkpad was still going strong, but I decided I'd better get
> a 16:10 while I could -- though I'd still prefer a 4:3.
> 
The thing that *really* pisses me off is that you *used* to be able to
get 1920 x 1200 15" displays, but *now* you are lucky to go above 1080
vertical pixels even in a 17" laptop display. I don't want the
resolution of my displays dictated by the resolution of my (current)
media, yet it seems that's what's happened in the laptop market.

I got a Lenovo T60 a while back as a touchpad machine. Wondering about
switching that to Linux, but I haven't seen any touchpad distros in
action yet.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

On 2010-11-07, Mark Wooding <mdw@distorted.org.uk> wrote:
> I've no idea how people manage with these ridiculous widescreen monitors.

Side space used for Other Stuff.  It takes some reworking of the layout,
but overall I sorta like it now.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-07, Grant Edwards <invalid@invalid.invalid> wrote:
> On 2010-11-07, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
>> In message <87sjzige0r.fsf@benfinney.id.au>, Ben Finney wrote:
>>> The more general answer is: the block is explicitly ended where the
>>> indentation ends.

>> That's implicit, not explicit.

> If you can _see_ it, how is it implicit?

Humans can see negative space.  It's still implicit.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-07, Ethan Furman <ethan@stoneleaf.us> wrote:
> Seebs wrote:
>> On 2010-11-05, Ethan Furman <ethan@stoneleaf.us> wrote:
>>> The verifiable benefit for me is ease of use, ease of thought, ease of 
>>> typing... I realize these are not benefits for everyone, but they are 
>>> for some -- and I would venture a guess that the ease of thought benefit 
>>> is one of the primary reasons Python is popular.  I am definitely one of 
>>> those that think indentation based structure is one of Python's best 
>>> features.

>> Could you explain more the "ease of thought" thing?  I haven't yet noticed
>> it, but it might be something to look out for as I get more experienced.

> Most if my programming experience is in FoxPro versions 2 and 6. 
> Control structures start with if, for, do case, do while, with, 
> procedure, and (I think) function.  Control structures end with endif, 
> endfor, endcase, endwhile, endwith, endproc, and (I think) endfunc.

Eww.

> In Python, control structures start with if, for, while, try, def, and 
> class, and each one ends with a dedent.

So they're more consistent.

> This really comes into play when developing -- want to change that if to 
> a while?  Go ahead!  And no need to worry about tracking down the 
> closing endif to change it to endwhile, plus it's less clutter on the 
> screen.

I can see that.  I actually mostly prefer an explicit close.  Of the things
I've used, I'm happiest with braces, because punctuation is good at
being interpreted unconsciously, but I'm okay with "end" as long as it's
the same for everything.  I do like having a things bounded, though; I
find it easier to read:
	if (foo) {
		bar;
	}
	baz;
than
	if foo:
		bar
	baz;

(I'm not quite sure why, but I think it's because the trailing boundary is
part of the thing it bounds, rather than being the start of the thing after
it.)

I would definitely agree, though, that the Python solution is better
than what you describe for FoxPro.  It's also better, IMHO, than sh.

> I also really like the dynamic typing and not having to declare nor 
> pre-initialize variable names, as well as the lack of a true global 
> namespace.

I am torn on declarations -- I am pretty sure I make more mistakes
with clashing variable names when they aren't explicitly declared, but
I do like the much shorter code that results from not having them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-07, Steve Holden <steve@holdenweb.com> wrote:
> On 11/7/2010 10:46 AM, Grant Edwards wrote:
>> On 2010-11-07, Steve Holden <steve@holdenweb.com> wrote:
>>> On 11/7/2010 8:23 AM, Grant Edwards wrote:
>>> [...]
>>>> (I bought 4:3 monitors before they got replaced by cheap 16:8
>>>> screens)
>>>
>>> I think you'll find the new aspect ration is 16:9.
>> 
> "aspect ration". Sheesh.
>
>> I knew that.  My keyboard didn't.
>> 
>> I recently bought a close-out Lenovo T500 Thinkpad from their outlet
>> because current models are now 16:9 instead of the older 16:10.  My
>> old 4:3 Thinkpad was still going strong, but I decided I'd better get
>> a 16:10 while I could -- though I'd still prefer a 4:3.
>> 
> The thing that *really* pisses me off is that you *used* to be able to
> get 1920 x 1200 15" displays, but *now* you are lucky to go above 1080
> vertical pixels even in a 17" laptop display. I don't want the
> resolution of my displays dictated by the resolution of my (current)
> media, yet it seems that's what's happened in the laptop market.

It's getting really hard to find high-DPI displays on laptops any
more.  1600x1200 used to be available on 16" laptop displays, and that
looked great.  Even my old 15" thinkpad at 1400x1050 wasn't bad.

> I got a Lenovo T60 a while back as a touchpad machine. Wondering about
> switching that to Linux, but I haven't seen any touchpad distros in
> action yet.

-- 
Grant

In article <ib7ifn$48f$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> It's getting really hard to find high-DPI displays on laptops any
> more.  1600x1200 used to be available on 16" laptop displays, and that
> looked great.  Even my old 15" thinkpad at 1400x1050 wasn't bad.

My 15" MacBook Pro is 1680 x 1050.

On 2010-11-07, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <8jftftFelnU1@mid.individual.net>, Neil Cerutti wrote:
>
>> The handsome ':' terminator of if/elif/if statements allows us to
>> omit a newline, conserving vertical space. This improves the
>> readability of certain constructs.
>> 
>> if x: print(x)
>> elif y: print(y)
>> else: print()
>
> I would never do that. ???Conserving vertical space??? seems a
> stupid reason for doing it. In C, I even go the opposite way:
>
>     if (x)
>       {
>         printf(..., x);
>       }
>     else if (y)
>       {
>         printf(..., y);
>       }
>     else
>       {
>         printf(...);
>       } /*if*/

Interesting. I find conserving vertical space to be a big win. I
understand why you'd enforce braces for virtually all code bodies
in C. In C, I'm giving up the most obvious form of expression for
something obviously more robust. In Python, there's no such
trade-off. Forbidding one-line conditional statements in Python
would sacrifice succinctness for nothing.

-- 
Neil Cerutti

On 2010-11-08, Roy Smith <roy@panix.com> wrote:
> In article <ib7ifn$48f$1@reader1.panix.com>,
>  Grant Edwards <invalid@invalid.invalid> wrote:
>
>> It's getting really hard to find high-DPI displays on laptops any
>> more.  1600x1200 used to be available on 16" laptop displays, and that
>> looked great.  Even my old 15" thinkpad at 1400x1050 wasn't bad.
>
> My 15" MacBook Pro is 1680 x 1050.

Yep, Apple is one of the holdouts that still offers 16:10 high
resolution displays.  That's the same format/resolution that Lenovo
used to offer before they switched to 16:9.

-- 
Grant Edwards               grant.b.edwards        Yow! Boy, am I glad it's
                                  at               only 1971...
                              gmail.com            

On 11/8/2010 8:50 AM, Neil Cerutti wrote:
[...]
> Interesting. I find conserving vertical space to be a big win. I
> understand why you'd enforce braces for virtually all code bodies
> in C. In C, I'm giving up the most obvious form of expression for
> something obviously more robust. In Python, there's no such
> trade-off. Forbidding one-line conditional statements in Python
> would sacrifice succinctness for nothing.

One-line conditional statements aren't "forbidden" or they would not be
grammatically correct. Many stylists (and the PEP 8 style guide) eschew
the single-line form as less readable because the guarded suites (in
this case, simple statements) are not flagged as clearly by indentation
or a trailing colon, and are therefore more likely to be missed by the
casual reader.

regards
 Steve
-- 
Steve Holden           +1 571 484 6266   +1 800 494 3119
PyCon 2011 Atlanta March 9-17       http://us.pycon.org/
See Python Video!       http://python.mirocommunity.org/
Holden Web LLC                 http://www.holdenweb.com/

On 11/06/2010 02:27 AM, Seebs wrote:
> On 2010-11-06, Steve Holden <steve@holdenweb.com> wrote:
>> If someone were to use a text editor which had always historically
>> mangled whitespace I would find myself wondering why they found it
>> necessary to restrict themselves to such stone-age tools.
> 
> I have yet to find an editor that allows me to, well, *edit*, more
> comfortably than vi.

Indeed vi (or in my case, vim) works wonderfully well with python.  I
always use the following vim settings on python files:


set sw=4
set ts=8
set softtabstop=4
set expandtab
set ai

If you set up a conditional thing in your vimrc to enable these settings
for python files, you shouldn't have any more tab problems.

In message <87oca1b8ba.fsf.mdw@metalzone.distorted.org.uk>, Mark Wooding 
wrote:

> Vertical space is a limiting factor on how much code one can see at a
> time.

One thing that helps me is that Emacs has commands for quickly jumping 
between matching brackets.

Of course, this only works for languages that have brackets.

In message <ib698e$q45$1@reader1.panix.com>, Grant Edwards wrote:

> IOW, editing a loop or other control structure where you couldn't see both
> ends was problematic. Conserving vertical space avoids that problem.

No it doesn’t. It just moves it to a different, arbitrary, point a few 
percent away—not enough to be worth bothering about.

In message <ib6hkq$jih$1@reader1.panix.com>, Grant Edwards wrote:

> ... though I'd still prefer a 4:3.

4:3 still seems to be the best. It gives you a landscape A3-proportional 
view (or two A4-proportioned portrait pages side by side), and the little 
bit of space left over at the top or bottom can be used for toolbars, 
titlebars, that sort of thing.

On 2010-11-08, Michael Torrie <torriem@gmail.com> wrote:
> On 11/06/2010 02:27 AM, Seebs wrote:
>> I have yet to find an editor that allows me to, well, *edit*, more
>> comfortably than vi.

> Indeed vi (or in my case, vim) works wonderfully well with python.  I
> always use the following vim settings on python files:

Ahh, but I use nvi, not vim.

> If you set up a conditional thing in your vimrc to enable these settings
> for python files, you shouldn't have any more tab problems.

And I don't think I can do that in nvi -- I don't think it has conditionals.

Although.

You've just caused me to remember something which is in context both
amusing and funny.  Which is that I believe nvi has support for some
embedded scripting functionality, at least as an optional build choice.

Which I've never used, on the grounds that I don't know Python...

So that may actually be possible.  I'll look into it, for sure.  Thanks
for nudging my memory.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

On 2010-11-08, Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> wrote:
> In message <87oca1b8ba.fsf.mdw@metalzone.distorted.org.uk>, Mark Wooding 
> wrote:
>> Vertical space is a limiting factor on how much code one can see at a
>> time.

> One thing that helps me is that Emacs has commands for quickly jumping 
> between matching brackets.

> Of course, this only works for languages that have brackets.

Yes.  One of the things I find frustrating about the Ruby idiom of
preferring do/end for multiline blocks is that you can't fence-match
them.

-s
-- 
Copyright 2010, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> writes:

> In message <87oca1b8ba.fsf.mdw@metalzone.distorted.org.uk>, Mark Wooding 
> wrote:
>
>> Vertical space is a limiting factor on how much code one can see at a
>> time.
>
> One thing that helps me is that Emacs has commands for quickly jumping 
> between matching brackets.
>
> Of course, this only works for languages that have brackets.

python-mode has python-beginning-of-block (C-c C-u) and
python-end-of-block.

-- 
Arnaud

In message <mailman.718.1289147839.2218.python-list@python.org>, Ethan 
Furman wrote:

> Lawrence D'Oliveiro wrote:
>
>> In message <iapom0$k4d$1@speranza.aioe.org>, Tim Harig wrote:
>>>
>>> I personally prefer tabs as it lets *me* decide how far the apparent
>>> indentations are in the code.
>> 
>> But they don’t. Other people can have different settings, and they will
>> see different indentations for your code
> 
> That's exactly the point -- each person can decide what level of
> indentation they prefer to look at.

But I thought Mr Harig was referring to “*me*” as in the author of the code, 
not the reader.

Arnaud Delobelle <arnodel@gmail.com> writes:

> python-mode has python-beginning-of-block (C-c C-u) and
> python-end-of-block.

Yes.  It was one of my explicit gripes that editing Python requires one
to learn entirely new and unfamiliar keystrokes for doing fairly
familiar editing tasks.

-- [mdw]

On 2010-11-07, Ethan Furman <ethan@stoneleaf.us> wrote:
> Lawrence D'Oliveiro wrote:
>> In message <iapom0$k4d$1@speranza.aioe.org>, Tim Harig wrote:
>>> I personally prefer tabs as it lets *me* decide how far the
>>> apparent indentations are in the code.
>> 
>> But they don???t. Other people can have different settings,
>> and they will see different indentations for your code
>
> That's exactly the point -- each person can decide what level
> of indentation they prefer to look at.

That ideal works only if you are disciplined to never mix tabs
and spaces. "Wrapped" lines can become ugly when tabstop is
changed.

-- 
Neil Cerutti