The single * way to specify keyword only arguments is a total
monstrosity.
Asterisks in Python
61–70 of 110 posts
Re: Asterisks in Python
#62Re: Asterisks in Python
#63Earlier quoted context omitted.
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!
For reference, this feature is Formatted String Literals ("f-strings"). https://docs.python.org/3/reference/lexical_analysis.html#fo...
Of course I didn't read your comment until several Google searches later.
Re: Asterisks in Python
#64Earlier quoted context omitted.
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?
People who come from math backgrounds often becomes infatuated with complicated list comprehensions when they realize that they can be used as set-builder notation. {(x,y) for x in range(10) for y in range(10) if y == 2*x}
I use stuff like that. But my rule of thumb is that I try and make it readable by breaking it up into multiple lines and using indentation. If I can't make it readable, then I will consider another way of writing it. This is mainly for self preservation, since I'm likely to be the person who has to read it later.
Re: Asterisks in Python
#65Earlier quoted context omitted.
This is one of the things that gets me about Python. It makes this big noise about being a super-friendly form of executable pseudocode, but then you open any code example and the first thing you see is two asterisks and the mysterious word "kwargs" (a Swedish dessert perhaps?). I wouldn't mind except for all the haughty pretense about Python being a language that doesn't do this sort of thing. Dear Python, get a gri…
Key word arguments. And I would consider the pythonic approach to be more pragmatic than anything. The language isn't haughty, it just does what it's told. That being said, you've provided a perfect example of what haughty looks like.
In the parent’s defense, people write a lot more cryptic Python than they do other languages. There are no metaclasses in Go nor abused operator overloads or half-baked DSLs. People don’t use dictionaries as structs to hang off whatever they like.
It’s kind of a penny wise and pound foolish approach. Arguably it’s not python’s fault, but that’s a poor consolation for folks who have to deal with these messes.
Re: Asterisks in Python
#66This 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!
This is one of the things that gets me about Python. It makes this big noise about being a super-friendly form of executable pseudocode, but then you open any code example and the first thing you see is two asterisks and the mysterious word "kwargs" (a Swedish dessert perhaps?). I wouldn't mind except for all the haughty pretense about Python being a language that doesn't do this sort of thing. Dear Python, get a gri…
Aside: Swedish does have the word 'kvarg', which is a product made out of sour milk. Some people eat it for breakfast but personally I can't stand it.
Re: Asterisks in Python
#67Earlier 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.
def apply(f, a):
return f(*a)Re: Asterisks in Python
#68my 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.
My frustration with locals() and globals() is the same with "from foo import *" It's really difficult to move that code around or clean up variables because their use is obscured. The worst is when your template variable is defined somewhere else.
Re: Asterisks in Python
#69Earlier quoted context omitted.
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!
Taken straight out of Ruby, I see. Very convenient feature (and one of my favorites about Ruby), though it does contradict the do-it-one-way mentality.
>though it does contradict the do-it-one-way mentality.
not really: use f-strings when you're passing in variables as-is (or nearly no work), and format() when you need to do work on them before stringifying them; f-strings are naturally (and obviously) more difficult to read when the variables are big, as it obscures the actual text they're being fit into, and where.
The only natural area for preference to apply is whether to do the work before the format() call, name the variables, and change it to an f-string.. or stick with a multi-line format()
I'm not sure theres any real situation where the choice isn't obvious. Maybe if you're doing something like f"list1: {sorted(a)}\nlist2{sorted(b)}", where the work is rather small, but even then f"list1:{}\nlist2:{}".format(sorted(a), sorted(b)) is just as nice, or rather unsatisfying, as the f-string.
Re: Asterisks in Python
#70I'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?
Multiple for loops in list comprehensions (if that's what's meant by "multi-level") are pretty straightforward once you realise the simple rule that translates them into loops: write everything to the right of the expression in the same order with nesting. For example this:
l = [f(x, y) for x in X for y in Y if x > y]
l = []
for x in X:
for y in Y:
if x > y:
l.append(f(x,y))
l = [
f(x, y)
for x in X
for y in Y
if x > y
]