Journal morgan_greywolf's Journal: Python 3.0 Review 3
(Also titled, 'Python 3.0: the good, the bad, and the ugly)
Here's my review of the changes in Python 3.0. I've been writing stuff in Python since 2.1 or so, and I tend to like Python's 'new' object system. I hate Lisp and I hate functional programming(*), so that makes me a bit of an oddball in the Python community I guess.
Good: The print statement has been replaced with a print() function, with keyword arguments to replace most of the special syntax of the old print statement (PEP 3105).
Maybe I just spent too many years writing C and Borland Pascal/Delphi code, but when I first started coding in Python, I often made the mistake of writing
print('Hello world')
rather than
print 'Hello world'
Now it's the way it should have been all along. Things are more consistent this way.
Additionally, the sep= keyword argument makes life easier. No longer do you have put the separator repeatedly in your quoted string especially if the separator is not a space!
Bad: The dict methods dict.keys(), dict.items() and dict.values() return "views" instead of lists. For example, this no longer works: k = d.keys(); k.sort(). Use k = sorted(d) instead (this works in Python 2.5 too and is just as efficient).
Why did they change this? I make use of dict.keys() rather a lot. *sniff*
Ugly: range() now behaves like xrange() used to behave, except it works with values of arbitrary size. The latter no longer exists.
It seems like they changed this just to be pedantic. Tell me what the improvement is in making range work like xrange and then removing xrange? Why not just keep both?
Bad: The ordering comparison operators (=, >) raise a TypeError exception when the operands don't have a meaningful natural ordering. Thus, expressions like 1 None or len are no longer valid, and e.g. None raises TypeError instead of returning False. A corollary is that sorting a heterogeneous list no longer makes sense - all the elements must be comparable to each other. Note that this does not apply to the == and != operators: objects of different incomparable types always compare unequal to each other.
Some of my favorite stupid Python tricks rely on the fact 'None' in fact does not raise a TypeError and instead causes an expression to return False. Oh well. Guess I'll be using a ton more exceptions.
Ugly: PEP 0237: Essentially, long renamed to int. That is, there is only one built-in integral type, named int; but it behaves mostly like the old long type.
So if you're going to only have one type, instead of no longer accepting 'long', make 'long' an alias for 'int'. Now that wasn't too hard was it?
Good: PEP 0238: An expression like 1/2 returns a float
About fscking time. Damn, you have no idea how many times I looked at expressions like 1/2 and went "Huh? Whadya mean 0?"
Good, Bad and Ugly: Python 3.0 uses the concepts of text and (binary) data instead of Unicode strings and 8-bit strings. All text is Unicode; however encoded Unicode is represented as binary data. The type used to hold text is str, the type used to hold data is bytes. The biggest difference with the 2.x situation is that any attempt to mix text and data in Python 3.0 raises TypeError, whereas if you were to mix Unicode and 8-bit strings in Python 2.x, it would work if the 8-bit string happened to contain only 7-bit (ASCII) bytes, but you would get UnicodeDecodeError if it contained non-ASCII values. This value-specific behavior has caused numerous sad faces over the years.
I agree, but changing it is going to be a real pain for a WHOLE lot of programs. Specifically 2to3 and -3 isn't able to fix a lot of these differences.
Meh: PEP 3107: Function argument and return value annotations. This provides a standardized way of annotating a function's parameters and return value. There are no semantics attached to such annotations except that they can be introspected at runtime using the __annotations__ attribute. The intent is to encourage experimentation through metaclasses, decorators or frameworks.
Okay, but we're already doing this throw DOC strings. Why change it now?
Good: PEP 3102: Keyword-only arguments. Named parameters occurring after *args in the parameter list must be specified using keyword syntax in the call. You can also use a bare * in the parameter list to indicate that you don't accept a variable-length argument list, but you do have keyword-only arguments.
Okay, this is more consistent with how arguments work...
Meh: PEP 3104: nonlocal statement. Using nonlocal x you can now assign directly to a variable in an outer (but non-global) scope. nonlocal is a new reserved word.
If you're going to explicitly change the scope of a variable, you might as well make it global, huh? Some people are just too pedantical.
Good: PEP 3132: Extended Iterable Unpacking. You can now write things like a, b, *rest = some_sequence. And even *rest, a = stuff. The rest object is always a (possibly empty) list; the right-hand side may be any iterable. Example:
(a, *rest, b) = range(5)
This sets a to 0, b to 4, and *rest to [1, 2, 3].
Oh, goody! No more writing a, b, dummy1, dummy2 = function()
Good: Dictionary comprehensions: {k: v for k, v in stuff} means the same thing as dict(stuff) but is more flexible. (This is PEP 0274 vindicated.
and
Set literals, e.g. {1, 2}. Note that {} is an empty dictionary; use set() for an empty set. Set comprehensions are also supported; e.g., {x for x in stuff} means the same thing as set(stuff) but is more flexible.
I always thought there should be a way to do this...
Ugly: New octal literals, e.g. 0o720 (already in 2.6). The old octal literals (0720) are gone.
But the old way was consistent with Unix...
Good: Change from except exc, var to except exc as var. See PEP 3110.
I hated the old way. To me, there isn't a lot of difference between except (exc, exc): and except exc, var: so I was always getting confused.
Ugly: PEP 3113: Tuple parameter unpacking removed. You can no longer write def foo(a, (b, c)):
Why? I mean, I read the PEP and understand the introspection issues, but um, if you don't like it, just don't use it.
This and the rest of the removed syntax: These seem like silly, pedantic political issues.
Bad: Library changes: why change the names of libraries without leaving aliases to the old names? You're just being pedantical again. Stop it.
Ugly: String template changes and the '%' string operator
I never saw anything wrong with the '%' operator.
The Rest
'file' is already an alias for 'open'. Again, why rename something in a destructive way? What's wrong with just leaving the damn alias there?
(*) More accurately, I hate programming purism. I tend to mix and match various techniques and metaphors and 'use what works' rather than get all uppity about things like how a function should never modify a global variable. Sometimes that's just the best way to do it.
Some good and some bad (Score:2)
Looking at the list myself the other day I just sat back and thought "woah."
The new string stuff is going to make maintenance a real pain, between the new formatting and the new Unicode handling. The octal thing is also weird, not quite sure about that syntax myself either.
A lot of the changes I'm pretty happy about, and I see how the new formatting stuff is more flexible, but honestly, I can see it getting ugly.
Things like "User {0{1{4}}} wrote this" are now possible and hideous.
Re: (Score:1)
I dunno about the string formatting. There's already the Template class in the string module:
import string
s=string.Template('User $user ($uid) wrote this')
s.substitute(user="MikeBabcock", uid=65886, email='mtb-slashdot@mikebabcock.ca')
print s
what's wrong with that? Why do we need yet another way to do template strings?
Re: (Score:2)
The problem we have of course is the Guido "one right way ..." thinking, which means having two ways to format strings was bad, and they should all be merged into one way.
Unfortunately, string formatting has an awful lot of issues that I don't believe should all be dealt with in a single syntax.
And I'll miss "%(name)s" to be honest.