«

On Mon, 28 Jul 2003, Shane Hathaway wrote:

> As a bonus, I find that print statements do not rightfully belong in
> most of the software I write. Therefore I can happily add print
> statements anywhere for debugging purposes, knowing that removing them
> later is perfectly safe.

As an extra bonus, if you do this you can remove them all automatically:

def print(*args):
for arg in args:
print arg,
return True


assert print("Well, well, well", "said", "he")

To erase all tracks of the debugging statements at runtime, just use the
-O flag. I tend to use a variant of this for debugging systems that have
"complex" concurrency to make it simpler to track "who" "said" what.

I know you can do the same with just grep if you use print - but you have
to ensure that your debugging statements don't span multiple lines.


Michael.

"Michael Sparks" <> wrote in message
news:mailman.1059409013.10134.python-...
> On Mon, 28 Jul 2003, Shane Hathaway wrote:
>
> > As a bonus, I find that print statements do not rightfully belong in
> > most of the software I write. Therefore I can happily add print
> > statements anywhere for debugging purposes, knowing that removing them
> > later is perfectly safe.

Yup. AFIC, the print statement is only for debugging, and it's quite
effective for that purpose.

> As an extra bonus, if you do this you can remove them all automatically:
>
> def print(*args):
> for arg in args:
> print arg,
> return True
>
>
> assert print("Well, well, well", "said", "he")
>
> To erase all tracks of the debugging statements at runtime, just use the
> -O flag. I tend to use a variant of this for debugging systems that have
> "complex" concurrency to make it simpler to track "who" "said" what.
>
> I know you can do the same with just grep if you use print - but you have
> to ensure that your debugging statements don't span multiple lines.

Which mine do, quite frequently. By the time you get this far,
you've pretty much got a logging system.

Another interesting arguement for the print statement versus
online debuggers is that, if you practice test driven development,
you gradually lose your facility with the debugger - you use it
so seldom.

John Roth
>
>
> Michael.
>
>

On Mon, 28 Jul 2003 13:23:43 +0000, John Roth wrote:

>
> Yup. AFIC, the print statement is only for debugging, and it's quite
> effective for that purpose.
>

I would guess it's pretty good for teaching programming, too. Seeing

print "Hello world"

is more welcoming than even:

import sys
sys.stdout.write("Hello world\n")

I use:

if __debug__: print "bla, bla, bla..."

And I was just wondering if it's legal to define a "print" function...
isn't print a keyword ?

Pedro> And I was just wondering if it's legal to define a "print"
Pedro> function... isn't print a keyword ?

You're right. You'd need it to be Print or print_ or something similar.

Skip

(Pedro Werneck) wrote in message news:<. com>...
> I use:
>
> if __debug__: print "bla, bla, bla..."
>
> And I was just wondering if it's legal to define a "print" function...
> isn't print a keyword ?

Instead of defining "print" you can assign a custom class to
sys.stdout. Then all the print statements get automagically
redirected.:

if __debug__:
class newStdout:
def write(self,string):
print string
else:
class newStdout:
def write(self,string):
pass

import sys
sys.stdout = newStdout()

It would be nice if you could give a name
to your email address, i.e if you are not
that paranoid as it seems.

~Anand

(logistix at cathoderaymission.net) wrote in message news:<. com>...
> (Pedro Werneck) wrote in message news:<. com>...
> > I use:
> >
> > if __debug__: print "bla, bla, bla..."
> >
> > And I was just wondering if it's legal to define a "print" function...
> > isn't print a keyword ?
>
> Instead of defining "print" you can assign a custom class to
> sys.stdout. Then all the print statements get automagically
> redirected.:
>
> if __debug__:
> class newStdout:
> def write(self,string):
> print string
> else:
> class newStdout:
> def write(self,string):
> pass
>
> import sys
> sys.stdout = newStdout()

In article < >,
Anand Pillai <> wrote:
>
>It would be nice if you could give a name to your email address, i.e if
>you are not that paranoid as it seems.

Top-posting is more annoying IMO. I remember e-mail addresses better
than names, anyway.
--
Aahz () <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

That's a nice idea... I done something similar to redirect print
statements to a text widget in a debug environment I am developing...
but my point here is not to redirect output... I think a statement
that simply does: if __debug__: print "..." would ease
debugging... that: def _print(*args): for arg in args:
print arg return True assert _print("bla", "bla bla") is very
interesting but it would be nice to have a standard way to do that...
a new statement, a modified assert statement or a new builtin... I am
not that experienced on python, so I don't know... what do you Python
gurus think ? Is this worth the effort ?

Aahz wrote:

> Top-posting is more annoying IMO.

Aahz,

I know that you champion the cause of stopping people from
top-posting, and I agree that bottom-posting a good thing.

However, there is a down side: it makes it impossible to get
meaningful summaries of a posters posting history on Google Groups.
For example, here is your own history of posts:-

http://groups.google.com/groups?hl=e...z%40panix.com+

As you can see if you view that history, the summaries represented do
not contain what you actually said or wrote: they contain what other
people said, that you replied to. While this is generally not a
problem, you might find occasionally that it will appear, at the
summary level, that you said something that it is the precise opposite
of what you actually think or feel.

I don't have a solution, but I thought I would point out the problem.

regards,

--
alan kennedy
-----------------------------------------------------
check http headers here: http://xhaus.com/headers
email alan: http://xhaus.com/mailto/alan