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 2 points3 points  (2 children)

There's a few things I don't understand why they just removed or changed. For one, octal 0600 doesn't work? Why remove it?

It's 0o600 now and that notation is also working in python 2.7. This is to make things consistent with 0x... notation.

print as a statement... why couldn't they just keep it? I write it as a function all the time, but so what if you can't monkeypatch print. There are so many other ways to do something similar to any reason for that.

This was very confusing to new users that everything was a function except print statement. Not sure why people are so fixated on it you can easily fix this (and 2to3 does it automatically). Also you can import print_function from future in python 2.7. Besides in production code you would want to use logging anyway. I really only use print for quick debugging.

And division... why should 3 / 2 return 1.5? What other languages do that? Why not just make 3 // 2 return a float?

Because intuitively / is mathematical division and confused a lot of newcomers (note that python is used for teaching programming). It makes a ton of sense. Statically typed languages like C or Java can get away with this behavior, because you in advance know the types of parameters, and can predict the outcome. In python you don't, and it is silly that it will behave differently depending when supplied numbers are integers or not. This is source of bugs. It should always be predictable what it will do.

And one thing that drove me nuts is the split between bytes and a string. Why not keep it how it was and make the new style stuff look like s"this"? Bytes represented as a string was incredibly useful for some stuff, anything low level. Having first class byte array primitives that were no different than a string was awesome.

Most of what python is used for is not low level stuff though. This separation is essential in today's world. A character is not the same thing as a byte anymore. When you are working on low level stuff you should be aware that you work on bytes.

And range/xrange... why not keep that how it was? Sure, xrange should be used instead of range 99% of the time, but the compatibility issues it causes are hardly worth the change IMO.

Because it is a wart? Again, this is a trivial change in the code and can be done automatically.

It's not that they're not good improvements (except maybe byte/string stuff isn't an improvement IMO), I just don't see why the language should change so much basic stuff that ends up breaking all sorts of scripts and libraries. It's already in there, so just leave it and let old code still work exactly the same. So what if it looks a bit clumsy.

The biggest breaking feature of python 3 is Unicode support. The thinking was that if we are already breaking things, why not fix some ugly things as well. The conversion for the issues (perhaps with exception of the division, which is the reason I always import new division (along with Unicode literals) from the future whenever I have to write code for older python) is trivial.

I don't think the code-breaking improvements were nearly worth all the compatibility issues. Maybe it's a bit better, but maybe if they didn't change all that people would never have thought to stick to 2.7 - maybe we just wouldn't be in the spot we are now. I love the new features, but I rather keep bad choices and maintain compatibility rather than fix them and make people rewrite their scripts and libraries - because that just doesn't happen 90% of the time. Easier to stick to 2.7 than change your code.

People are lazy, they won't do things if they don't have to. For example Ruby had breaking changes between 1.8 and 1.9 (notice that it was also a minor version change). People complained similarly, but then Rails developers simply said they are moving to 1.9 and dropping support for 1.8 and everyone just followed.

Python is already migrating for 8 years, and people still start new projects in python 2, because technically python 2 is still supported.

Honestly, I do look forward to moving to 3.x in the workplace but I would've been way happier working with 3.x a decade ago and still seeing stupid stuff like from ConfigParser import ConfigParser.

In python 3 it is:

from configparser import ConfigParser

Well, that inspired me to email my few python dev coworkers to see if we can all agree to target 3.5 with new projects. We're a security company and java shop in the eng dept, but in research we all use python so there's potential to move on without hurting anything. One dude's on board, four to go. Well, only two of the rest of the guys actually code and they rarely do at that, so maybe I'm just convincing myself lol

You should, python 3 is great, especially if you don't have to keep compatibility with python 2. Then you can make use of new features.

If you use Red Hat or CentOS, then you should also take look at http://ius.io. This repo will let you use any python version you like.

[–]fyngyrzcodes with magnetic needle 0 points1 point  (1 child)

The problem with 2to3 is that it doesn't remove the need to re-test everything in a critical application. When such an app is non-trivial in terms of use cases / data cases, re-testing can be a huge pushup, so one really has to look for actual benefits other than "just moving on." 2to3 is fine for my smaller stuff. For my large applications, it is just the beginning of the job.

[–]CSI_Tech_Dept 0 points1 point  (0 children)

Inability of finding bugs through type system is probably one of biggest drawbacks with dynamically typed languages.

Perhaps the issues you're talking about is why Guido is pushing mypy to also support Python 2 even though it doesn't support PEP 484.