4 ms·

> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport st

> Python programmers and companies with python code should spend the time and effort to move to python 3 instead of spending that time and effort to backport stuff to python 2 because python 2 is deprecated and the future is python 3. I hate Python 3's removal of the (lambda (key, value): blah) tuple unpacking syntax, and the forcing of parentheses for print statements. They might seem minor but they aren't for me. So I'm not at all eager to move to version 3 and don't really see any benefit. Not sure if those who aren't migrating feel the same way, but I wouldn't be surprised if some of them do. (Edit to address comment below: There are more issues I have with Python 3. It allows more bugs to slip through, for instance. I actually particularly like a comment I just wrote, so I'll link to it here: https://news.ycombinator.com/item?id=13145299 https://news.ycombinator.com/item?id=13145299 Do note that this was added after the reply below.)

BozeWolf 10y ago
Benefits? Unicode. Async. Extended library. Required keywords. syntax inprovements (lots of m, many more than just the removal of the print statement). Type hinting.
- wfunction 10y ago
  > Benefits? I meant I don't see any benefits for me, not benefits for other people. I assumed that was clear; sorry if it wasn't. > Unicode. Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language. > Async. It's a nice feature, yeah. I can live without it, as people have for many years. Maybe if I was used to having it around I wouldn't want to go back, but I'm not. > Extended library. Cool! I'm not sure what exactly falls under this that I'm supposed to be missing, but pip install has sure been taking care of everything in the blink of an eye in version 2. > Required keywords. Cool! I need it about as much as I need a donut. > syntax inprovements (lots of m, many more than just the removal of the print statement). nonlocal is literally the only positive one I can think of right now that I'd actually care about. But then again, it comes up maybe 50x less often than the parentheses I have to write for print, or the tuple unpacking that I have to do. So yeah, it's hardly a reason to migrate. > Type hinting. Nice to have. I'm living just fine without it. Maybe I'd have migrated if it actually optimized things or did something more useful.
  - BozeWolf 10y ago
    Well, things change, especially in tech. For better or worse, but most of the time for the better. You should read some changelogs of past python 3 releases. 3.6, for example, has ordered dicts by default. Which is quite convenient when you need to write test testing a small dict with two items for example. I like driving an old muscle car, most of m look beautiful and bring me everywhere i want. But damn, those new cars changed a lot and are much more comfortable. (But they do break as much ;))
    - nicpottier 10y ago
      Pretty sure they say NOT to rely on the ordered nature of the new dicts. So definitely not something you want to put in your tests.
      - gsnedders 10y ago
        The intention is to make the order guaranteed in 3.7 or 3.8, AIUI. There was some desire to prove the new implementation before guaranteeing its behaviours (i.e., in the worst case, if it turned out to be broken, they could revert to the 3.5 code and it would be valid).
        BozeWolf 10y ago
        No it is in 3.6 already! It used to be not guaranteed. https://mail.python.org/pipermail/python-dev/2016-September/146327.html https://mail.python.org/pipermail/python-dev/2016-September/... But it is insertion order indeed, not sorting order.
        gsnedders 10y ago
        The behaviour is there in CPython, yes. But the language documentation doesn't, deliberately.
- meddlepal 10y ago
  People often bring up the unicode thing but tons of Python code is backend glue code that really doesn't care at all about unicode.
xrisk 10y ago
So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.
- wfunction 10y ago
  > So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs. Think about that! Second, no, I just listed the two that irritated me the most every time I tried to switch, because they were the first things that came up by far the earliest and most frequently. Small inconveniences can be amplified through their frequencies. There are lots of things I don't like about it though... division becoming floating point division, having to say list(foo.items()) or list(map(...)) instead of just foo.items(), etc... again, more verbosity and typing for common cases where I really didn't mind the old way. If I wanted imap(), I could've just used imap; they could've just moved that to __builtin__ and made my life easier that way. By the way -- the lazy nature of map(), etc. also means you catch fewer bugs now. Again, think about that! Just because it looks more efficient, that doesn't mean it's actually better. If there's anything I've learned, it's that even the smallest things tend to come with non-obvious tradeoffs. Finally, regarding strings: if you look at my earlier comments, yes, I already acknowledged the Unicode changes were for the better. Awesome. I agree. Cool? OK, but there are other things in the language besides Unicode though, and they're not as awesome. I don't spend my entire programming life dealing with Unicode strings, so I care about other things too, and they make my life harder. Simple as that.
  - js8 10y ago
    Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner function. It's a feature/shortcoming (depends on POV) of Python that you cannot bind variables in an expression. I hope you understand that they couldn't keep the feature in lambdas if they didn't keep it in proper functions. I am sure if you think about other things, there are good reasons to do it the way Python 3 does it, usually there is a hidden case where things need to be disambiguated (like your list() examples).
gigatexal 10y ago
That seems kinda petty. Surely you can work around that. If they really were killer features that many devs used I doubt they'd have been deprecated and removed in python 3. I do agree that though I wish lambdas could be more useful instead of one liners.
kstrauser 10y ago
> and the forcing of parentheses for print statements You mean print functions. I love the new change because you can pass "print" around like any other function now, letting you write code like: def my_map(data, func): for item in data: func(item) my_map(dataset, insert_into_database) # For testing my_map(dataset, print)

BozeWolf 10y ago

Benefits? Unicode. Async. Extended library. Required keywords. syntax inprovements (lots of m, many more than just the removal of the print statement). Type hinting.

wfunction 10y ago
> Benefits? I meant I don't see any benefits for me, not benefits for other people. I assumed that was clear; sorry if it wasn't. > Unicode. Yeah, but some people have still been living without the changes, and it's hardly enough of a reason on its own (for me anyway) when there's other things I hate about the language. > Async. It's a nice feature, yeah. I can live without it, as people have for many years. Maybe if I was used to having it around I wouldn't want to go back, but I'm not. > Extended library. Cool! I'm not sure what exactly falls under this that I'm supposed to be missing, but pip install has sure been taking care of everything in the blink of an eye in version 2. > Required keywords. Cool! I need it about as much as I need a donut. > syntax inprovements (lots of m, many more than just the removal of the print statement). nonlocal is literally the only positive one I can think of right now that I'd actually care about. But then again, it comes up maybe 50x less often than the parentheses I have to write for print, or the tuple unpacking that I have to do. So yeah, it's hardly a reason to migrate. > Type hinting. Nice to have. I'm living just fine without it. Maybe I'd have migrated if it actually optimized things or did something more useful.
- BozeWolf 10y ago
  Well, things change, especially in tech. For better or worse, but most of the time for the better. You should read some changelogs of past python 3 releases. 3.6, for example, has ordered dicts by default. Which is quite convenient when you need to write test testing a small dict with two items for example. I like driving an old muscle car, most of m look beautiful and bring me everywhere i want. But damn, those new cars changed a lot and are much more comfortable. (But they do break as much ;))
  - nicpottier 10y ago
    Pretty sure they say NOT to rely on the ordered nature of the new dicts. So definitely not something you want to put in your tests.
    - gsnedders 10y ago
      The intention is to make the order guaranteed in 3.7 or 3.8, AIUI. There was some desire to prove the new implementation before guaranteeing its behaviours (i.e., in the worst case, if it turned out to be broken, they could revert to the 3.5 code and it would be valid).
      - BozeWolf 10y ago
        No it is in 3.6 already! It used to be not guaranteed. https://mail.python.org/pipermail/python-dev/2016-September/146327.html https://mail.python.org/pipermail/python-dev/2016-September/... But it is insertion order indeed, not sorting order.
        gsnedders 10y ago
        The behaviour is there in CPython, yes. But the language documentation doesn't, deliberately.
meddlepal 10y ago
People often bring up the unicode thing but tons of Python code is backend glue code that really doesn't care at all about unicode.

xrisk 10y ago

So you _hate_ Python 3 because of two changes in syntactic sugar? I would understand if you hated it because of the real breaking changes, but no... I think you just don't comprehend the multitude of problems that Python 3 fixes by handling strings correctly... Maybe you've never handled Unicode before.

wfunction 10y ago
> So you _hate_ Python 3 because of two changes in syntactic sugar? First of all, the tuple unpacking one is a HUGE readability AND maintainability issue; it's not just syntactic sugar. var[0][1][2] is not only far less readable than the unpacking notation, it doesn't even have the same semantics (doesn't enforce the structure of the tuple). That means Python 2.7 helped me catch more bugs. Think about that! Second, no, I just listed the two that irritated me the most every time I tried to switch, because they were the first things that came up by far the earliest and most frequently. Small inconveniences can be amplified through their frequencies. There are lots of things I don't like about it though... division becoming floating point division, having to say list(foo.items()) or list(map(...)) instead of just foo.items(), etc... again, more verbosity and typing for common cases where I really didn't mind the old way. If I wanted imap(), I could've just used imap; they could've just moved that to __builtin__ and made my life easier that way. By the way -- the lazy nature of map(), etc. also means you catch fewer bugs now. Again, think about that! Just because it looks more efficient, that doesn't mean it's actually better. If there's anything I've learned, it's that even the smallest things tend to come with non-obvious tradeoffs. Finally, regarding strings: if you look at my earlier comments, yes, I already acknowledged the Unicode changes were for the better. Awesome. I agree. Cool? OK, but there are other things in the language besides Unicode though, and they're not as awesome. I don't spend my entire programming life dealing with Unicode strings, so I care about other things too, and they make my life harder. Simple as that.
- js8 10y ago
  Regarding tuple unpacking, instead of writing, say: def foo((birthname,surname)): ... you can write in Python 3: def foo(name): birthname, surname = name ... It's not less readable. I also missed it in the beginning, but it's not really a big deal. (I think they couldn't keep the feature because of how '*' is used, but I am not sure.) Edit: If you have problem with this in lambda expression, just create a named inner function. It's a feature/shortcoming (depends on POV) of Python that you cannot bind variables in an expression. I hope you understand that they couldn't keep the feature in lambdas if they didn't keep it in proper functions. I am sure if you think about other things, there are good reasons to do it the way Python 3 does it, usually there is a hidden case where things need to be disambiguated (like your list() examples).

gigatexal 10y ago

That seems kinda petty. Surely you can work around that. If they really were killer features that many devs used I doubt they'd have been deprecated and removed in python 3. I do agree that though I wish lambdas could be more useful instead of one liners.

kstrauser 10y ago

> and the forcing of parentheses for print statements You mean print functions. I love the new change because you can pass "print" around like any other function now, letting you write code like: def my_map(data, func): for item in data: func(item) my_map(dataset, insert_into_database) # For testing my_map(dataset, print)