Compare source code

S

Steven D'Aprano


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.

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?
 
S

Seebs

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
 
S

Seebs

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
 
S

Steve Holden

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
 
S

Seebs

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
 
T

Tim Chase

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.
 
L

Lawrence D'Oliveiro

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.
 
L

Lawrence D'Oliveiro

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.
 
L

Lawrence D'Oliveiro

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*/
 
L

Lawrence D'Oliveiro

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.
 
M

Mark Wooding

Lawrence D'Oliveiro said:
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]
 
G

Grant Edwards

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).
 
S

Steve Holden

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
 
R

Roy Smith

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.
 
T

Tim Chase

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
 
G

Grant Edwards

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.
 
E

Ethan Furman

Seebs said:
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~
 
E

Ethan Furman

Lawrence said:
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~
 
S

Steve Holden

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
 

Ask a Question

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

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

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top