> On 2010-11-05, Grant Edwards <inva...@invalid.invalid> wrote: >> On 2010-11-05, Seebs <usenet-nos...@seebs.net> wrote: >>> On 2010-11-05, Emile van Sebille <em...@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.
On 2010-11-06, Steve Holden <st...@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.
> On 2010-11-06, Steve Holden<st...@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.
Rustom Mody <rustompm...@gmail.com> writes: > As for tools' brokeness regarding spaces/tabs/indentation heres a > thread on the emacs list wherein emacs dev Stefan Monnier admits to > the fact that emacs' handling in this regard is not perfect.
You've misunderstood. That discussion is about configuring Emacs to not do automatic indentation when the `tab' key is pressed or when language-specific punctuation is entered. It has very little to do with tab characters in files.
On Nov 6, 5:21 pm, m...@distorted.org.uk (Mark Wooding) wrote:
> Rustom Mody <rustompm...@gmail.com> writes: > > As for tools' brokeness regarding spaces/tabs/indentation heres a > > thread on the emacs list wherein emacs dev Stefan Monnier admits to > > the fact that emacs' handling in this regard is not perfect.
> You've misunderstood. That discussion is about configuring Emacs to not > do automatic indentation when the `tab' key is pressed or when > language-specific punctuation is entered. It has very little to do with > tab characters in files.
The OP there clearly says he needs help in dealing consistently with 'tabbed' files. Mixing up these 2 issues (actually 3) is the 'Eternal Holy War' that Jamie Zawinski talks about here http://www.jwz.org/doc/tabs-vs-spaces.html
Note: I am in no way supporting the demand that python should suddenly get 'braced' beacuse:
a. this would do too much violence to the essential -- 'executable- pseudo-code' -- spirit of the language b. Anyway for me personally python and haskell are two of my favorites and one their common features is this: indentation == program structure
I am only pointing to the fact that one of the widely used and super- powerful editors is less than perfect in this regard
In message <slrnid9ln8.30fm.usenet-nos...@guild.seebs.net>, Seebs wrote:
> Specifically:
> Four spaces followed by a tab nearly always actually means "eight spaces" > to most editors (and Python seems to treat it that way), but it's hard to > tell. Worse, a tab may have been intended to be the same thing as four > spaces, and someone was expecting it NOT to be the same as eight spaces...
Whereas explicitly-bracketed languages leave no ambiguity about how many brackets you need and where.
On 2010-11-07, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote:
> In message <slrnid9ln8.30fm.usenet-nos...@guild.seebs.net>, Seebs wrote: >> Four spaces followed by a tab nearly always actually means "eight spaces" >> to most editors (and Python seems to treat it that way), but it's hard to >> tell. Worse, a tab may have been intended to be the same thing as four >> spaces, and someone was expecting it NOT to be the same as eight spaces... > Whereas explicitly-bracketed languages leave no ambiguity about how many > brackets you need and where.
Well, the good ones don't. :P (I think the optional nature of brackets is probably a flaw in C. It would break too much existing code to fix it, sadly.)
On Sun, 07 Nov 2010 14:53:45 +1300, Lawrence D'Oliveiro wrote: > In message <slrnid9ln8.30fm.usenet-nos...@guild.seebs.net>, Seebs wrote:
>> Specifically:
>> Four spaces followed by a tab nearly always actually means "eight >> spaces" to most editors (and Python seems to treat it that way), but >> it's hard to tell. Worse, a tab may have been intended to be the same >> thing as four spaces, and someone was expecting it NOT to be the same >> as eight spaces...
> Whereas explicitly-bracketed languages leave no ambiguity about how many > brackets you need and where.
Yes, and?
The way people[1] go on, and on, and ON about braces and indentation, anyone would think that the hardest part of programming was deciding how many times to press the tab key.
Besides, if we used reverse Polish notation, we wouldn't need either brackets or indentation.
On 2010-11-07, Steven D'Aprano <st...@REMOVE-THIS-cybersource.com.au> wrote:
> On Sun, 07 Nov 2010 14:53:45 +1300, Lawrence D'Oliveiro wrote: >> In message <slrnid9ln8.30fm.usenet-nos...@guild.seebs.net>, Seebs wrote: >>> Four spaces followed by a tab nearly always actually means "eight >>> spaces" to most editors (and Python seems to treat it that way), but >>> it's hard to tell. Worse, a tab may have been intended to be the same >>> thing as four spaces, and someone was expecting it NOT to be the same >>> as eight spaces... >> Whereas explicitly-bracketed languages leave no ambiguity about how many >> brackets you need and where. > Yes, and?
In context, I think the comment was sarcastic, referring to C's famous ambiguities caused by optional braces.
In message <iapom0$k4...@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 <8jftftFel...@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.
>> On 2010-11-03, Steven D'Aprano <steve-REMOVE-T...@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.
Lawrence D'Oliveiro <l...@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.
On 2010-11-07, Mark Wooding <m...@distorted.org.uk> wrote:
> Lawrence D'Oliveiro <l...@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).
>>> On 2010-11-03, Steven D'Aprano <steve-REMOVE-T...@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.
In article <87oca1b8ba.fsf....@metalzone.distorted.org.uk>, m...@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 2010-11-07, Steve Holden <st...@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.
Seebs wrote: > On 2010-11-05, Ethan Furman <et...@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.
> On 2010-11-07, Steve Holden <st...@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.
On 2010-11-07, Grant Edwards <inva...@invalid.invalid> wrote:
> On 2010-11-07, Lawrence D'Oliveiro <l...@geek-central.gen.new_zealand> wrote: >> In message <87sjzige0r....@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.
