Links

Lists

Latest Updates

Ruby On Rails List
Python list
Advanced Java
The JavaScript List
Apache Users
Full Disclosure
Linux Security

Search the archives!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Experimentation and dealing with transient broken code (was: Python end of file marker similar to perl's __END__)


  • From: bignose+hates-spam at benfinney.id.au (Ben Finney)
  • Subject: Experimentation and dealing with transient broken code (was: Python end of file marker similar to perl's __END__)
  • Date: Fri, 03 Aug 2007 08:07:38 +1000

Steven D'Aprano <steve at REMOVE.THIS.cybersource.com.au> writes:

> It's not just "bad syntax" that makes the triple-quote or comment
> trick useful.

Okay. That was the original reason given for refusing suggestions like
"return early from the function" etc. I answered in that context.

> Because you're experimenting, you might end up with ten different
> versions of a function, and not all of them will compile, let alone
> execute correctly.

If a function doesn't compile, I don't understand why you're not
either throwing it away or fixing it.

As for multiple versions? That's what version control is for. With
client-only, distributed VCSes like Bazaar and Mercurial (both written
in Python) you don't even have to do anything other than install the
software to begin using it.

There's no reason not to be using a version control system any time
you're coding ? even (especially!) while "just experimenting".

> It's handy to be able to comment them out and reload() the file

Why not simply fix them and reload() instead? Why keep something
inside the module that doesn't work, and indeed has just been proven
not to work? (If the only reason is "because I might need it later",
again, that's what a VCS is for.)

-- 
 \        "I'd take the awe of understanding over the awe of ignorance |
  `\                                       any day."  -- Douglas Adams |
_o__)                                                                  |
Ben Finney