Hacker News Reader

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.

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

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.

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)

> 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-e... If you're telling me this isn't Pythonic, you're really just not being sensible.

> 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#collectio...

I think you should watch some Raymond Hettinger's talks, he is discussing many little things like this.

Yes, Really Now! Your disdain for the answers people are giving you, and your abrasive demeanor tell me I can spend my time better than to discuss this further with you.

Why would you want to downvote somebody trying to help you?

In any case, I think I see your problem. You are not the sole user of Python language. There are features that other people like (such as using '*' in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made.

And frankly, I think if you like to use lambdas that much, you really want to program in a language where everything is an expression, such as Lisp or Haskell.

> Why would you want to downvote somebody trying to help you?

Misreading comments is not helping.

That's why I used the word "trying". Maybe you should read more carefully before you want to accuse others from misreading something. ;-)

I think it's unfair to say that I misread his comment - he doesn't explicitly mention he is aware of the workaround I outlined for the functions, and that he is bothered with lack of tuple unpacking in lambda expressions only, not in ordinary functions.

Regardless, I still think it's quite impolite to downvote somebody who wants to help you and misunderstands you, if they are not e.g. factually incorrect. If you don't actually tell me where I am wrong, I cannot improve my answer. Also, this is not Stackoverflow, where that could be marginally acceptable (I am very strongly against downvoting without explanation).

> Regardless, I still think it's quite impolite to downvote somebody who wants to help you and misunderstands you

Well, I don't consider it a "misunderstanding" when there are literally just 2 things to note in my comment that you're replying to ("lambda" and "tuple unpacking") and you still somehow miss 1 of them. I think it totally deserves a downvote, because it makes me look stupid when you present a reasonable solution to a non-problem and make readers assume I was saying something other than I was, and on top of that I have to waste some 5-10 minutes of my time replying. That's not something I appreciate.

That said, like I said, I never actually downvoted that comment (because I obviously couldn't). So you don't need to worry about the internet points.

If you weren't busy taking things so personally, you could note that I already hinted in my comment on why I made it - I missed the feature of unpacking within function arguments myself at first too, until I realized that unpacking within the body isn't really less readable. (And please - do not waste time replying.)

I admit I don't use lambdas that much, since generator expressions (which is like Python 2.3) they aren't really needed too frequently. And in most cases you're better off using function anyway, because in Python statements are not expressions, as I already also stated. For example, I use print() for debugging frequently and this is tough to insert into lambda. (And even in Haskell I prefer to name subexpressions to lambda syntax.)

> That said, like I said, I never actually downvoted that comment (because I obviously couldn't). So you don't need to worry about the internet points.

I am not worried about internet points (I actually got about 80 of them on this discussion alone, which is frankly ridiculously too much, and in practice, I find that comments I personally find to be the most insightful only rarely get most points), I am just really annoyed when somebody downvotes my comments without any explanation, because I am a very curious person and in most cases it's just a honest misunderstanding, which could be cleared up with, I don't know, actual communication?

And at least two or three other people actually downvoted my original comment, so I would like to use this opportunity to invite them to come forward with an explanation what they found so wrong about it.

> In any case, I think I see your problem. You are not the sole user of Python language.

I'm glad I'm not. Otherwise I probably wouldn't be using it either. Not sure how that is my "problem".

> There are features that other people like (such as using [asterisk] in unpacking), and so features you like are weighted against their use cases, and a reasonable compromise is made.

I like that [asterisk] syntax too.

> And frankly, I think if you like to use lambdas that much, you really want to program in a language where everything is an expression, such as Lisp or Haskell.

Or I could just keep using Python 2.7 which works just fine, and not move to version 3 where I'm not welcome.

> Not sure how that is my "problem".

It's your problem in e.g. where you want list returned by default where Python 3 returns an iterator by default. Why is that useful for many people was already explained.

> I like that [asterisk] syntax too.

Funny, AFAIK it is Python 3 only.. https://www.python.org/dev/peps/pep-3132/

> Or I could just keep using Python 2.7 which works just fine, and not move to version 3 where I'm not welcome.

You are welcome to use Python 3, but - suit yourself. :-)

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.

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.

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.

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

> Array.FindAll, Array.Convert, etc. all existed in C# beforehand. Though maybe this is what you meant in the next sentence.

Yes, it's what I had in mind. I have to admit that I completely forgot about ConvertAll (and so assumed there was no map).

I think the biggest reason why those weren't all that commonly used in practice, is because in .NET you often deal with opaque collection types (like ICollection<T>, or ReadOnlyCollection<T>, or even custom-made collections pre-generics) that are usually exposed on properties of objects. Since the concrete type is not known, you can't do List.ConvertAll etc.

This, by the way, is another point in the favor of lazy implementations - they don't care about input type, because the output type is always "lazy sequence". Of course, you can have an eager map similarly not care about input, but then what should be the type of its output collection by default? No matter what type you choose, someone will complain that they wanted someone else. Given Python's preference for explicitness, such design would warrant several functions like map_to_list, map_to_tuple, map_to_set etc. But, of course, if you have a lazy map, you might as well just write list(map(...)) etc.

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

It's a bit different, though. When you import itertools, it brings all those functions into your global namespace. But when you import System.Linq, it only brings one static class into your global namespace; the actual functions are extension methods that only show up on the types to which they are applicable. So the resulting namespace pollution is far less in C#.

There's also the issue of import being generally frowned upon in idiomatic Python, largely because the way conflict resolution works there (silent override). In C#, if you happen to have clashing identifiers from usings, it'll prevent you from using them unqualified, so there's no good reason to avoid it.