Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: I strongly dislike Python 3

Reply
Thread Tools

Re: I strongly dislike Python 3

 
 
Thomas Jollans
Guest
Posts: n/a
 
      06-26-2010
On 06/26/2010 05:59 PM, Stefan Reich wrote:
> Hi there.
>
> Let me preface this by saying that I am a fan of Python. I use it
> regularly and I like it a lot.
>
> That is, I am using and liking Python 2.6.
>
> I don't like Python 3.
>
> I won't comment on the advanced stuff that is changed in Python 3, as I
> haven't look into that.
>
> My complaint is about changing the syntax of "print".
>
> This has probably been talked about on your lists, but I wasn't part of
> that discussion. And I think that everyone has a right to bring up a
> subject at any time if it is still important. And I believe it is
> because Python 3 is out there and it poses a real problem.
>
> The main problem is that Python 3 is incompatible with almost all
> scripts written for Python 2 (if they use print). And it gets worse:
> Python 3 scripts are incompatible with Python 2! (If they use print
> variants, like writing to a file.)
>
> Thus the world of Python scripts is split in two incompatible factions.
> All for simplifying the syntax of one statement. That, to me, is pure
> insanity.
>
> Here's the advantages:
>
> -Some arcane stuff like redefining "print" in a module (which 99% of
> users will never do) allegedly gets easier.


s/easier/possible/

> -Any more?


Ever had to write this:

def print_wrapper(s):
print s

in Python 2.x? Well, probably not, but I have.

There is no reason for print not being a function. Also, do you use
print *that* much? Really?

>
> 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.

> -Python world split in half. There is now a Python 2 world and a Python
> 3 world, both incompatible with each other.

Sort-of true:
with a few __future__ statements and a little care, scripts can be
portable across 2.6/2.7--3.x. Tools like 2to3 are meant to make the
transition of an old package as painless as possible, and it's not like
there are no packages that support both versions, from one codebase!

I'm looking forward to 3to2 though - allowing me to support Python 2
from Python 3 code. Sounds nice, doesn't it?

> -Libraries written for Python 2 cannot be mixed with libraries written
> for Python 3.


No, but libraries can and do (partly) / will (mostly) support both at
the same time.

> -Developers have to choose between Python 2 and Python 3 and are bound
> to their choice afterwards.


Not quite true with 3to2 and 2to3

>
> So there are basically no advantages and extremely significant
> disadvantages. The single advantage there is could certainly be achieved
> without breaking all scripts out there.


the print() function is really a minor change. It could be done because
compatibility was broken *anyway*. There are much more important
changes, with much more far-reaching and beneficial consequences for
which I think some pain due to incompatibility is justified:

* old-style classes are gone. Good riddance!
* str is now unicode => unicode is no longer a pain in the a****
* range, map, filter, zip no longer return lists. There are Python 2
equivalents to the new functions, but this is just nicer.

And this is just what springs to mind, there are quite a few other changes.

Anyway, this is the type of pleasant change we've got Python 3 for.
print-as-a-function is just a minor detail correcting an old mistake,
just because the core devs could. And it's not that bad:

print ("string")

without output specification, etc, will work with either version.

>
> Consider Java as a better example: JDK 1.6 still runs and compiles
> everything written for JDK 1.0. That is proper management. Python 3 is,
> I'm sorry to say, an example of unfathomably bad management.


Python 3 was deliberately incompatible. Before 3.0, every new Python
release was backwards compatible. This one single release intentionally
dares to break things in order to fix old mistakes that couldn't have
been fixed otherwise.

>
> To reiterate, I am strongly in disfavor of Python 3 and will stick to
> Python 2, for as least as long as Python 3 breaks my scripts.


I trust you've also read Stephen Hansen's post, which arrived while I
was writing this.

-- Thomas
 
Reply With Quote
 
 
 
 
Lie Ryan
Guest
Posts: n/a
 
      06-26-2010
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.
 
Reply With Quote
 
 
 
 
Ian Kelly
Guest
Posts: n/a
 
      06-26-2010
On Sat, Jun 26, 2010 at 11:38 AM, Lie Ryan <(E-Mail Removed)> wrote:
> 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.


That's true, although a good IDE will automatically produce the
closing bracket when you type the opening bracket.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      06-27-2010
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
 
Reply With Quote
 
Nobody
Guest
Posts: n/a
 
      06-27-2010
On Sat, 26 Jun 2010 18:33:02 +0200, Thomas Jollans wrote:

> * str is now unicode => unicode is no longer a pain in the a****


True. Now byte strings are a pain in the arse.


 
Reply With Quote
 
Stephen Hansen
Guest
Posts: n/a
 
      06-27-2010
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/

 
Reply With Quote
 
Edward A. Falk
Guest
Posts: n/a
 
      06-28-2010
In article <(E-Mail Removed)>,
Thomas Jollans <(E-Mail Removed)> wrote:

>There is no reason for print not being a function. Also, do you use
>print *that* much? Really?


I use it all the time. Who doesn't? What do you use instead?

--
-Ed Falk, http://www.velocityreviews.com/forums/(E-Mail Removed)
http://thespamdiaries.blogspot.com/
 
Reply With Quote
 
Stefan Behnel
Guest
Posts: n/a
 
      06-28-2010
Edward A. Falk, 28.06.2010 16:15:
> In article<(E-Mail Removed)>,
> Thomas Jollans wrote:
>
>> There is no reason for print not being a function. Also, do you use
>> print *that* much? Really?

>
> I use it all the time. Who doesn't? What do you use instead?


Usually file.write() or log.info() and friends. Since you can't really
control the encoding used by print(), nor redirect it locally, it's mostly
useless for anything but debugging and small scripts.

Stefan

 
Reply With Quote
 
Grant Edwards
Guest
Posts: n/a
 
      06-28-2010
On 2010-06-28, Stefan Behnel <(E-Mail Removed)> wrote:
> Edward A. Falk, 28.06.2010 16:15:
>> In article<(E-Mail Removed)>,
>> Thomas Jollans wrote:
>>
>>> There is no reason for print not being a function. Also, do you use
>>> print *that* much? Really?

>>
>> I use it all the time. Who doesn't? What do you use instead?

>
> Usually file.write() or log.info() and friends. Since you can't really
> control the encoding used by print(), nor redirect it locally, it's mostly
> useless for anything but debugging and small scripts.


Maybe it's just me, but I find both debugging and small scripts to be
very useful.

--
Grant Edwards grant.b.edwards Yow! I need to discuss
at BUY-BACK PROVISIONS
gmail.com with at least six studio
SLEAZEBALLS!!
 
Reply With Quote
 
Stephen Hansen
Guest
Posts: n/a
 
      06-28-2010
On 6/28/10 7:15 AM, Edward A. Falk wrote:
> In article<(E-Mail Removed)>,
> Thomas Jollans<(E-Mail Removed)> wrote:
>
>> There is no reason for print not being a function. Also, do you use
>> print *that* much? Really?

>
> I use it all the time. Who doesn't? What do you use instead?


It depends on what my purpose is.

If its debugging output or something similar, I use the logging module
exclusively (the fine grained control it gives me on just how much
information, categorized as such, with which modules, is invaluable to
prevent brain hemorrhage from TMI or confusion from TLI).

Any other use, I basically operate on a file object. I never write to
stdout directly, but instead to some file object passed into some
function-- it may very well be stdout, but the code doesn't know that,
because I half the time I don't have a stdout (or stderr) and half the
time I do.

I *could* use, say, print >>file_object, "..." in those cases, but I
sort of hate that construct kind of a lot. So don't.

--

... Stephen Hansen
... Also: Ixokai
... Mail: me+list/python (AT) ixokai (DOT) io
... Blog: http://meh.ixokai.io/

 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
The real problem with Python 3 - no business case for conversion(was "I strongly dislike Python 3") John Nagle Python 79 07-08-2010 01:44 PM
Re: I strongly dislike Python 3 Terry Reedy Python 43 07-01-2010 02:26 AM
Re: I strongly dislike Python 3 Stefan Reich Python 5 06-27-2010 05:39 PM
Re: I strongly dislike Python 3 Stephen Hansen Python 12 06-27-2010 05:21 PM
I strongly dislike Python 3 Stefan Reich Python 1 06-27-2010 06:59 AM



Advertisments