Maybe it's just my background in logic programming and resulting love for pattern-matching assignment, but this seems to be one of those features that you never think you'd use until you have opportunity to use it, and then you start seeing opportunities to use it everywhere. When reading code, it reduces the line-noise effect of the explicit slicing and makes your intention that much easier to discern. When writing code, it lets you express your intention directly and then get on with the business of handling the data. The ability to compress this into a clean one-liner might seem trivial, but I'm already finding it a significant win. But in Python 3, you can now use the starred-variable syntax familiar from function argument definitions to say "put all the unmatched elements into this variable": > items = Python's slicing syntax makes this bearable, but still pretty ugly: > items = But if you want to unpack only certain elements of the list, you're stuck doing the unpacking yourself. This is a very elegant technique, assuming you know how many items are in the list and want each of them in a separate variable. In Python 2, you can automatically unpack a list/tuple/iterable into a series of variables using a single assignment statement: > a,b,c = Instead, I wanted to share a small joy I've found in Python 3 that I'm already missing in Python 2: extended iterable unpacking. There has been some good-natured debate about the pros and cons of switching from the 2.x series, focused mostly around the big-ticket changes like better Unicode handling (pro) and breaking compatibility with all existing Python libraries (con). Hope you enjoyed the read.If you care about these things, you probably already know: Python 3 was released last week to much fanfare. Not enough attention is being given to them (e.g: I only learned about Python 3 keyword only arguments syntax a week ago, while it was around since python 3.0) – hence, this article. The addition is really small, but I find it convenient, and I am under the impression that the small features like this combined together are actually a crucial part of the overall Python programming experience. This does not seem like a needed feature though. Synta圎rror: iterable argument unpacking follows keyword argument unpacking One limitation that is still valid, is that you cannot mix the order of iterable and keyword arguments:Īny_arg_combination(*al1, **ad1, *al2, **ad2) TypeError: keywords() got multiple values for keyword argument '1' TypeError: keywords() keywords must be strings Now it just works, and corner cases seem to follow the principle of least surprise: Previously, if you wanted to combine two dictionaries, you had to either call the update method, or use collections.ChainMap. The dictionary unpacking changes are in similar fashion. Synta圎rror: can use starred expression only as assignment target It is also possible to have arbitrary number of unpacking operations in a function call: In python 3.5 though, this will just work as expected: To make it work as desired, we would have to turn the received args tuple into a mutable object (possibly list), append to it, and then pass it forward, or use itertools.chain – both solutions adding boilerplate code. > Synta圎rror: only named arguments may follow *expression If the order is important though, we’re out of luck, prior to python 3.5, trying to call: In case of positional arguments we can, just stick it in front: Will output (notice that positional arguments are tuples, which are immutable, whereas keywords are mutable dicts):īut suppose that we are not operating on explicit arguments, but we’ve already received a tuple or dictionary, and want to pass it forward with some modification – this is not an exceptionally rare problem – it can occur for example when writing function decorators. It’s all cool if you call those functions while providing arguments explicitly:Īny_arg_combination(1, 2, 3, a=1, b=2, c=3) # tip for the uninitiated - kwargs stands for keyword arguments.ĭef any_arg_combination(*args, **kwargs): You’re probably familiar with functions taking variable number of either positional of keyword arguments: The new feature – described in detail in PEP 0448 is really simple. Still, I think python is often perceived as a very succinct and readable language – and the inclusion of those unpacking generalizations make it even more so, and deserve a short article. Among definitely more complex enhancements like async/await, type hinting support, Windows C-runtime and installer changes, it might be easily overlooked. Python 3.5 – the latest major release of my favorite programming language comes with a few handy additions – one of which is a small new convenience feature I wanted to write about today.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |