5 ms·

I never understood what kind of changes Guido made from 2.7 to 3.0 that kept everyone off.

• lqdc13 11y ago
  The backwards incompatible kind.
• stdbrouw 11y ago
  Hardly any changes at all, and the things that did change didn't actually make a clear difference in productivity or the clarity of your code. The ability to make breaking changes wasn't really used to improve the language, maybe except for unicode handling – no new syntax (would've loved functions-as-blocks myself), no getting rid of old crufty syntax, nada.
  • toyg 11y ago
    > things that did change didn't actually make a clear difference in [...] the clarity of your code print "%s remember to %s in %s if %s but never %s" % (some_random_tuple) vs print("{when} remember {what} in {room} if {condition} but never {dont}".format(* * dict_with_explicit_keys)) A bit verbose but much clearer and future-proof.
    • icebraining 11y ago
      But you can already do that in Python 2.7.
    • mmarx 11y ago
      That's an unfair comparison, however, print "%(when)s remember to %(what)s in %(room)s but never %(dont)s" % dict_with_explicit_keys was supported back in at least 2.4.
    • Ded7xSEoPKYNsDd 11y ago
      Python 2.7 supports string.format and Python 3 supports % formatting. The only actual difference in that example is that print became a function in Python 3, requiring some additional parentheses. (Something that can be mechanically translated without much hassle.)
      • GFK_of_xmaspast 11y ago
        Wasn't the % formatting missing from early versions of python3?
• jvdh 11y ago
  There are both syntactic as well as behavioural changes. A simple example is the print statement, in Python 2 you could do: print "Hello World!" Whereas in Python 3 you have to do: print("Hello World!") Now obviously, you can easily change this programmatically. Things get harder when you use more advanced print statements, for example adding a "," at the end to prevent a newline, printing to different targets, new ways of using placeholders, et cetera. Then there is the fact that strings are no more in Python 3, but they are Unicode. Again for average strings that's not really a problem, but when you start using bytes, special characters, et cetera. There is a tool to translate programs from Python 2 to Python 3, but it does not catch everything, and you still have to fix stuff manually.
  • acqq 11y ago
    Most of the common 2.x programs don't depend on the change in Unicode semantics or whatever, but they really don't work simply because really unnecessary changes in the way print and formatting must be written in 3.x. It was technically possible to make much more programs still work while still introducing the more convenient syntax and it was in my opinion bad judgement not to do so. In my view, those that made the decision took to seriously "there's only one way to do it." Zen of Python actually says: "There should be one-- and preferably only one --obvious way to do it." Even if the obvious way for 3.x can be different from 2.x, I can't imagine any real-life effects from allowing the alternative syntax for formatting and printing except for a few special-case branches somewhere in the source. Yes, then the people would continue to write it with the "wrong syntax" in the new programs too, so what?
    • eru 11y ago
      In Python3 print is now a function, and no longer a keyword. The syntax got strictly simpler that way, and semantics, too. You could try to make the interpreter guess when you want to use print as a function and when as a keyword. But that would be horribly complicated, and is bound to go wrong.
      • acqq 11y ago
• toyg 11y ago
  The Unicode fix, string formatting and print becoming a function. Also some stuff with old-style classes, I think, but that's a very small minority. Lesson for language designers: never, ever mess with your debugging/printout facilities once you've hit the mainstream.
• IanCal 11y ago
  For me it's not really that there are things keeping me away, it's more that py2.7 still seems fine for everything I want to do. I know all the libraries I'm used to are supported and I can make stuff work. There are some small hurdles to moving and I have no pressing need to jump over them.
• rkrzr 11y ago
  The non-existing support of some crucial libraries that you are depending on. That, in my opinion, is the number one reason holding people back from upgrading. Fortunately that is getting better and better, it is just a very slow process.
• peterfirefly 11y ago
  Old Python handled strings in a really dumb way that only seemed to work for monolingual Americans and (to a lesser extent) Western Europeans. New Python fixed that. Problems: 1) new Python wasn't very tolerant of real-world conditions where incorrect text encoding happens once in a while. 1b) there was great resistance to fixing that because "Python now did it correctly!" and the rest of the world was just assumed to do it correctly, always. 2) not everybody who already programmed in Python really understood the need for the new (and mostly correct) way of handling strings. Also not everybody in the US really understood Unicode and encodings. 3) there was no proper update path from Old Python to New Python. 4) it was not possible (or very difficult) to write code that was both valid Old Python and valid New Python and which did the right thing in both cases. 5) at the same time the interface for libraries written in C was changed. 5a) the new way was better. 5b) a change was needed for New Pythons string handling anyway. 5c) it could still have been done in a backwards-compatible way... 5d) ... but it wasn't, since the new way was Better. 6) lots of important Python libraries are partially written in C because pure Python is so slow 7) ... so porting all the important libraries was necessary for New Python to take off while at the same time being rather annoying and difficult work. There were other changes at the same time that were improvements but which made upgrading hard. Print was no longer a keyword with lots of special handling and corner cases but an ordinary function. You could switch newer versions of Python 2.x to the same behaviour but not the older ones. Many libraries needed to work with many different Python 2.x versions, which made it hard to support Python 3.x at the same time. You could convert all your print statements to using a function that worked like the new print function and then either use that natively (3.x and newer 2.x) or provide a compatibility function that wrapped the print statement (older 2.x). You would put this code in a module you would selectively import depending on the Python version -- or some variant of that. Not actually hard but really annoying and something that required changing many lines of some libraries. Ad 1, things have improved a lot and there are now known ways of fixing the remaining problems (with newer 3.x versions). Ad 2, Unicode is better understood these days. Ad 3 and 4, things have again improved. If you skip the first few 3.x versions and the early 2.x versions then it is not too hard to write code that works on both Old and New Python. Ad 5, I don't know if is possible to support both ABIs in a single shared library, but at least the core code that actually does the work can be shared. PyPy might have helped as well by making ordinary Python -- the kind you would otherwise write in C -- run fast. Edit: formatting is hard.
• est 11y ago
  py3k break str(), a very basic yet extremely important data type for all scripting languages.
• jflatow 11y ago
  You also take a performance hit, which however subtle, can be hard to justify when making a relatively big 'upgrade'.