Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #31725 > unrolled thread

Re: A desperate lunge for on-topic-ness

Back to article view | Back to comp.lang.python

Contents

  Re: A desperate lunge for on-topic-ness Jean-Michel Pichavant <jeanmichel@sequans.com> - 2012-10-19 11:21 +0200
    Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-19 22:14 +0000
      Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-19 20:23 -0400
        Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-20 14:18 +0000
          Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-20 15:10 -0400
          Re: A desperate lunge for on-topic-ness Walter Hurry <walterhurry@lavabit.com> - 2012-10-20 20:02 +0000
          Re: A desperate lunge for on-topic-ness David Robinow <drobinow@gmail.com> - 2012-10-20 16:02 -0400
          Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 08:07 +0000
            Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-21 20:20 +1100
              Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 10:00 +0000
                Re: printing (was: A desperate lunge for on-topic-ness) Tim Chase <python.list@tim.thechases.com> - 2012-10-21 06:03 -0500
                Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-21 22:43 +1100
                  Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-21 19:11 +0000
                    Re: A desperate lunge for on-topic-ness Grant Edwards <invalid@invalid.invalid> - 2012-10-21 19:23 +0000
                      Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-21 16:19 -0400
                        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 07:38 +1100
                    Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 07:22 +1100
                      Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-22 06:30 +0000
                        Re: A desperate lunge for on-topic-ness Chris Angelico <rosuav@gmail.com> - 2012-10-22 18:03 +1100
                        Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-22 08:29 -0400
                          RE: A desperate lunge for on-topic-ness "Prasad, Ramit" <ramit.prasad@jpmorgan.com> - 2012-10-22 20:48 +0000
                        Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-22 16:02 -0600
                        Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-22 21:39 -0400
                        Re: A desperate lunge for on-topic-ness Joshua Landau <joshua.landau.ws@gmail.com> - 2012-10-23 08:35 +0100
                        Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-23 10:50 -0600
                          Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-23 22:34 +0000
                            Re: A desperate lunge for on-topic-ness Ian Kelly <ian.g.kelly@gmail.com> - 2012-10-23 17:24 -0600
                              Re: A desperate lunge for on-topic-ness Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-10-24 00:04 +0000
            Re: A desperate lunge for on-topic-ness Gene Heskett <gheskett@wdtv.com> - 2012-10-21 07:08 -0400
            Re: A desperate lunge for on-topic-ness Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2012-10-21 12:42 -0400
          Re: A desperate lunge for on-topic-ness DJC <djc@news.invalid> - 2012-10-21 15:06 +0100
      Re: A desperate lunge for on-topic-ness Tim Chase <python.list@tim.thechases.com> - 2012-10-19 22:27 -0500
        Re: A desperate lunge for on-topic-ness rusi <rustompmody@gmail.com> - 2012-10-20 00:35 -0700
      Re: A desperate lunge for on-topic-ness Roy Smith <roy@panix.com> - 2012-10-20 16:37 -0400
        Re: A desperate lunge for on-topic-ness Walter Hurry <walterhurry@lavabit.com> - 2012-10-21 21:58 +0000

Page 1 of 2  [1] 2  Next page →

#31725 — Re: A desperate lunge for on-topic-ness

----- Original Message -----
[snipe 80 char line discussion] 
> And, quite frankly, people who care more about the readability of
> their
> code than about squeezing in as much processing into a single line of
> text as possible.
> 

As usual Steven, you take someone's argument, you add a little bit of exaggeration and make it sound silly.
Using 80+ char lines doesn't mean I put all my efforts exceeding the 80 char limit. As a matter of fact, I never
get the char limit get into the way of readability. What needs to be short will be short, and what needs to be long will be long.


[snip] 
> Flame away :)

good job :o)

JM

[toc] | [next] | [standalone]

#31777

On Fri, 19 Oct 2012 11:21:06 +0200, Jean-Michel Pichavant wrote:

> Using 80+ char lines doesn't mean
> I put all my efforts exceeding the 80 char limit.

I didn't say it did. I was describing some of the reasons people might 
choose to stick to the 79 character limit, beyond the reason you gave, 
which quite frankly is the least important reason. 80 character 
terminals? Who still uses them? Well, a few people, but they're in a 
minority. But caring about the readability of code? Everyone needs to 
read code at some point, and 79 characters is a good balance between 
stuffing too much into a single line and spreading it out too thinly over 
multiple lines.


> As a matter of fact, I
> never get the char limit get into the way of readability. What needs to
> be short will be short, and what needs to be long will be long.

Code never *needs* to be long, because it can always be shortened.

Some code might be more conveniently written as a single long line. But I 
would argue that nearly never is code more easily *read* as a single long 
line, and since code is read much more than it is written, it is more 
important to optimise for reading, not writing.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31785

On 19 Oct 2012 22:14:27 GMT, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> declaimed the following in
gmane.comp.python.general:


> I didn't say it did. I was describing some of the reasons people might 
> choose to stick to the 79 character limit, beyond the reason you gave, 
> which quite frankly is the least important reason. 80 character 
> terminals? Who still uses them? Well, a few people, but they're in a 
> minority. But caring about the readability of code? Everyone needs to 
> read code at some point, and 79 characters is a good balance between 
> stuffing too much into a single line and spreading it out too thinly over 
> multiple lines.
> 

	Strangely, we've gone from 80-character fixed width displays to
who-knows-what (if I drop my font size I can probably get nearly 200
characters across in full-screen mode)...

	But at the same time we've gone from 132-character line-printers
using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11
paper, defaulting to portrait orientation -- with a 10 character/inch
font, and 1/4" left/right margins, we're back to 80 character limitation
<G>
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#31813

On 2012-10-20, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:

> 	Strangely, we've gone from 80-character fixed width displays to
> who-knows-what (if I drop my font size I can probably get nearly 200
> characters across in full-screen mode)...
>
> 	But at the same time we've gone from 132-character line-printers
> using fan-fold 11x17 pages, to office inkjet/laser printers using 8.5x11
> paper, defaulting to portrait orientation -- with a 10 character/inch
> font, and 1/4" left/right margins, we're back to 80 character limitation
><G>

True, but nobody prints source code out on paper do they?

Seriously -- I can't remember the last time I printed souce code...

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#31815

On Sat, 20 Oct 2012 14:18:47 +0000 (UTC), Grant Edwards
<invalid@invalid.invalid> declaimed the following in
gmane.comp.python.general:

> 
> True, but nobody prints source code out on paper do they?
> 
> Seriously -- I can't remember the last time I printed souce code...

	Well, having been unemployed for a year, I can't speak much of
recent practice...

	But I did tend to run up listings when I had to take over
maintenance of some programs and needed to become familiar with the
overall code base...
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#31818

On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:

> True, but nobody prints source code out on paper do they?
> 
> Seriously -- I can't remember the last time I printed souce code...

I remember my first IT job - COBOL programming in the early 80's. The 
rule was that every time we delivered a new or updated program into 
testing, we had to print a listing onto fanfold paper and hang it, in a 
cardboard binder, onto a set of rails which ran down the center of the 
office.

I recall even then thinking the practice ludicrous.

[toc] | [prev] | [next] | [standalone]

#31819

On Sat, Oct 20, 2012 at 3:10 PM, Dennis Lee Bieber
<wlfraed@ix.netcom.com> wrote:
> On Sat, 20 Oct 2012 14:18:47 +0000 (UTC), Grant Edwards
> <invalid@invalid.invalid> declaimed the following in
> gmane.comp.python.general:
>
>>
>> True, but nobody prints source code out on paper do they?
>>
>> Seriously -- I can't remember the last time I printed souce code...
>
>         Well, having been unemployed for a year, I can't speak much of
> recent practice...
>
>         But I did tend to run up listings when I had to take over
> maintenance of some programs and needed to become familiar with the
> overall code base...
Same here. I've been unemployed (retired!) 6 years, but I'd
occasionally print code written by someone else, never anything of my
own.

[toc] | [prev] | [next] | [standalone]

#31837

On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:

> On 2012-10-20, Dennis Lee Bieber <wlfraed@ix.netcom.com> wrote:
> 
>> 	Strangely, we've gone from 80-character fixed width displays to
>> who-knows-what (if I drop my font size I can probably get nearly 200
>> characters across in full-screen mode)...
>>
>> 	But at the same time we've gone from 132-character line-printers
>> using fan-fold 11x17 pages, to office inkjet/laser printers using
>> 8.5x11 paper, defaulting to portrait orientation -- with a 10
>> character/inch font, and 1/4" left/right margins, we're back to 80
>> character limitation
>><G>
> 
> True, but nobody prints source code out on paper do they?

I do.

There's nothing better than spreading out a dozen sheets of source code 
over a table to get a good, high-level overview of what does what in 
preparation to refactoring it.


> Seriously -- I can't remember the last time I printed souce code...

I've never printed souce code either *wink*



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31841

On Sun, Oct 21, 2012 at 7:07 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:
>> True, but nobody prints source code out on paper do they?
>
> I do.
>
> There's nothing better than spreading out a dozen sheets of source code
> over a table to get a good, high-level overview of what does what in
> preparation to refactoring it.
>
>> Seriously -- I can't remember the last time I printed souce code...
>
> I've never printed souce code either *wink*

So what you actually mean is that there's nothing _like_ spreading out
&c &c. I should think that throwing cold water over the code would be
better.

ChrisA

[toc] | [prev] | [next] | [standalone]

#31842

On Sun, 21 Oct 2012 20:20:41 +1100, Chris Angelico wrote:

> On Sun, Oct 21, 2012 at 7:07 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> On Sat, 20 Oct 2012 14:18:47 +0000, Grant Edwards wrote:
>>> True, but nobody prints source code out on paper do they?
>>
>> I do.
>>
>> There's nothing better than spreading out a dozen sheets of source code
>> over a table to get a good, high-level overview of what does what in
>> preparation to refactoring it.
>>
>>> Seriously -- I can't remember the last time I printed souce code...
>>
>> I've never printed souce code either *wink*
> 
> So what you actually mean is that there's nothing _like_ spreading out
> &c &c. I should think that throwing cold water over the code would be
> better.

Er, no. Note spelling of "source code" vs "souce code". Hence the grin.

I seriously do print out source code. When I'm having trouble seeing how 
the parts of a module fit together, reading print-outs is a good way 
around the problem. Class browsers don't show you duplicate code, and 
besides, only works with classes. Reading code on screen is limited in 
how much you can see at a time. Both of these things play a part in 
refactoring, and so does printing out the source and having a human being 
(i.e. me) look at it.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31844 — Re: printing (was: A desperate lunge for on-topic-ness)

On 10/21/12 05:00, Steven D'Aprano wrote:
> I seriously do print out source code. When I'm having trouble
> seeing how the parts of a module fit together, reading print-outs
> is a good way around the problem.

I don't print my personal code--both in light of the fact that I
know it much more intimately and I longer own a printer.  But when
trying to wrap my head around other people's code at work, printing
helps to get both the big picture and the details at the same time,
as well as allows me to annotate it with multi-colored
pens/highlighters.

Maybe I'll reconsider when I have a 300+ dpi desktop surface that is
as large as my desk+walls (where those printouts end up).

-tkc

[toc] | [prev] | [next] | [standalone]

#31848

On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.

Ahh. I totally didn't see that, I'm way too used to reading past
typos. Sure. Printing out *source* code, that's altogether different.

Me, though, I don't print anything. Paper and I are not exactly on
speaking terms; the last time we met, he cut me, and that's one of the
rudest things you can do to someone.

ChrisA

[toc] | [prev] | [next] | [standalone]

#31858

On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:

> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
> 
> Ahh. I totally didn't see that, I'm way too used to reading past typos.

As a programmer, doesn't that screw up your debugging ability?


> Sure. Printing out *source* code, that's altogether different.
> 
> Me, though, I don't print anything. Paper and I are not exactly on
> speaking terms; the last time we met, he cut me, and that's one of the
> rudest things you can do to someone.

Man, you must have deserved it. Paper, he don't just cut anybody.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31859

On 2012-10-21, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
>
>> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
>> 
>> Ahh. I totally didn't see that, I'm way too used to reading past typos.
>
> As a programmer, doesn't that screw up your debugging ability?

Indeed it does.

I spent a half hour the other day trying to figure out what was wrong
with a line of PHP code, when it was nothing but a mis-spelled
variable name.  [I've only been working with PHP a short time, but
have quickly grown to dislike it.]

-- 
Grant

[toc] | [prev] | [next] | [standalone]

#31860

In article <k61i2o$63u$1@reader1.panix.com>,
 Grant Edwards <invalid@invalid.invalid> wrote:

> On 2012-10-21, Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:
> > On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
> >
> >> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
> >> <steve+comp.lang.python@pearwood.info> wrote:
> >>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
> >> 
> >> Ahh. I totally didn't see that, I'm way too used to reading past typos.
> >
> > As a programmer, doesn't that screw up your debugging ability?
> 
> Indeed it does.

The human brain is amazingly good at real-time error correction.  For 
the most part, this improves communication since it lets people make all 
sorts of minor errors in both spoken and written language without 
seriously degrading comprehension.

The down-side is that you hear (and read) what you're expecting to hear 
(or read).  This makes us really suck as things like finding typos in 
variable names.

> I spent a half hour the other day trying to figure out what was wrong
> with a line of PHP code, when it was nothing but a mis-spelled
> variable name.  [I've only been working with PHP a short time, but
> have quickly grown to dislike it.]

Of course, the same can happen in Python.  I could do:

foo = "default value"
if blah == 47:
   fooo = "some other value"
print foo

No syntax error, no NameError, just the wrong thing printing.  This does 
not in any way detract from the fact that PHP is a horrible language.  
Trust me, if you continue to use it, your dislike for it will only grow.  
It is truly evil.  Have you discovered "unexpected 
T_PAAMAYIM_NEKUDOTAYIM" yet?

[toc] | [prev] | [next] | [standalone]

#31863

On Mon, Oct 22, 2012 at 7:19 AM, Roy Smith <roy@panix.com> wrote:
> Of course, the same can happen in Python.  I could do:
>
> foo = "default value"
> if blah == 47:
>    fooo = "some other value"
> print foo
>
> No syntax error, no NameError, just the wrong thing printing.

Yeah, that's the worst kind of bug. No error, just wrong behaviour.
This kind of issue is one of the "balancing downsides" of the freedom
of not requiring variable declarations. For small scripts, it's not a
problem, and Python and PHP both save you the hassle of explicitly
telling the language that you really do know what you're doing, and
that's a Good Thing. For large modules, debugging creeps up in
significance, and variable declarations are less of a cost.
JaCMaScript in "use strict" mode and a good linter can catch a lot of
these sorts of bugs, though it has its own weirdnesses (why does a
'var' statement apply to the whole function regardless of where it
is?). C-derived languages with proper block scope have a good chance
of catching bugs of this nature at compile time, but at the cost of
demanding code that's mainly there to satisfy the compiler ("isn't it
OBVIOUS that I want this to be an integer? I'm assigning an integer to
it!").

> This does
> not in any way detract from the fact that PHP is a horrible language.
> Trust me, if you continue to use it, your dislike for it will only grow.
> It is truly evil.  Have you discovered "unexpected
> T_PAAMAYIM_NEKUDOTAYIM" yet?

The double-double-dot-in-Hebrew token name isn't actually a bad error;
the only problem is the token name itself. If it said "unexpected
T_SCOPE" or something, it'd be easier to debug. Several of PHP's most
annoying issues are solved in version 5.4 (array indexing a function
call that returns an array now works), but there's still a huge
fundamental that's unsolved: Unicode support. Python FTW there,
especially now that PEP 393 means strings are as compact as possible.

ChrisA

[toc] | [prev] | [next] | [standalone]

#31861

On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Sun, 21 Oct 2012 22:43:07 +1100, Chris Angelico wrote:
>
>> On Sun, Oct 21, 2012 at 9:00 PM, Steven D'Aprano
>> <steve+comp.lang.python@pearwood.info> wrote:
>>> Er, no. Note spelling of "source code" vs "souce code". Hence the grin.
>>
>> Ahh. I totally didn't see that, I'm way too used to reading past typos.
>
> As a programmer, doesn't that screw up your debugging ability?

Reading-past-typos applies mainly to English, which is a pretty
redundant language. In code, it would only apply to variable names;
with (effectively) single words/tokens standing alone, the automatic
correction doesn't really apply. But yes, sometimes I have stared at a
piece of code for a long time without knowing why there's an error on
line X. (This is another good reason to require that all variables be
declared, incidentally. I might have a variable called "source" but
not "souce", so using the other causes an instant compile-time failure
on the exact line with the bug.)

And Grant, I agree; PHP does not make life easy.

>> Sure. Printing out *source* code, that's altogether different.
>>
>> Me, though, I don't print anything. Paper and I are not exactly on
>> speaking terms; the last time we met, he cut me, and that's one of the
>> rudest things you can do to someone.
>
> Man, you must have deserved it. Paper, he don't just cut anybody.

Perhaps. Also, perhaps I've just finished Hell Week and am behaving
less than sanely, with a strong tendency to quote/reference Through
The Looking Glass. :)

ChrisA

[toc] | [prev] | [next] | [standalone]

#31878

On Mon, 22 Oct 2012 07:22:18 +1100, Chris Angelico wrote:

> On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:

>>> Ahh. I totally didn't see that, I'm way too used to reading past
>>> typos.
>>
>> As a programmer, doesn't that screw up your debugging ability?
> 
> Reading-past-typos applies mainly to English, which is a pretty
> redundant language. In code, it would only apply to variable names; with
> (effectively) single words/tokens standing alone, the automatic
> correction doesn't really apply. But yes, sometimes I have stared at a
> piece of code for a long time without knowing why there's an error on
> line X. (This is another good reason to require that all variables be
> declared, incidentally. I might have a variable called "source" but not
> "souce", so using the other causes an instant compile-time failure on
> the exact line with the bug.)

"Another" good reason?

For languages without static types, what other reasons for declaring 
variables are there?



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#31879

On Mon, Oct 22, 2012 at 5:30 PM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> For languages without static types, what other reasons for declaring
> variables are there?

The main one is scope nesting. Compare a few different languages.

Python: If you don't declare, it's global if you don't rebind it, but
local if you do. You may declare variables as global or nonlocal.

PHP: If you don't declare, it's local, but functions are in a separate scope.

C: If you don't declare, it's looked for in some broader scope. If
it's not declared in any scope, error.

All three approaches make reasonable sense. The PHP one is perfectly
consistent, but would be hopelessly impractical if all your function
names had to be marked off as globals. (Plus PHP has superglobals,
with their own Marvellous mess.) Python's system "just works" most of
the time, but can introduce yet another trap for the unsuspecting
newbie who doesn't understand the difference between rebinding and
mutating; I've not looked into multiple levels of closures but I
suspect there'll be odd limitations there, as there's only one
"nonlocal" keyword. The C style has administrative overhead (requiring
explicit declarations for all variables), but allows full flexibility
(variables having narrower scope than entire functions, infinite
nesting of scopes, etc).

Incidentally, variable declarations don't have to be connected with
static typing. JavaScript/ECMAScript simply has 'var x;' to declare
that x exists in this function. But it's hardly a language that I'd
hold up as a shining example; a var declaration anywhere in a function
makes that variable name local to that entire function. There's
actually no block scoping at all. And then there's the whole confusion
of the global object, 'this', and 'with' statements...

You knew I was going to cite it sooner or later :) Pike has true block
scoping, though unlike C++, Pike does not guarantee that destructors
will be called immediately at the close brace (but zero-reference
objects will be cleaned up, including destructor calls, at the next
function return - even if not the current function). Variables can be
mostly-statically-typed, or can be declared as 'mixed' and be rebound
freely (like in JS and Python). So scoped variable declarations and
static typing are quite orthogonal.

ChrisA

[toc] | [prev] | [next] | [standalone]

#31881

In article <5084e819$0$29897$c3e8da3$5496439d@news.astraweb.com>,
 Steven D'Aprano <steve+comp.lang.python@pearwood.info> wrote:

> On Mon, 22 Oct 2012 07:22:18 +1100, Chris Angelico wrote:
> 
> > On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
> > <steve+comp.lang.python@pearwood.info> wrote:
> 
> >>> Ahh. I totally didn't see that, I'm way too used to reading past
> >>> typos.
> >>
> >> As a programmer, doesn't that screw up your debugging ability?
> > 
> > Reading-past-typos applies mainly to English, which is a pretty
> > redundant language. In code, it would only apply to variable names; with
> > (effectively) single words/tokens standing alone, the automatic
> > correction doesn't really apply. But yes, sometimes I have stared at a
> > piece of code for a long time without knowing why there's an error on
> > line X. (This is another good reason to require that all variables be
> > declared, incidentally. I might have a variable called "source" but not
> > "souce", so using the other causes an instant compile-time failure on
> > the exact line with the bug.)
> 
> "Another" good reason?
> 
> For languages without static types, what other reasons for declaring 
> variables are there?

Variable declarations serve two purposes.  One is to declare the type 
(which obviously doesn't apply to Python).  The other is to declare the 
beginning of a scope.

On occasion, I will make typos in variable names which a 
scope-introduction declaration would have prevented.  If the cost of 
having to declare every variable would be justified by the rare bug it 
would prevent, is another question.

Pet peeve of the day...

Why do you have to write:

global foo
foo = 4

when

global foo = 4

would have been so much easier?

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | comp.lang.python

csiph-web