5 ms·

What would you like to see?

by aberrant 12y ago

shadowmint 12y ago
multi-line lambdas.
- Noelkd 12y ago
  Wouldn't you just define a function in that case? Guido has mentioned[1] that he isn't a fan of lambda functions. [1] http://www.linuxjournal.com/article/2959 http://www.linuxjournal.com/article/2959
- jdpage 12y ago
  Not happening, because it would mean multi-line function arguments, which have been declared "ugly". http://legacy.python.org/dev/peps/pep-3099/ http://legacy.python.org/dev/peps/pep-3099/
- EliAndrewC 12y ago
  Guido explains in an old blog post (http://www.artima.com/weblogs/viewpost.jsp?thread=147358 http://www.artima.com/weblogs/viewpost.jsp?thread=147358) that he considers all of the possible implementations of multi-line lambdas to be un-Pythonic: > But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.
segphault 12y ago
For starters, I really want CoffeeScript's safe accessor operator: "x?.y" Microsoft is even reportedly considering it* for inclusion in C#, now. I think every object-oriented programming language should have it. * http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-las...
- emidln 12y ago
  I'm perfectly fine with defining get and get_in ala Clojure and using them (they work on __getitem__ supporting things, so dicts, lists, strings, most random user-level containers). I go a bit further in my codebases and implement: def get(obj, k, default=None): """ safe __getitem__ obj[k] with a default """ def assoc(obj, k, v): """ obj[k] = v returning obj """ def dissoc(obj, k): """ safe del obj[k] returning obj without k""" def get_in(obj, keys, default=None): """ __getitem__ obj[k0][k1][kn] with a default. """ def assoc_in(obj, keys, v, default=lambda n: dict()): """ __setitem__ obj[k0][k1][kn] = v. __getitem__ failures handled with default """ def dissoc_in(obj, keys): """ Return obj asserting that obj[k0][k1][kn] does not exist. """ def update_in(obj, keys, update_fn=None, default=lambda n:dict()): """ Update the value at obj[k0][k1][kn] with update_fn returning obj. __getitem__ failures handled by default. """ def merge_with(fn, **dictionaries): """ Merge resolving node conflicts with fn """ def deep_merge_with(fn, **dictionaries): """ Recursively merge resolving node conflicts with fn""" as a matter of course in most of python webapp and data munging projects. They are insanely useful when working with the gobs of JSON that is common when interacting with modern web services. I really should throw the implementations into a public library at this point.
- thwest 12y ago
  Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None. Objects should be valid.
  - dragonwriter 12y ago
    > Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None. Producing NULL (or whatever the languages equivalent is) isn't an error -- if there was an error, it would be throwing an exception, not returning NULL. The idea of "do this chain of operations propagating nulls encountered at any point" is reasonably useful.
    - thwest 12y ago

What would you like to see?

shadowmint 12y ago

multi-line lambdas.

Noelkd 12y ago
Wouldn't you just define a function in that case? Guido has mentioned[1] that he isn't a fan of lambda functions. [1] http://www.linuxjournal.com/article/2959 http://www.linuxjournal.com/article/2959
jdpage 12y ago
Not happening, because it would mean multi-line function arguments, which have been declared "ugly". http://legacy.python.org/dev/peps/pep-3099/ http://legacy.python.org/dev/peps/pep-3099/
EliAndrewC 12y ago
Guido explains in an old blog post (http://www.artima.com/weblogs/viewpost.jsp?thread=147358 http://www.artima.com/weblogs/viewpost.jsp?thread=147358) that he considers all of the possible implementations of multi-line lambdas to be un-Pythonic: > But the complexity of any proposed solution for this puzzle is immense, to me: it requires the parser (or more precisely, the lexer) to be able to switch back and forth between indent-sensitive and indent-insensitive modes, keeping a stack of previous modes and indentation level. Technically that can all be solved (there's already a stack of indentation levels that could be generalized). But none of that takes away my gut feeling that it is all an elaborate Rube Goldberg contraption.

segphault 12y ago

For starters, I really want CoffeeScript's safe accessor operator: "x?.y" Microsoft is even reportedly considering it* for inclusion in C#, now. I think every object-oriented programming language should have it. * http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-last-c-is-getting-sometimes-called-the-safe-navigation-operator.aspx http://blogs.msdn.com/b/jerrynixon/archive/2014/02/26/at-las...

emidln 12y ago
I'm perfectly fine with defining get and get_in ala Clojure and using them (they work on __getitem__ supporting things, so dicts, lists, strings, most random user-level containers). I go a bit further in my codebases and implement: def get(obj, k, default=None): """ safe __getitem__ obj[k] with a default """ def assoc(obj, k, v): """ obj[k] = v returning obj """ def dissoc(obj, k): """ safe del obj[k] returning obj without k""" def get_in(obj, keys, default=None): """ __getitem__ obj[k0][k1][kn] with a default. """ def assoc_in(obj, keys, v, default=lambda n: dict()): """ __setitem__ obj[k0][k1][kn] = v. __getitem__ failures handled with default """ def dissoc_in(obj, keys): """ Return obj asserting that obj[k0][k1][kn] does not exist. """ def update_in(obj, keys, update_fn=None, default=lambda n:dict()): """ Update the value at obj[k0][k1][kn] with update_fn returning obj. __getitem__ failures handled by default. """ def merge_with(fn, **dictionaries): """ Merge resolving node conflicts with fn """ def deep_merge_with(fn, **dictionaries): """ Recursively merge resolving node conflicts with fn""" as a matter of course in most of python webapp and data munging projects. They are insanely useful when working with the gobs of JSON that is common when interacting with modern web services. I really should throw the implementations into a public library at this point.
thwest 12y ago
Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None. Objects should be valid.
- dragonwriter 12y ago
  > Why though? I'm of the opinion that the error should be handled at the place that produces the first NULL/None. Producing NULL (or whatever the languages equivalent is) isn't an error -- if there was an error, it would be throwing an exception, not returning NULL. The idea of "do this chain of operations propagating nulls encountered at any point" is reasonably useful.
  - thwest 12y ago