Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Asterisks in Python

treyhunner.com

Post reply on HN
Print view View original

71–80 of 110 posts

Re: Asterisks in Python

#71

Post by taneq »

the_clarence wrote: post #36
th0ma5 wrote: post #2

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.

I never understand why people feel the need to find shortcuts. It’s like reading smthg[i++] in C. It’s not clear and it could be clearer if written over two lines instead but yet everyone does it.

It's perfectly clear and unambiguous. For some reason everyone loves it when functional languages are 'pithy' but hates it when C-like languages are equally terse.

Re: Asterisks in Python

#72

Post by dorfsmay »

soVeryTired wrote: post #21
th0ma5 wrote: post #2

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?

It used to be for performance reasons, the way python runs comprehension is faster than plain loops, so the more you could cram in a single comprehension, the faster it ran.

These days though, you can split it in generator expressions and make it run at the end inside a comprehension, and you get best of both worlds: splitting helps readability, running it all at once in a single comprehension at the end keeps it performing.

Re: Asterisks in Python

#73

Post by aequitas »

pavlov wrote: post #28
zmmmmm wrote: post #10

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!

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…

At least the kwargs word is googleable. So it is relatively easy to find documentation. Unlike list comprehensions which are really hard to google until you know the name.

Re: Asterisks in Python

#74

Post by jacobush »

zmmmmm wrote: post #10

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!

I feel you, however I also love https://github.com/Knio/dominate - a Python library to generate HTML.

Generating HTML always felt awkward for me in many languages. From PHP where you sprinkle PHP between HTML or HTML between PHP, to frameworks in various languages where you populate variables and HTML is magically generated.

Somewhere in between there are template languages.

"Dominate" uses Python itself as the template language - this means there never is that "disconnect" where you have to validate your output, neither is it that disconnect coming from generators, nor do you have to learn and use a separate template language. Dominate can look like this:

    return hr(), p(
        a(
            'Start',
            href = '/start'
        ),
        style = 'text-align: center;'
    )
If the Python is valid, so is the HTML.

For me it hit a sweet spot. Dominate uses kwargs. I discovered this and (a?)bused kwargs when I wanted to add some tags of my own.

Re: Asterisks in Python

#75

Post by masklinn »

reachtarunhere wrote: post #61

The single * way to specify keyword only arguments is a total monstrosity.

It's a logical and consistent outgrowth of the existence of *args, and having (finally) allowed parameters after that (which would be keyword-only). I'm sure you could make up other ways to do it, but not that they'd be any better.

Re: Asterisks in Python

#76

Post by masklinn »

ereyes01 wrote: post #60
the_clarence wrote: post #35

Earlier quoted context omitted.

Same with Golang: A := []int{1,2} B := append(A, A...) fmt.Println(B) > [1, 2, 1, 2]

Golang has no equivalent to double-* since it doesn't do keyword arguments.

Neither does javascript, "keyword expansion" only occurs for object literals (which is why it's unambiguous: objects can't be created from sequences and don't implement the iteration protocol, so expansion within an object context can easily be special-cased).

Re: Asterisks in Python

#77

Post by masklinn »

tln wrote: post #3

Whats with the / in the help for sorted? Help on built-in function sorted in module builtins: sorted(iterable, /, *, key=None, reverse=False)

It's a documentation-only (currently, I remember seeing posts on python-dev to add it as a python-level construct but I don't believe that's been implemented) to document positional-only parameters, a feature currently only available to "native" functions.

Basically, at the C level you can define positional-only parameters such that sorted can not be called as `sorted(iterable=xxx)`, and this was specified using a "/" in argument clinic (https://www.python.org/dev/peps/pep-0436/#special-syntax-for...) and now appears in some docstrings. This is pretty common in builtins e.g. you can't give a name to the first argument of `max`, it doesn't have one (except informally).

Anything before the / is positional-only (the name is informational but not definitional), between / and * it's both positional and keyword, and after * (or *args) it's keyword-only.

Re: Asterisks in Python

#78

Post by masklinn »

setr wrote: post #69
nercht12 wrote: post #44

Earlier quoted context omitted.

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…

f-strings are also unusable for i18n.

Re: Asterisks in Python

#79

Post by olavk »

zmmmmm wrote: post #10

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!

True, Python allows a lot of crazy hacks like monkeypatching, dynamically creating classes and so on. It is there if you need it. It is not like in Java where those things are simply impossible. The Python culture on the other hand discourages obscure hacks and unreadable cleverness, and the language is generally designed to encourage the straightforward and readable solution. I don't really see a contradiction in that.

You cannot prevent people from doing stupid things anyway. What you can do is encourage good style, and making the "right way" the path of least resistance. You can write readable code in any language, even Perl, if you use enough effort and discipline, but Python tries to make readable code the easy default.

The "quote" you made up is not representative of the Python culture or the article here, although I'm sure you can find some blogger somewhere with that attitude. They seem to have mostly migrated to other more hip languages though.

Re: Asterisks in Python

#80

Post by sevensor »

jacobush wrote: post #74
zmmmmm wrote: post #10

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!

I feel you, however I also love https://github.com/Knio/dominate - a Python library to generate HTML. Generating HTML always felt awkward for me in many languages. From PHP where you sprinkle PHP between HTML or HTML between PHP, to frameworks in various languages where you populate variables and HTML is magically generated. Somewhere in between there are template languages. "Dominate" uses Python itself as the templ…

Oooh, that's nice. Thanks for sharing this. I like how it merges your mental model for HTML with Python in what feels like a very unsurprising way.
Post reply on HN