4 ms·

> 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

> 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).
- wfunction 10y ago
  I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas. That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine.
  - rndgermandude 10y ago
    Lambdas are not really pythonic these days anyway list(map(lambda (some, thing): some + thing, everything)) # better list(some + thing for (some, thing) in everything) Or, as the parent suggests, just create helper function, preferably one your python environment doesn't need to set up every time your outer function is called # okish, "verbose lambda" def compute(everything): def magic(elem): some, thing = elem return some + thing return list(map(magic, everything)) # probably better def magic(some, thing): return some + thing def compute(everything): return list(magic(some, thing) for (some, thing) in everything)
    - wfunction 10y ago
      > Lambdas are not really pythonic these days anyway Too much nonsense in your comment. Really now? How about you give a realistic example where syntactic sugar doesn't substitute for it? Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... and that's the prime example on their web page (and a realistic one at that) for where you're supposed to use lambdas: https://docs.python.org/3/tutorial/controlflow.html#lambda-expressions https://docs.python.org/3/tutorial/controlflow.html#lambda-e... If you're telling me this isn't Pythonic, you're really just not being sensible.
      - js8 10y ago
        > Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... I suggest you look at namedtuple: https://docs.python.org/3/library/collections.html#collections.namedtuple https://docs.python.org/3/library/collections.html#collectio... I think you should watch some Raymond Hettinger's talks, he is discussing many little things like this.
ianamartin 10y ago
If your needs are for static analysis and type checking at compile-time, you are using the wrong language. I'm a huge lover of Python, but I drop into C# when I need stuff like that. Or Go. Or Rust. Or something. You're just making bad decisions here. If you're looking to catch bugs in your code before you test or deploy it, don't use a dynamic language. Python has never been and probably never will be a language with declarative types and the checking that allows. Pick a different hammer if that's the nail you need to hit. Don't complain about the hammer you want to use not being a screwdriver.
ianamartin 10y ago
If your needs are for static analysis and type checking at compile-time, you are using the wrong language. I'm a huge lover of Python, but I drop into C# when I need stuff like that. Or Go. Or Rust. Or something. You're just making bad decisions here. If you're looking to catch bugs in your code before you test or deploy it, don't use a dynamic language. Python has never been and probably never will be a language with declarative types and the checking that allows. Pick a different hammer if that's the nail you need to hit. Don't complain about the hammer you want to use not being a screwdriver.
int_19h 10y ago
Regarding laziness of map() - lazy is a good default, because you can always make eager out of lazy, but not the other way around. Lazy is also more general, because it can handle both lazy and eager inputs, while eager will always force a lazy input. This has been the general trend in mainstream languages lately, not just in Python. E.g. in C#, all LINQ operations are lazy. in Java, the new stream API, to be used with lambdas, is lazy.
- wfunction 10y ago
  Notice in said languages they added lazy APIs. They did not remove eager APIs. Python already had imap, ifilter, izip, etc... I already said this and I'll repeat: I would've been just fine if they made those easier to use (e.g. no import). There was no need to change the behavior of existing APIs.
  - int_19h 10y ago
    There were generally no map/filter/fold APIs in those languages, eager or lazy. In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). The new APIs are more straightforward to use. The reason to change the behavior of an existing API is because the default (i.e. most obvious) API should also be the most flexible, and do the right thing in as many cases as possible. This was not the case with map etc in Py2. The disadvantage of changing an existing API like that is that it breaks code. But Py3 broke code anyway, so it was a good time to introduce breaks like that for the sake of better defaults.
    - wfunction 10y ago
      > There were generally no map/filter/fold APIs in those languages, eager or lazy. Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence. > In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). This is going on a tangent but LINQ still has hoops to jump through. You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import *" and then using imap, which you could've always done.

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).

wfunction 10y ago
I wish I could downvote. I specifically said I hate the tuple unpacking syntax change in lambdas. That's where I used it so much to begin with, not in defs! I obviously can't put statements like that in lambdas, and until now I didn't need to do that to make my code readable. Now I have to name all of my lambdas just to make this syntax work, which is nonsense. It used to be there and it worked perfectly fine.
- rndgermandude 10y ago
  Lambdas are not really pythonic these days anyway list(map(lambda (some, thing): some + thing, everything)) # better list(some + thing for (some, thing) in everything) Or, as the parent suggests, just create helper function, preferably one your python environment doesn't need to set up every time your outer function is called # okish, "verbose lambda" def compute(everything): def magic(elem): some, thing = elem return some + thing return list(map(magic, everything)) # probably better def magic(some, thing): return some + thing def compute(everything): return list(magic(some, thing) for (some, thing) in everything)
  - wfunction 10y ago
    > Lambdas are not really pythonic these days anyway Too much nonsense in your comment. Really now? How about you give a realistic example where syntactic sugar doesn't substitute for it? Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... and that's the prime example on their web page (and a realistic one at that) for where you're supposed to use lambdas: https://docs.python.org/3/tutorial/controlflow.html#lambda-expressions https://docs.python.org/3/tutorial/controlflow.html#lambda-e... If you're telling me this isn't Pythonic, you're really just not being sensible.
    - js8 10y ago
      > Like what am I supposed to pass to sort(key)? And incidentally, this tuple unpacking problem comes up when sorting frequently... I suggest you look at namedtuple: https://docs.python.org/3/library/collections.html#collections.namedtuple https://docs.python.org/3/library/collections.html#collectio... I think you should watch some Raymond Hettinger's talks, he is discussing many little things like this.

ianamartin 10y ago

If your needs are for static analysis and type checking at compile-time, you are using the wrong language. I'm a huge lover of Python, but I drop into C# when I need stuff like that. Or Go. Or Rust. Or something. You're just making bad decisions here. If you're looking to catch bugs in your code before you test or deploy it, don't use a dynamic language. Python has never been and probably never will be a language with declarative types and the checking that allows. Pick a different hammer if that's the nail you need to hit. Don't complain about the hammer you want to use not being a screwdriver.

ianamartin 10y ago

int_19h 10y ago

Regarding laziness of map() - lazy is a good default, because you can always make eager out of lazy, but not the other way around. Lazy is also more general, because it can handle both lazy and eager inputs, while eager will always force a lazy input. This has been the general trend in mainstream languages lately, not just in Python. E.g. in C#, all LINQ operations are lazy. in Java, the new stream API, to be used with lambdas, is lazy.

wfunction 10y ago
Notice in said languages they added lazy APIs. They did not remove eager APIs. Python already had imap, ifilter, izip, etc... I already said this and I'll repeat: I would've been just fine if they made those easier to use (e.g. no import). There was no need to change the behavior of existing APIs.
- int_19h 10y ago
  There were generally no map/filter/fold APIs in those languages, eager or lazy. In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). The new APIs are more straightforward to use. The reason to change the behavior of an existing API is because the default (i.e. most obvious) API should also be the most flexible, and do the right thing in as many cases as possible. This was not the case with map etc in Py2. The disadvantage of changing an existing API like that is that it breaks code. But Py3 broke code anyway, so it was a good time to introduce breaks like that for the sake of better defaults.
  - wfunction 10y ago
    > There were generally no map/filter/fold APIs in those languages, eager or lazy. Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence. > In cases where the APIs were there, they were generally not as easily accessible (i.e. they were the equivalent of imap etc, with some hoops to jump before you could use them). This is going on a tangent but LINQ still has hoops to jump through. You have to say "using System.Linq;" at the top if you want to use the new syntax. That's like saying "from itertools import *" and then using imap, which you could've always done.