I strongly dislike Python 3
in [Python]
|
From: Paul Rubin on 26 Jun 2010 20:53 Terry Reedy <tjreedy(a)udel.edu> writes: > To make your life easier, and even save keystrokes:.. >>>> def tp(*args): print(args) # tuple print Too much to remember, makes my life harder. If I were that organized, I'd figure out how to use the logging module. ;)
From: Steven D'Aprano on 26 Jun 2010 21:06 On Sat, 26 Jun 2010 17:02:32 -0700, Paul Rubin wrote: > Terry Reedy <tjreedy(a)udel.edu> writes: >> Having completely switched from 'printf(' to 'print ', I have had a bit >> of a problem switching back to 'print('. It is my single largest source >> of typos. But a decent system that puts me at the site of syntax errors >> alleviates this. Logic bugs are a much bigger problem. > > I tend to print a lot of tracing messages in my programs, in the form > > print (x, y, z) > > expecting to print the tuple (x,y,z) in a form that I can read back into > an analysis program. That's going to break without throwing any syntax > errors if I ever switch to Python 3. Apart from retraining yourself to add the extra parentheses, the easy fix is to put this at the top of your module: _pr = print def print(*args, **kwargs): _pr(args, **kwargs) But I'm sure you know this :) I didn't notice this level of angst when Python made equally significant changes going from 1.5 to 2.0... admittedly Python 1.5 code would work unchanged in 2.0, but the 2.x series introduced MUCH bigger additions to Python than anything 3.0 and 3.1 have added, and anyone taking advantage of those changes is implicitly writing code which is not backwards compatible. To all the Python 3.x haters -- spend a few minutes installing Python 1.5 and playing around with it and see how much it is missing: no integrated help, no unicode, no __futures__, no generators, no iterators apart from xrange and xreadlines, no properties... See how long you last before you (metaphorically) throw it across the room in disgust. That's what you'll be like for Python 2.x in a decade. I realise it's hard to see that now, when so many major libraries haven't been ported yet and the unicode vs. bytes situation is still unclean, but 3.x is the future of Python, and a good thing it is too. -- Steven
From: Steven D'Aprano on 26 Jun 2010 21:24 On Sun, 27 Jun 2010 03:38:30 +1000, Lie Ryan wrote: > On 06/27/10 02:33, Thomas Jollans wrote: >>> > >>> > And here's the disadvantages: >>> > >>> > -The Python 3 syntax actually requires more keystrokes. >> Typically ONE extra character: the closing bracket. The opening bracket >> can replace the whitespace previously required. > > What really matters is not the number of extra characters, but the > number of keystrokes. On a typical keyboard, producing a '(' requires 2 > keystrokes (Shift + 9) and another 2 keystrokes for ')' (Shift + 0). > Also, spacebar is a key in the home position of the thumb, while 9 and 0 > are on the top row of the weaker fingers (ring and little finger). > > All in all, the new syntax requires 4 keystrokes, none of which are home > keys; compared with old syntax which requires 1 keystroke in thumb's > home position. > > Producing print function takes a little bit more effort than producing a > print statement. Worrying about this sort of micro-optimisation is hardly a productive use of anyone's time. Nobody here is complaining that typing len(x) requires three extra keystrokes compared to len x and therefore Python should make len a statement. Why should print be any different? (1) The main use-cases for print are quick (and usually dirty) scripts, interactive use, and as a debugging aid. So this change isn't going to effect many large code bases, but mostly small scripts that can be fairly easily changed by hand. (2) With all the other function calls in Python code, this is a trivial increase in typing effort. (3) If you really care that much, you can re-map your keyboard to make the parentheses require only a single key press. Or use an editor that automatically inserts the closing parenthesis. (4) Despite what the OP says, the ability to overload print is not a small feature, it is a major win. My scripts are filled with ugly functions pr(), print_() or prnt(), depending on how I was feeling at the time, none of which *quite* match the behaviour of the print statement correctly. The ability to redefine print in Python 3 is, to me, the Killer App for simple scripting: _print = print def print(*args, **kwargs): # Untested if "verbosity" not in kwargs: kwargs["verbosity"] = VERBOSITY if kwargs["verbosity"]: del kwargs["verbosity"] _print(*args, **kwargs) # You want logging too? Add it here. The ability to make print() understand your script's --verbose flag is, in my mind, the most underrated plus for Python 3. -- Steven
From: Steven D'Aprano on 26 Jun 2010 21:32 On Sat, 26 Jun 2010 13:41:30 -0500, John Bokma wrote: >> Done means finished: complete, not going to be advanced any further. > > I think that's not true. If enough people want to support Python 2 it > might be possible to advance Python 2. I can't see that happening. In my experience those who are the most vehemently against Python 3 are the least likely to do anything about it apart from bad-mouthing it. The chances of them actually taking on responsibility for maintaining Python 2.7 is somewhere between slim and none. -- Steven
From: Stephen Hansen on 26 Jun 2010 21:42
On 6/26/10 6:24 PM, Steven D'Aprano wrote: > On Sun, 27 Jun 2010 03:38:30 +1000, Lie Ryan wrote: >> All in all, the new syntax requires 4 keystrokes, none of which are home >> keys; compared with old syntax which requires 1 keystroke in thumb's >> home position. >> >> Producing print function takes a little bit more effort than producing a >> print statement. > > > Worrying about this sort of micro-optimisation is hardly a productive use > of anyone's time. Nobody here is complaining that typing len(x) requires > three extra keystrokes compared to len x and therefore Python should make > len a statement. Why should print be any different? I swear I've heard a "it should be x.len" argument once where saving a character was a key selling point (in addition to some vague OOP-handwaving thing which indicated that it would also be Clearly The Correct Thing To Do Anyways). Just because no one is complaining about that *right now* doesn't mean they won't -- and now you had to go and remind them of it. :) Just saying. As for the keystroke count -- pssh, my editor has me do 'print<tab>' and it not only puts both the open and closing parens, but also moves my cursor in between them. That's exactly the same effort as old-print! :) > (1) The main use-cases for print are quick (and usually dirty) scripts, > interactive use, and as a debugging aid. So this change isn't going to > effect many large code bases, but mostly small scripts that can be fairly > easily changed by hand. I got called (essentially) elitist and condescending for thinking that was basically the only places anyone really used print. Careful there. :) > (4) Despite what the OP says, the ability to overload print is not a > small feature, it is a major win. My scripts are filled with ugly > functions pr(), print_() or prnt(), depending on how I was feeling at the > time, none of which *quite* match the behaviour of the print statement > correctly. The ability to redefine print in Python 3 is, to me, the > Killer App for simple scripting: > [snip] > > The ability to make print() understand your script's --verbose flag is, > in my mind, the most underrated plus for Python 3. Interestingly enough, the reason I never use print is because its a statement and is inflexible in this regard. If it were always a function, I imagine my opinion of print's usefulness would be very different today: I too have a number of slightly unique little pseudo-print functions scattered throughout my codebase. That, and various hacks replacing sys.stdout. The rigidness of the statements behavior (and therefore inability to bend it to my whim) is why I always just equated it with temporary or quick and dirty usage. -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/ |