4 ms·

Python has a convention for "private" functions, which is to prepend "_" to the name. > It's hard to make a strong case just in words, but once you really unde

by y7 8y ago

Python has a convention for "private" functions, which is to prepend "_" to the name. > It's hard to make a strong case just in words, but once you really understand the power of the fat arrow syntax for anonymous inline functions then you use it more and more and it becomes second nature and the programs you write have a completely different style, oriented towards neatly positioned inline anonymous functions everywhere that typically can be read and understood at a glance as you skip through the code. This is exactly why I think Python has such limited anonymous functions: because it does not want to promote that style. > There is simply no other way to write a function that absolutely cannot be called by some other bit of code. Python also believes that you do not need to defend against this possibility, as long as you make it clear to other developers that they should not call your "private function". This is also why the language allows monkey patching anything at will. If someone wants to ignore good sense, let them.

andrewstuart 8y ago
Private functions do not restrict the usage of that function to one point in the code. There's a world of difference between a coding convention - essentially a comment to say "please don't access this function from outside the current class" versus it simply being impossible to do so. And the "private" convention does not say "don't use this function at any other point except one", it says "please don't access this function from outside the current class", which is completely different to the point I make. Anonymous inline functions reduce lines of code and complexity. >>because it does not want to promote that style. Why would Python not want to promote a more readable, simple, powerful, reliable and maintainable programming style? Can you reference anything to back this assertion?
- joshuamorton 8y ago
  As a user of JavaScript and es6, fat arrows are only necessary if you haven't started using async and await syntax, and I found myself almost never using fat arrows after moving to async/await. Indeed naming my functions resulted in more testable and clearer code.
  - andrewstuart 8y ago
    Hmmmm. I don't see the relationship between async/await and fat arrows. Can you explain more about how async/await obviates the need for fat arrows?
    - joshuamorton 8y ago
      Just async is callback based. You don't need callbacks with async/await. No callbacks, no need for fat arrow.
      - andrewstuart 8y ago
        Interesting idea.
  - dragonwriter 8y ago
    While I can see async/await replacing a lot of the most common use in JS, anonymous functions have a lot more uses than that (passing a single use function to generic algorithm, like an ordering function to a sorting routine, is one of the more common other uses, across languages.)
  - danShumway 8y ago
    Getting rid of fat arrows is one thing, but I use async/await pretty much all the time, and I still use anonymous functions in my code. await (async function () { //Do a thing }()); I don't think async changes anything about how useful or problematic an anonymous function is.
    - joshuamorton 8y ago
      That feels like a weird pattern (for one because you can have async fat arrows), but also because in general I find await request_some_data() much clearer than await (async () => { // just make the async request inline })()
      - 8y ago
- another-cuppa 8y ago
  Come on. You've defined a function inside another function. It's very clear that you've done it so you can pass it to some higher level function. If someone comes along and starts using your inner function willy nilly in the outer function without anyone noticing then you've got much bigger problems that multiline lambdas are not going to help you with.
- anentropic 8y ago
  The parent comment about private naming convention is a red herring. 99% of the time in places where you might use a multi-line anonymous function you're already inside another function So when you define your named function in Python, it is only available within the scope of the current method call and there's no danger of it being abused by other developers. The lack of true private vars in python is a separate issue, and one of the best things about the language (because library authors inevitably get carried away and mark things as private which don't need to be - then you're stuck in copy & paste land... I did loads of ActionScript back in the day and this was super frustrating)
danShumway 8y ago
> Python also believes that you do not need to defend against this possibility, as long as you make it clear to other developers that they should not call your "private function". Python has apparently never worked in a large, corporate environment with a multinational team. Yes, in theory you can just not call private methods. And in my own personal code I don't care much about restricting variable access, because I trust myself. However, it is a tremendous amount of work to get a company culture to start respecting privates if they aren't already. I've had so many phone calls trying to explain why "yes, you can technically call this function, but in reality you can't, and I don't care that your deadline is tomorrow, you still can't. And yes, I know that technically you're on a separate team and not under my jurisdiction, but you can't just remove me from the code review and call all of my library's private functions anyway." It's taking the path of most resistance. True privates are very helpful on large teams.

by y7 8y ago

andrewstuart 8y ago

Private functions do not restrict the usage of that function to one point in the code. There's a world of difference between a coding convention - essentially a comment to say "please don't access this function from outside the current class" versus it simply being impossible to do so. And the "private" convention does not say "don't use this function at any other point except one", it says "please don't access this function from outside the current class", which is completely different to the point I make. Anonymous inline functions reduce lines of code and complexity. >>because it does not want to promote that style. Why would Python not want to promote a more readable, simple, powerful, reliable and maintainable programming style? Can you reference anything to back this assertion?

joshuamorton 8y ago
As a user of JavaScript and es6, fat arrows are only necessary if you haven't started using async and await syntax, and I found myself almost never using fat arrows after moving to async/await. Indeed naming my functions resulted in more testable and clearer code.
- andrewstuart 8y ago
  Hmmmm. I don't see the relationship between async/await and fat arrows. Can you explain more about how async/await obviates the need for fat arrows?
  - joshuamorton 8y ago
    Just async is callback based. You don't need callbacks with async/await. No callbacks, no need for fat arrow.
    - andrewstuart 8y ago
      Interesting idea.
- dragonwriter 8y ago
  While I can see async/await replacing a lot of the most common use in JS, anonymous functions have a lot more uses than that (passing a single use function to generic algorithm, like an ordering function to a sorting routine, is one of the more common other uses, across languages.)
- danShumway 8y ago
  Getting rid of fat arrows is one thing, but I use async/await pretty much all the time, and I still use anonymous functions in my code. await (async function () { //Do a thing }()); I don't think async changes anything about how useful or problematic an anonymous function is.
  - joshuamorton 8y ago
    That feels like a weird pattern (for one because you can have async fat arrows), but also because in general I find await request_some_data() much clearer than await (async () => { // just make the async request inline })()
    - 8y ago
another-cuppa 8y ago
Come on. You've defined a function inside another function. It's very clear that you've done it so you can pass it to some higher level function. If someone comes along and starts using your inner function willy nilly in the outer function without anyone noticing then you've got much bigger problems that multiline lambdas are not going to help you with.
anentropic 8y ago
The parent comment about private naming convention is a red herring. 99% of the time in places where you might use a multi-line anonymous function you're already inside another function So when you define your named function in Python, it is only available within the scope of the current method call and there's no danger of it being abused by other developers. The lack of true private vars in python is a separate issue, and one of the best things about the language (because library authors inevitably get carried away and mark things as private which don't need to be - then you're stuck in copy & paste land... I did loads of ActionScript back in the day and this was super frustrating)

danShumway 8y ago

> Python also believes that you do not need to defend against this possibility, as long as you make it clear to other developers that they should not call your "private function". Python has apparently never worked in a large, corporate environment with a multinational team. Yes, in theory you can just not call private methods. And in my own personal code I don't care much about restricting variable access, because I trust myself. However, it is a tremendous amount of work to get a company culture to start respecting privates if they aren't already. I've had so many phone calls trying to explain why "yes, you can technically call this function, but in reality you can't, and I don't care that your deadline is tomorrow, you still can't. And yes, I know that technically you're on a separate team and not under my jurisdiction, but you can't just remove me from the code review and call all of my library's private functions anyway." It's taking the path of most resistance. True privates are very helpful on large teams.