41–50 of 110 posts
Earlier quoted context omitted.
Now how much nicer would it be if even more things were functions, rather than special syntax like here? This can be done with an `apply`.
I think the star syntax is a lot nicer than `apply`. Python actually had an `apply` builtin, but it was deprecated in Python 2.3.
So this is like the rest and spread operator in javascript (`...`). An interesting observation is that while python has separate operators for lists ( * ) and dictionaries ( * * )—javascript has only `...`. > You need to be careful when using multiple times though. Functions in Python can’t have the same keyword argument specified multiple times, so the keys in each dictionary used with must be distinct or an excepti…
In JavaScript, the surrounding syntatical context solely decides if it's an object or array splat. But since Python has 2 kinds of parameters, to preserve obviousness when reading code using splats, they went with 2 operators for each parameter kind, and then separated list and dictionary splat analogously.
Side note... Why does everything needs to be bold on that page? It made reading it very difficult.
It looks like this: https://i.imgur.com/AfEnDf0.png
And this is what it would look like if was bold. I fiddled in the devtools to make this: https://i.imgur.com/zQQR1gA.png
my favorite cheat is using locals() with string formatting something like this: def example_cheater(color, flavor, age): template = 'I am {age} years old and I like to wear {color} hats and eat {flavor} icecream' return template.format(**locals()) Obviously a contrived example, and it can be argued that using locals() is not very pythonic, but I think it makes the code look much nicer.
In python 3.6 and up, that becomes def example_cheater(color, flavor, age): return f'I am {age} years old and I like to wear {color} hats and eat {flavor} icecream' Even nicer!
> print(*more_numbers, sep=', ') This alone makes me appreciate print as a function in py3.
Now how much nicer would it be if even more things were functions, rather than special syntax like here? This can be done with an `apply`.
So this is like the rest and spread operator in javascript (`...`). An interesting observation is that while python has separate operators for lists ( * ) and dictionaries ( * * )—javascript has only `...`. > You need to be careful when using multiple times though. Functions in Python can’t have the same keyword argument specified multiple times, so the keys in each dictionary used with must be distinct or an excepti…
I suppose both observations are reminiscent of the fact that Python has language-level support for named parameters. Given that named and sequential parameters are treated differently everywhere in Python (sequential params must be provided, keyword args are optional, amongst other things), it would be extremely surprising behaviour if the run-time type of the value being spread determined what kind of spread happene…
The other reason to distinguish * and double-* is because * works with any iterable, and dicts are themselves iterables (of their keys). So you can actually use * on dicts, it just does something different:
>>> d = {'a': 1, 'b' : 2}
>>> [*d]
['a', 'b']
Earlier quoted context omitted.
I think the star syntax is a lot nicer than `apply`. Python actually had an `apply` builtin, but it was deprecated in Python 2.3.
Apply, and first class / higher order functions in general are good in languages where they compose well. Python's * won't compose well.
This is one of those areas where I find Python a little contradictory. About 50% of the time it's "explicit is better than implicit" and "there should be one and only one good way" and then the other half of the time it's "here's this cool feature for doing something you could do a different way that looks like hieroglyphics and nobody understands but you should totally use it because it's awesome!
It's not contradictory. You should never use args and kwargs unless you need them. Usually they're only needed in relatively rare situations, like A) when you're building a dictionary dynamically without knowing what the key names will be in advance B) when building a library where you want to allow people to subclass a parent class, but also reserve the right to change method signatures in the parent class without breaking the user code.
If developers are just using args and kwargs when calling one normal function from another then you should absolutely should not merge their pull requests until this gets removed.
my favorite cheat is using locals() with string formatting something like this: def example_cheater(color, flavor, age): template = 'I am {age} years old and I like to wear {color} hats and eat {flavor} icecream' return template.format(**locals()) Obviously a contrived example, and it can be argued that using locals() is not very pythonic, but I think it makes the code look much nicer.
In python 3.6 and up, that becomes def example_cheater(color, flavor, age): return f'I am {age} years old and I like to wear {color} hats and eat {flavor} icecream' Even nicer!
>>> pi = 3.14159; two = 2
>>> f"{two:02d} pi is {2*pi:.2f}"
'02 pi is 6.28'I've been programming with Python for over a decade. I mostly understand, but I do try to avoid when possible for maximum clarity. Expanding function variables is fine and clear enough, but multiple levels deep in a comprehension and it can get pretty thick to try and keep it all straight. This article is nice that it covers all the patterns I've seen.
Honest question: why would anyone make a list comprehension that's multiple levels deep? Isn't the purpose of comprehensions to provide quick-and-dirty inline for loops, where a full for loop is too verbose?