Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: A desperate lunge for on-topic-ness

Reply
Thread Tools

Re: A desperate lunge for on-topic-ness

 
 
Roy Smith
Guest
Posts: n/a
 
      10-21-2012
In article <k61i2o$63u$(E-Mail Removed)>,
Grant Edwards <(E-Mail Removed)> wrote:

> On 2012-10-21, Steven D'Aprano <(E-Mail Removed)> 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
> >> <(E-Mail Removed)> 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?
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      10-21-2012
On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
<(E-Mail Removed)> 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
>> <(E-Mail Removed)> 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
 
Reply With Quote
 
 
 
 
Chris Angelico
Guest
Posts: n/a
 
      10-21-2012
On Mon, Oct 22, 2012 at 7:19 AM, Roy Smith <(E-Mail Removed)> 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
 
Reply With Quote
 
Walter Hurry
Guest
Posts: n/a
 
      10-21-2012
On Sat, 20 Oct 2012 16:37:23 -0400, Roy Smith wrote:

> sys.stderr.write("Error: Can't find the file 'settings.py'
> in the directory containing %r.\nYou'll have to run django-profile.py,
> passing it your settings module.\n(If the file settings.py does indeed
> exist, it's causing an ImportError somehow.)\n" % __file__)


textwrap.dedent?

 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      10-22-2012
On Mon, 22 Oct 2012 07:22:18 +1100, Chris Angelico wrote:

> On Mon, Oct 22, 2012 at 6:11 AM, Steven D'Aprano
> <(E-Mail Removed)> 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
 
Reply With Quote
 
Chris Angelico
Guest
Posts: n/a
 
      10-22-2012
On Mon, Oct 22, 2012 at 5:30 PM, Steven D'Aprano
<(E-Mail Removed)> 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
 
Reply With Quote
 
Roy Smith
Guest
Posts: n/a
 
      10-22-2012
In article <5084e819$0$29897$c3e8da3$(E-Mail Removed) om>,
Steven D'Aprano <(E-Mail Removed)> 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
> > <(E-Mail Removed)> 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?
 
Reply With Quote
 
Prasad, Ramit
Guest
Posts: n/a
 
      10-22-2012
Roy Smith wrote:

> Pet peeve of the day...
>
> Why doyou have to write:
>
> global foo
> foo = 4
>
> when
>
> global foo = 4
>
> would have been somuch easier?


To make it more annoying for people who use globals, duh.

Ramit Prasad

This email is confidential and subject to important disclaimers and
conditions including on offers for the purchase or sale of
securities, accuracy and completeness ofinformation, viruses,
confidentiality, legal privilege, and legal entity disclaimers,
available at http://www.jpmorgan.com/pages/disclosures/email.
 
Reply With Quote
 
Ian Kelly
Guest
Posts: n/a
 
      10-22-2012
On Mon, Oct 22, 2012 at 1:03 AM, Chris Angelico <(E-Mail Removed)> wrote:
> 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.


On my wishlist for Python is a big, fat SyntaxError for any variable
that could be interpreted as either local or nonlocal and is not
explicitly declared as either. It would eliminate this sort of
confusion entirely and make code that shadows nonlocal variables much
more readable.

Ideally, the same thing would also be done for locals that shadow
globals, but I don't see how that could possibly be enforced at
compile time.
 
Reply With Quote
 
Dennis Lee Bieber
Guest
Posts: n/a
 
      10-23-2012
On Mon, 22 Oct 2012 16:02:34 -0600, Ian Kelly <(E-Mail Removed)>
declaimed the following in gmane.comp.python.general:

> On my wishlist for Python is a big, fat SyntaxError for any variable
> that could be interpreted as either local or nonlocal and is not
> explicitly declared as either. It would eliminate this sort of
> confusion entirely and make code that shadows nonlocal variables much
> more readable.
>

Which now makes code dependent upon changes to some imported modules
if someone is foolish enough to use the

from xyz import *

notation...

I'd be very displeased if working code with local names suddenly
fails because some third-party package was updated.

Yes, I prefer not to use the "from...*" notation, but how many
tutorials (especially of GUI toolkits, with their dozens of constants)
illustrate using the wildcard?
--
Wulfraed Dennis Lee Bieber AF6VN
http://www.velocityreviews.com/forums/(E-Mail Removed) HTTP://wlfraed.home.netcom.com/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
A desperate lunge for on-topic-ness Zero Piraeus Python 24 10-19-2012 10:16 PM
Re: A desperate lunge for on-topic-ness Jean-Michel Pichavant Python 2 10-19-2012 05:59 PM
Re: A desperate lunge for on-topic-ness Mark Lawrence Python 0 10-18-2012 09:12 AM
Re: A desperate lunge for on-topic-ness Demian Brecht Python 0 10-18-2012 06:52 AM
Re: A desperate lunge for on-topic-ness Chris Angelico Python 0 10-18-2012 06:13 AM



Advertisments