PyWart: The problem with "print"

[Rick Johnson]

On Jun 2, 12:20 pm, Chris Angelico <ros... at gmail.com> wrote:
> On Mon, Jun 3, 2013 at 3:04 AM, Rick Johnson
> >  * Woefully inadequate because: Switching on or off the debug
> >    messages is only valid in the current module that the
> >    function was imported. What if you want to kill all
> >    debugprint messages EVERYWHERE? Do you really want to edit
> >    "debug = BOOLEAN" in every source file OR do something
> >    stupid like import debugprint and edit the DEBUG constant
> >    OR even dumber, edit the debugprint source code? GAWD NO!
> Easy fix to this one. Instead of copying and pasting debugprint into
> everything, have it in a module and import it everywhere. Then the
> debug flag will be common to them all.

Ignoring the fact that you have "import everywhere", what if you want
to stop ALL debug messages? If you "import everywhere" to get them,
you then have to "edit everywhere" to stop them.

> Oh, and you probably want to add **kwargs to debugprint, because the
> print function does a lot more than sys.stdout.write does:

The kwargs to print are not germane to the issue, however noobs may be
watching so glad you pointed that one out.

> [...]
> py> timeit.timeit('debugprint("asdf") [...]
> 0.5838018519113444
>
> That's roughly half a second for a million calls to debugprint().
> That's a 580ns cost per call. Rather than fiddle with the language,
> I'd rather just take this cost.

I never purposely inject ANY superfluous cycles in my code except in
the case of testing or development. To me it's about professionalism.
Let's consider a thought exercise shall we?

  Imagine your an auto mechanic. You customer brings in his
  car and asks you to make some repairs. You make the
  repairs but you also adjust the air/fuel ratio to run
  "rich" (meaning the vehicle will get less MPG). Do you
  still pat yourself on the back and consider you've done a
  professional job?

I would not! However, you're doing the same thing as the mechanic when
your code executes superflouos calls and burns cycles for no other
reason than pure laziness. CPU's are not immortal you know, they have
a lifetime. Maybe you don't care about destroying someone's CPU,
however, i do!

I just wonder how many of your "creations" (aka: monstrosities!) are
burning cycles this very minute!

> [...]
> So you can eliminate part of the cost there, if it matters to you. If
> a half-microsecond cost is going to be significant to you, you
> probably should be looking at improving other areas, maybe using
> ctypes/cython, or possibly playing with the new preprocessor tricks
> that have been being discussed recently. There's really no need to
> change the language to solve one specific instance of this "problem".

That's like suggesting to the poor fella who's MPG is suffering
(because of your incompetent adjustments!) to buy fuel additives to
compensate for the loss of MPG. Why should he incur costs because you
are incompetent?