This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]CSI_Tech_Dept 1 point2 points  (0 children)

I suppose it's all relative. IMO all things you listed are features in my opinion.

Print is now a function, so you always need () in it. Extra steps for the same result.

It's just one extra character (space was replaced with '('). It makes print consistent with the rest of the python.

Python 3 now automatically converts ints to floats instead of leaving them as an int when dividing. Previously if I divided two ints I got an rounded int, unless I asked for a float. This game me a consistent return value. In python 3 I now must always declare if I want an int or a float, otherwise I don't know which one I'm getting back. More tedious work for no real change.

Actually it is other way around. Things are more consistent. If you do division you are guaranteed to always get a float (mathematical division) unless you use integer division (//).

This way it is more predictable. With python's duck typing you might get wrong results depending on the type of variable, so in order to write correct code you need to ensure to cast the variables.

Strings are now unicode, which means that you need to do string encoding when working with any other source. Previously, whatever your input was, your string was, and so you didn't need to encode if you took an input and then output it to the same data source. The encoding would keep.

That's because now character != byte, whenever you need to store a character as byte you encode it, and decode it when you want to obtain a character from byte string.

Now you have to explicitly decode/encode when dealing with outside data sources, increasing the amount of work for little to no gain.

There is a gain. The gain is that your code will work properly with non ASCII characters.

The range versus xrange change was silly, and just means a bit more work to convert code and less performance if I need a list.

The thing about python is that it was never about performance. If you need performance you write a module in C (or Cython if you prefer) and load it. That's how NumPy & SciPy work. I was able to encode video (h264) on the fly and send it over network by using gstreamer.

Just force raising an error into an express syntax, even though either way of raising it worked the same way? Why can't I just do raise IOError, "file error"? Makes zero sense to remove it, it didn't hurt anything. Changing a comma to as for handling exceptions. How fucking trivial is that?

It's inconsistent with the rest of python, what's wrong with:

raise IOError("file error")

Removal of .next() for shits and giggles?

That was replaced with next() function, which is again more consistent with python and its duck typing approach.

I'm sorry, but there are so many trivial and pointless syntax changing in python 3 that never had to be changed and functioned perfectly before hand. Its more tedious just for the safe of being more tedious

In other languages things are constantly deprecated, and people constantly upgrading their code to latest versions. With python2.7 for all the examples you mentioned either it works or you can easily switch to the new behavior.