I need to preface all of this with a disclaimer:\u00a0I love Python, but I am<\/i> able to see plenty of faults with it. In this article, I attempt to provide a very roundabout way of working around one of those faults: the lack of multi-line lambdas. This is not<\/i> to say that this is a good solution, but it may be one of the best that we have for certain cases. Try and see if one of the typical workarounds is the best option before settling on this.<\/p>\nIntro<\/h2>\n
Python has one missing feature that actually hurts my idea that Kotlin is a lot like a statically-typed Python: lack of multi-line lambdas; lambdas in Python, as you probably know, are limited to a single expression or statement. There are numerous ways to get around all of this, but none are very satisfying, since they either obfuscate the code or don\u2019t put it in the place that you want it.<\/p>\n
The first and most obvious workaround is to define a function that does what you want then pass that function in instead of a lambda. This is generally your best bet, and if you name the function well, it can help to actually make the code more clear. But, in some instances, having the code right there would be more helpful than any name.<\/p>\n
The next workaround is to try and squeeze your code into one line somehow. In this video of a talk given at PyCon 2016, Oneliner-izer: An Exercise in Constrained Coding<\/a>, Chelsea talks about how it\u2019s technically possible to squeeze any code into a single line (I watched the video a while ago and didn\u2019t actually finish it, so there may be some restrictions that I don\u2019t remember\/didn\u2019t see). To be blunt, this is probably a BAD idea. In simple cases, it may work, but it\u2019ll still likely be too confusing to be maintainable.<\/p>\n In certain circumstances you could also try to combine those lines using function piping<\/a> or composition<\/a>. If it\u2019s possible to do this, and everyone in your codebase is kind of into functional programming, then this is probably your best bet. It\u2019s generally pretty clean and readable, but it is limited.<\/p>\n That brings us to the workaround that I came up with for this article. It involves For a lambda that has no parameters and no return type, a For this case, it\u2019s just a simple context manager where To make this, you do a typical context manager, but Say that we want to provide more parameters than 0 or 1. How do we get more? Well, directly, we can\u2019t, but because of iterable unpacking, we can do essentially the same thing! So, to get two parameters, This context manager is kind of worthless, since it simply gives back the values you gave it as a tuple to use in the As I mentioned earlier in the aside about using tuples, you could technically pass in a list as the arguments use it to take care of the return value. This could be done by appending a return value to the end of the list or reassigning an item already in the list. This isn\u2019t all that terrible, mechanically, but it\u2019s confusing, error-prone, and doesn\u2019t read well. With this technique, one of the arguments that is passed in (preferably the last) is a small mutable data store. It probably has a method along the lines of This works, isn\u2019t too confusing, but seems to take up just a little excess space. Let\u2019s change it up just a little bit.<\/p>\n Instead of passing the object that will take on the return value as one of the arguments, you actually pass it as all<\/i> the arguments. You see, it\u2019s possible to unpack any<\/i> sequence object, and making one of those is super easy. I call this class Now, if I were actually implementing Overall, this didn\u2019t save us much space. In fact, in total it was longer due to the larger definition of When making a context manager, I highly recommend using Now, despite the fact that I\u2019ve removed a few limitations from using Normally, a function that uses a lambda is capable of using that lambda as many times as it wants. When it comes to a The block of code in a That\u2019s way more than just There can be only one. Only one \u201clambda\u201d can be passed in using a When you call the Normal functions that take lambdas are able to return something that can be used later. So that\u2019s the craziness that is multi-line lambdas using The Workaround That is the Topic of This Article<\/h2>\n
with<\/code> and context managers. If you\u2019ve followed my blog for a while, you may have read my articles earlier about in Java and Python<\/a>, in which I showed my initial findings for using context managers to do multiline lambdas. At the time, I placed limitations on them that aren\u2019t technically true. Before I get into that, though, I\u2019ll reshow how they can be used for lambdas.
\n<\/a><\/p>\nwith<\/code> block is really simple:<\/a><\/p>\nwith someFunc():\r\n # do something<\/pre>\n
__enter__()<\/code> doesn\u2019t return anything.
\nFor a lambda that has one parameter and no return type, a with<\/code> block is still pretty simple:<\/p>\nwith someFunc() as arg:\r\n # use arg<\/pre>\n
__enter__()<\/code> returns a value that is used for arg<\/code>.\u00a0In the older articles, I presented these as the only ways that with<\/code> blocks could be used for lambdas. Luckily, this actually covers a large majority of use cases, but it\u2019s actually not the extent of how far with<\/code> block lambdas can go.<\/p>\nMore Parameters<\/h2>\n
__enter__()<\/code> returns a tuple (or list \u2013 but a tuple is better) of two objects (i.e. return thing1, thing2<\/code>).
\nASIDE:<\/b> A tuple is better than a list for a few reasons. First, there are no brackets required to make a tuple, so it looks cleaner. Second, a tuple is immutable, so it can\u2019t be accidentally messed with. If you want to design it so that an argument becomes an out<\/code> argument, then you could use a list, but there are better, clearer ways to do this.
\nLet\u2019s make this a little more clear with an example:<\/p>\nclass MyContextManager:\r\n def __enter__(self):\r\n return 1, 2, 3, 4\r\n\r\n def __exit__(self, type, exc, tb):\r\n \u2026\r\n\r\nwith MyContextManager() as args:\r\n one, two, three, four = args\r\n print(one)\r\n print(two)\r\n print(three)\r\n print(four)<\/pre>\n
with<\/code> block, but it does demonstrate how multiple arguments can be provided to the \u201clambdas\u201d in the with<\/code> blocks. I expect that the name args<\/code> will generally be used unless a better name can be given for the specific situation. Also, you can see that it\u2019s easy to separate the arguments into something more useful in a single unpacking line.<\/p>\nReturn Values<\/h2>\n
\nSo, I\u2019ve got some alternatives, starting with my least favorite.<\/p>\nReturn Parameter<\/h2>\n
_return(self, value)<\/code> that can be called within the with<\/code> block. Calling it will set a value on the object which, if stored on the context manager, can be looked at in the __exit__()<\/code> method.<\/p>\nclass OutParameter:\r\n def _return(self, value):\r\n self.return_value = value\r\n\r\nclass MyContextManager:\r\n def __enter__(self):\r\n self.return_value = OutParameter()\r\n return 1, 2, 3, 4, self.return_value\r\n\r\n def __exit__(self, type, exc, tb):\r\n do_something_with(self.return_value.return_value)\r\n\r\nwith MyContextManager() as args:\r\n one, two, three, four, out = args\r\n \u2026\r\n out._return(value)<\/pre>\n
Function Signature<\/h2>\n
FunctionSignature<\/code>, since it encapsulates both the arguments as well as the return value, but I\u2019m not too keen on the name. I\u2019d happily accept some suggestions in the comments.<\/p>\nfrom collections.abc import Sequence\r\nclass FunctionSignature(Sequence):\r\n def arguments(self, *args):\r\n self.args = args\r\n return self\r\n\r\n def _return(self, value):\r\n self.return_value = value\r\n\r\n def __getitem__(self, index):\r\n return self.value[index]\r\n\r\n def __len__(self):\r\n return len(self.value)\r\n\r\nclass MyContextManager:\r\n def __enter__(self):\r\n self.sig = FunctionSignature()\r\n return self.sig.arguments(1, 2, 3, 4)\r\n\r\n def __exit__(self, type, exc, tb):\r\n do_something_with(self.sig.return_value)\r\n\r\nwith MyContextManager() as args:\r\n one, two, three, four = args\r\n \u2026\r\n args._return(value)<\/pre>\n
FunctionSignature<\/code>, I\u2019d override all of the Sequence<\/code> methods (possibly without even inheriting from Sequence<\/code>) to redirect to the internal tuple so that the less efficient mixin methods aren\u2019t used. But, for the sake of conciseness, I did the shortest, easiest way to create a sequence.<\/p>\nFunctionSignature<\/code> versus OutParameter<\/code>, but that length is a one-time thing versus the length of all the with<\/code> blocks that use it. And we only saved a few characters on one line within the with<\/code> block. Still, I like this idea more overall, since I feel like it puts a smaller mental burden on the user writing the with<\/code> block. I could be wrong. What do you think?<\/p>\nUse the
contextmanager<\/code> Decorator<\/h2>\ncontextmanager<\/code> decorator<\/a> in the contextlib<\/code> module. It makes writing the manager much easier, and it still works just fine with OutParameter<\/code> and FunctionSignature<\/code>.<\/p>\nLimitations<\/h2>\n
with] blocks for multi-line lambdas, there are still plenty of limitations, one of which was actually introduced by adding the ability to 'return' values.<\/code><\/p>\nCan Only Be Called Once<\/h2>\n
with<\/code> block lambda, the block is only called once; between one call to __enter__()<\/code> and one call to __exit__()<\/code>.<\/p>\nThere is No Function Object Involved<\/h2>\n
with<\/code> block is not turned into a callable object that can be passed around. This means it can\u2019t be passed further into more specific functions and such.<\/p>\nHarder to Reuse Existing Functions<\/h2>\n
with<\/code> blocks don\u2019t accept functions and lambdas. So you can\u2019t just pass an already-defined function in to be used. To use a function, with arguments and return values, it would look like this:<\/p>\nwith cm as args:\r\n args._return(some_func(*args))<\/pre>\n
cm(some_func)<\/code>. Now, you could<\/i> define the function in such a way that, if it does receive a function or lambda, it doesn\u2019t go into \u201ccontext manager mode\u201d.<\/p>\nThe Highlander Problem<\/h2>\n
with<\/code> block. I\u2019m pretty sure there\u2019s no way around this. If there is a way, I\u2019m certain that it\u2019s nearly impossible to read.
\nObviously, actual lambdas can be passed in, but that doesn\u2019t help the situation a ton.<\/p>\nReturns That Don\u2019t Return<\/h2>\n
_return()<\/code> method, it doesn\u2019t exit out of the block. You\u2019ll have to use other control flow techniques to make sure that\u2019s the last thing called. Also, please don\u2019t try and be clever by purposely having code run after the return; that will just confuse readers more.<\/p>\nwith<\/code> Statements Aren\u2019t Expressions<\/h2>\nwith<\/code> statements don\u2019t return anything that can be used outside of themselves. This hurts functional programming, since it makes the code obviously impure.<\/p>\nOutro<\/h2>\n
with<\/code> blocks. Remember the disclaimer at the top when it comes to making comments. I\u2019m particularly proud of this one, even if it\u2019s usually a bad idea. Thinking around languages like this is something I particularly enjoy doing, and I hope there are others out there that do, too.<\/p>\n