end of print = lower productivity ?

[cptnwillard]

I want my productivity back.

In Python 2.x, I could easily write things like -- print "f" / print
"add" / print "done" -- to a lot of different places in my code, which
allowed me to find bugs that I could not track otherwise. When I found
out that "f" was not at fault, I could write -- print "g" -- to some
other place... etc, so that a significant part of the time spent
debugging was actually used to write print statements.

Now the print statement disappeared, and I have to write print("f")
instead. These parentheses not only take time to write, they also make
me think twice about using print for debugging purposes. Pressing <
SHIFT > then < ( > then < " > makes the whole process quite a hassle.

I agree with most of the arguments that have been made against using
the print statement to build code, but I did care about the efficient
debugging tool it was.

 

[skip]

:rollseyes:

I hope there was a missing smiley in that post. If a couple extra parens
destroys your debugging productivity I suspect you need a fresh approach to
the task.

 

[Diez B. Roggisch]

I want my productivity back.

In Python 2.x, I could easily write things like -- print "f" / print
"add" / print "done" -- to a lot of different places in my code, which
allowed me to find bugs that I could not track otherwise. When I found
out that "f" was not at fault, I could write -- print "g" -- to some
other place... etc, so that a significant part of the time spent
debugging was actually used to write print statements.

Now the print statement disappeared, and I have to write print("f")
instead. These parentheses not only take time to write, they also make
me think twice about using print for debugging purposes. Pressing <
SHIFT > then < ( > then < " > makes the whole process quite a hassle.

I agree with most of the arguments that have been made against using
the print statement to build code, but I did care about the efficient
debugging tool it was.

I used to use print a lot. Once I found

import pdb; pdb.set_trace()

I massively lost interest in it. And gained *much* more debugging
power/productivity.

Also, using logging instead of print allows you to keep the output producing
statements in your code, while turning them on only if things get fishy.

Diez

 

[peter]

I want my productivity back.

In Python 2.x, I could easily write things like -- print "f" / print
"add" / print "done" -- to a lot of different places in my code, which
allowed me to find bugs that I could not track otherwise. When I found
out that "f" was not at fault, I could write -- print "g" -- to some
other place... etc, so that a significant part of the time spent
debugging was actually used to write print statements.

Now the print statement disappeared, and I have to write print("f")
instead. These parentheses not only take time to write, they also make
me think twice about using print for debugging purposes. Pressing <
SHIFT > then < ( > then < " > makes the whole process quite a hassle.

I agree with most of the arguments that have been made against using
the print statement to build code, but I did care about the efficient
debugging tool it was.

BUT you now can do

Voila, 4 keystrokes saved

 

[cptnwillard]

I used to use print a lot. Once I found

import pdb; pdb.set_trace()

I massively lost interest in it. And gained *much* more debugging
power/productivity.

In some cases, this is not discriminatory enough : there are simply
too many function calls.

 

[cptnwillard]

BUT you now can do


Voila, 4 keystrokes saved

All right. Let's talk about that.

When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.

Contrast this with what one has to go through to catch the SHIFT key,
and then the "(" : move the left hand, press SHIFT, move the right
hand, aim "(", press, miss, press again. Same thing at the end of the
function call.

I know it sounds ridiculous, but it does *impair* my debugging
productivity. Taylor would agree.

 

[Johannes Bauer]

I know it sounds ridiculous

Not only that - it also sounds as if there's spring break in Trollland.

Regards,
Johannes

 

[Tim Chase]

p = print

When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.

Contrast this with what one has to go through to catch the SHIFT key,
and then the "(" : move the left hand, press SHIFT, move the right
hand, aim "(", press, miss, press again. Same thing at the end of the
function call.

I know it sounds ridiculous, but it does *impair* my debugging
productivity. Taylor would agree.

It's not so much "rediculous" as a failure of your editor to
assist you. In Vim (my editor-of-choice), I'd do something like

:iab print print()<left><bs>

and that's the end of it. Or you could be even lazier if you
don't name your variables "p":

:iab p print()<left>

in which case you can just type

p"

and it automatically populates with

print(")

with the cursor after the double-quote ready for you to type the
string's contents. Net gain: 5 characters in old-Python and 6
characters in new-Python ;-)

Any editor environment worth its salt should allow you to do
things like this (insert abreviated text or template text). The
gains made from making "print" a function far outweigh niggling
things that simple editor-tweaks can overcome.

-tkc

 

[George Sakkis]

    >> Now the print statement disappeared, and I have to write print("f")
    >> instead. These parentheses not only take time to write, they also make
    >> me think twice about using print for debugging purposes. Pressing <
    >> SHIFT > then < ( > then < " > makes the whole process quite a hassle.

:rollseyes:

I hope there was a missing smiley in that post.  If a couple extra parens
destroys your debugging productivity I suspect you need a fresh approach to
the task.

Seconded; I thought he's either joking or trolling.

George

 

[Diez B. Roggisch]

In some cases, this is not discriminatory enough : there are simply
too many function calls.

But not to many prints with to few parentheses? You must be joking.

Diez

 

[Arnaud Delobelle]

It's not so much "rediculous" as a failure of your editor to assist
you. In Vim (my editor-of-choice), I'd do something like

:iab print print()<left><bs>

Or if you had chosen Emacs for editing, you could add the following to
your .emacs.

(fset 'py3kprint
[?p ?r ?i ?n ?t ?( ?) left])

(add-hook 'python-mode-hook
'(lambda () (define-key python-mode-map "\C-cp" 'py3kprint)))

When in Python mode, it would bind C-c p to the same.

(Warning - I am not an emacs lisp pro!)

 

[Diez B. Roggisch]

All right. Let's talk about that.

When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.

Contrast this with what one has to go through to catch the SHIFT key,
and then the "(" : move the left hand, press SHIFT, move the right
hand, aim "(", press, miss, press again. Same thing at the end of the
function call.

I know it sounds ridiculous, but it does *impair* my debugging
productivity. Taylor would agree.

If the relative difference between pressing space & ( impairs your
absolute debugging productivity, it pretty much follows that the latter
must be very low for such a minimal overhead to make such a difference.

Try learning touchtype. Might increase your debugging, programming &
writing productivity manyfold.

Diez

 

[Paul Rubin]

All right. Let's talk about that.

When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.

Contrast this with what one has to go through to catch the SHIFT key ...

You could say:

class Printer:
def __isub__(self, x): print(x)
p = Printer()

Then

p-= "foo"

doesn't need use of the shift key. Use of -= instead of - gets rid
of operator precedence issues.

 

[George Sakkis]

You could say:

    class Printer:
        def __isub__(self, x): print(x)
    p = Printer()

Then

    p-= "foo"

doesn't need use of the shift key.  Use of -= instead of - gets rid
of operator precedence issues.

Please don't forget the smileyes when you make such ludicrous
suggestions; if anyone takes them seriously you could be cursed to
maintain his code ;-)

 

[alex23]

I hope there was a missing smiley in that post.  If a couple extra parens
destroys your debugging productivity I suspect you need a fresh approach to
the task.

I'm always inclined to suggest 6 months working in a role that
requires hard manual labour whenever programmers raise the whole
"effort of extra typing" argument.

 

[Barak, Ron]

Hi Pythonistas,

I read diaz's comments with interest, but - in my current configuration, I'm unable to use pdb.

I'm developing on cygwin and use wxPython.
Consequently, I cannot use native cygwin Python, but my Python is actually the Windows XP Python (i.e., /cygdrive/c/Python25/python.exe).
This means that pdb (and, for that matter any Python shell (like IDLE)) gets stuck upon invocation.

I was wandering: is anybody able to use native Python on cygwin, or alternately, to use Windows Python under cygwin in IDLE/pdb ?

Thanks,
Ron.

-----Original Message-----
From: Diez B. Roggisch [mailto:[email protected]]
Sent: Tuesday, November 25, 2008 17:54
To: (e-mail address removed)
Subject: Re: end of print = lower productivity ?

I want my productivity back.

In Python 2.x, I could easily write things like -- print "f" / print
"add" / print "done" -- to a lot of different places in my code, which
...
debugging tool it was.

I used to use print a lot. Once I found

import pdb; pdb.set_trace()

I massively lost interest in it. And gained *much* more debugging power/productivity.

Also, using logging instead of print allows you to keep the output producing statements in your code, while turning them on only if things get fishy.

Diez

 

[Steve Holden]

Hi Pythonistas,

I read diaz's comments with interest, but - in my current configuration, I'm unable to use pdb.

I'm developing on cygwin and use wxPython.
Consequently, I cannot use native cygwin Python, but my Python is actually the Windows XP Python (i.e., /cygdrive/c/Python25/python.exe).
This means that pdb (and, for that matter any Python shell (like IDLE)) gets stuck upon invocation.

I was wandering: is anybody able to use native Python on cygwin, or alternately, to use Windows Python under cygwin in IDLE/pdb ?

That's a pretty crazy combination, which is more or less guaranteed to
cause problems. If you are using the standard Windows Python under
cygwin you will find it gives you issues with filenames, for example.
You won't be able to access them using the Cygwin names, so why not just
run the standard Windows Python under the Windows command line?

You can, of course, continue to use Cygwin for editing and command-line
Python. But you seem to be asking for trouble unnecessarily by running
Windows Python under Cygwin.

regards
Steve

 

[Tim Roberts]

When I write "print", it is both effortless and instantaneous : my
hands do not move, a wave goes through my fingers, it all happens in a
tenth of a second.

Contrast this with what one has to go through to catch the SHIFT key,
and then the "(" : move the left hand, press SHIFT, move the right
hand, aim "(", press, miss, press again. Same thing at the end of the
function call.

I know it sounds ridiculous, but it does *impair* my debugging
productivity. Taylor would agree.

Although I'm not sure I will have the same issue with "print", I can
sympathize with what you are saying. I spend virtually all of my time in a
command line. As a Windows driver guy, I work a lot in the
\windows\system32\drivers directory. I got used to typing that as
\wi <tab> \syst <tab><tab> \dr <tab>
letting tab completion fill it in.

Well, in Windows XP, Microsoft introduced a new utility in "system32"
called "driverquery.exe". Because it is alphabetically before "drivers",
that now appears.

Now, you would think that this is just a trivially minor inconvenience, but
to this day, 6 years after XP, I still find myself looking at
"driverquery.exe" instead of the "drivers" directory.

 

[Lie]

It's not so much "rediculous" as a failure of your editor to
assist you.  In Vim (my editor-of-choice), I'd do something like

   :iab print print()<left><bs>

seriously, I don't think anyone in Windows uses vim and there are
quite a lot of Windows Python user. Since when is python becoming
exclusive community for Linux/Unix-like/Cygwin users that Windows
users who have nothing but Notepad is put aside.

Python has long "advertised" itself as a language that is better off
without an IDE, i.e. encourages plain text editor over IDE. By
introducing print-as-function, doing a simple print does requires you
to use more shift-key than before, but having to configure your text
editor to substitute print to print() is just as nice and disgusting
as using an IDE, I, for instance, hates when my text editors tries to
be smarter than me. A practical example is Scribes Text Editor, which
"features" auto-pair completion, which drives me mad for it trying to
close tags where I only want open tags. I never used that "smart"
editor again ever since (even if I know I can turn that off easily).

and that's the end of it.  Or you could be even lazier if you
don't name your variables "p":

   :iab p print()<left>

in which case you can just type

   p"

and it automatically populates with

   print(")

with the cursor after the double-quote ready for you to type the
string's contents.  Net gain:  5 characters in old-Python and 6
characters in new-Python ;-)

Is that supposed to be a joke?

Any editor environment worth its salt should allow you to do
things like this (insert abreviated text or template text).  The
gains made from making "print" a function far outweigh niggling
things that simple editor-tweaks can overcome.

-tkc

In general, I don't hate the print-as-function for having to type open
and closing parens. I am, in fact, indifferent to that change. But
I've got to say that I HATE "smart-ass" (read: less than stupid)
editors. I'm sure when my dislike for "smart" editors is coupled with
someone's else's hate for print-as-function, s/he would consider end
of print-as-statement as lowering productivity.

 

[Lie]

(e-mail address removed) schrieb:








If the relative difference between pressing space & ( impairs your
absolute debugging productivity, it pretty much follows that the latter
must be very low for such a minimal overhead to make such a difference.

Try learning touchtype. Might increase your debugging, programming &
writing productivity manyfold.

It doesn't work. I'm already a touch typist. But my touch typing
rhythm is disturbed when there is a pair characters, as my internal
pair-completion would do something like this: ()<left>""<left>string.
I am a perfectionists, I hate having unclosed pair characters (though
I hate editors that auto-complete pairs even more, as it always
mistook my attempt to place open tags that already have closing tags
as need to be auto-closed). I am also a control-freak, as you might
have guessed. And I don't like patchwork, e.g. correcting the editor's
mistaken attempt, I'd rather do the whole thing manually than having
it done automatically but sometimes need manual intervention, if
something is automatized, do it completely, else don't.