Compare source code

[Seebs]

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

 

[Seebs]

If you can _see_ it, how is it implicit?

Humans can see negative space. It's still implicit.

-s

 

[Seebs]

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

 

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

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

 

[Roy Smith]

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.

 

[Neil Cerutti]

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.

 

[Grant Edwards]

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.

 

[Steve Holden]

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

 

[Michael Torrie]

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.

 

[Lawrence D'Oliveiro]

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.

 

[Lawrence D'Oliveiro]

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.

 

[Lawrence D'Oliveiro]

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

 

[Seebs]

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

 

[Seebs]

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

 

[Arnaud Delobelle]

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.

 

[Lawrence D'Oliveiro]

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.

 

[Mark Wooding]

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]

 

[Neil Cerutti]

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.