Python's "only one way to do it" philosophy isn't good?

[Douglas Alan]

Graham Breed <x31equsenet at gmail.com> writes:

> Another way is to decorate functions with their local variables:

>>>> from strict import my
>>>> @my("item")
> ... def f(x=1, y=2.5, z=[1,2,4]):
> ...     x = float(x)
> ...     w = float(y)
> ...     return [item+x-y for item in z]

Well, I suppose that's a bit better than the previous suggestion, but
(1) it breaks the style rule of not declaring variables until you need
them, and (2) it doesn't catch double initialization.

> The best way to catch false rebindings is to stick a comment with
> the word "rebound" after every statement where you think you're
> rebinding a variable.

No, the best way to catch false rebindings is to have the computers
catch such errors for you.  That's what you pay them for.

> Then you can search your code for cases where there's a "rebound"
> comment but no rebinding.

And how do I easily do that?  And how do I know if I even need to in
the face of sometimes subtle bugs?

> Assuming you're the kind of person who knows that false rebindings
> can lead to perplexing bugs, but doesn't check apparent rebindings
> in a paranoid way every time a perplexing bug comes up, anyway.
> (They aren't that common in modern python code, after all.)

They're not that uncommon, either.

I've certainly had it happen to me on several occasions, and sometimes
they've been hard to find as I might not even see the mispeling even
if I read the code 20 times.

(Like the time I spent all day trying to figure out why my assembly
code wasn't working when I was a student and finally I decided to ask
the TA for help, and while talking him through my code so that he
could tell me what I was doing wrong, I finally noticed the "rO" where
there was supposed to be an "r0".  It's amazing how useful a TA can
be, while doing nothing at all!)

> And you're also the kind of person who's troubled by perplexing bugs
> but doesn't run a fully fledged lint.

Maybe PyLint is better than Lint for C was (hated it!), but my idea of
RAD does not include wading through piles of useless warning messages
looking for the needle warning in the warning haystack.  Or running
any other programs in the midst of my code, run, code, run, ..., loop.

> Maybe that's the kind of person who wouldn't put up with anything
> short of a macro as in the original proposal.  All I know is that
> it's the kind of person I don't want to second guess.

As it is, I code in Python the way that a normal Python programmer
would, and when I have a bug, I track it down through sometimes
painstaking debugging as a normal Python programmer would.  Just as
any other normal Python programmer, I would not use the alternatives
suggested so far, as I'd find them cumbersome and inelegant.  I'd
prefer not to have been bit by the bugs to begin with.  Consequently,
I'd use let and set statements, if they were provided (or if I could
implement them), just as I have the equivalents to let and set in
every other programming language that I commonly program in other than
Python.

|>oug