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

101–110 of 110 posts

Re: Asterisks in Python

#101

Post by setr »

nercht12 wrote: post #98
setr wrote: post #69

Earlier quoted context omitted.

>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…

> not really: Yes it does. You could construct the string using a for-loop. Thank you for proving my point and then down-voting me.

...if you’re going down that route, you could claim that any feature not necessary for turing completeness conflicts with the one way to do it strategy, since you could alternatively build up whatever feature from scratch, thus offering additional solutions

But practically, there remains (close to) one obvious way to do things, with the choice boiling down to whether or not to name your outputs before string construction (and the choice of f-string vs format naturally falling out). But thats always been a choice.

On a side note: I don’t use comment voting systems, for up or down votes, on pretty much any site including HN. Even if I did, I don’t see why you’d care

Re: Asterisks in Python

#102

Post by [deleted] »

kbp wrote: post #52
jetrink wrote: post #23

Earlier quoted context omitted.

It's useful for working with permutations. E.g, [f(a, b) for a in some_list for b in some_list] or even [f(a, b) for a in some_list for b in some_list if a is not b]

itertools has functions that make that sort of nesting unnecessary (and some would say make the code clearer), eg: import itertools as it [f(a, b) for a, b in it.product(some_list, some_list) if a is not b]

[deleted]

Re: Asterisks in Python

#103

Post by kbp »

kbp wrote: post #52
jetrink wrote: post #23

Earlier quoted context omitted.

It's useful for working with permutations. E.g, [f(a, b) for a in some_list for b in some_list] or even [f(a, b) for a in some_list for b in some_list if a is not b]

itertools has functions that make that sort of nesting unnecessary (and some would say make the code clearer), eg: import itertools as it [f(a, b) for a, b in it.product(some_list, some_list) if a is not b]

Oh, or more directly:

    [f(a, b) for a, b in it.permutations(some_list, r=2)]
And then you could also use itertools.starmap instead of using a comprehension at all, if you wanted.

Re: Asterisks in Python

#104

Post by nercht12 »

setr wrote: post #101
nercht12 wrote: post #98

Earlier quoted context omitted.

> not really: Yes it does. You could construct the string using a for-loop. Thank you for proving my point and then down-voting me.

...if you’re going down that route, you could claim that any feature not necessary for turing completeness conflicts with the one way to do it strategy, since you could alternatively build up whatever feature from scratch, thus offering additional solutions But practically, there remains (close to) one obvious way to do things, with the choice boiling down to whether or not to name your outputs before string construc…

> if you’re going down that route, you could claim that any feature not necessary for turing completeness conflicts with the one way to do it strategy

I suppose one could do that, philosophically if not practically. What I had in mind was the various syntax sugars used for the same thing, particularly in Ruby. While some ways of doing things in Ruby were convenient, there was a host of other "shortcuts" that added to the confusion, and it was evident that it was the design of the language itself - not an accident - that allowed these shortcuts, at least imo.

> On a side note: I don’t use comment voting systems

I had a feeling you might say that, but I'd already clicked the "reply" button. Sorry for being presumptuous.

Not that I care about the voting system either, but people tend to use it as a cowardly way of showing disapproval.

Re: Asterisks in Python

#105

Post by taneq »

the_clarence wrote: post #97
taneq wrote: post #71

Earlier quoted context omitted.

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.

How? Smthg[i++] and smthg[++i] have two different behaviors. If you tell me that this is clear I probably don't want to read your code.

They're two different things. Are you going to complain that a/b and b/a give different results?

Re: Asterisks in Python

#106

Post by BerislavLopac »

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!

The Zen of Python clearly states:

    There should be one-- and preferably only one --obvious way to do it.
I think that "obvious" is the key word here -- it says nothing about the non-obvious ways, nor about which ones are better.

The problem here is not with Python itself, but with people looking for a silver bullet which will solve all their problems. In Python, this is presently very obvious with async programming, and people insisting on using it for everything; however, async is useful for only a certain subset of problems one might encounter (and in a few cases it's incredibly useful) while in most situations it adds avoidable complexity. However, this approach is definitely not limited to Python, and every language has its own examples (classes vs prototypes in Javascript is one example).

My advice is: use what you're comfortable with; don't be afraid of learning new techniques, but don't feel obligated to use them at all costs; ignore the Kool Kidz™ pushing fads.

Re: Asterisks in Python

#107

Post by wodenokoto »

sooheon wrote: post #26
cpsempek wrote: post #22

> 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`.

I'm not the sharpest functional programmer in the cohort, but isn't `apply` a parallelizable for-loop?

    apply(l, print)
is the same as

    for el in l:
      print(el)
which is a number of print statements, rather than 1 print statement with a number of arguments.

Re: Asterisks in Python

#108

Post by the_clarence »

taneq wrote: post #105
the_clarence wrote: post #97

Earlier quoted context omitted.

How? Smthg[i++] and smthg[++i] have two different behaviors. If you tell me that this is clear I probably don't want to read your code.

They're two different things. Are you going to complain that a/b and b/a give different results?

You're comparing mathematics term which have been established since before your grandfather was born with a peculiarity of the C language that confuse more people than it helps. People willing to Obtain a small amount of LOC for less clarity deserves neither.

Re: Asterisks in Python

#109

Post by cbcoutinho »

yxhuvud wrote: post #66
pavlov wrote: post #28

Earlier 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…

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.

Funny, in Dutch we call it kwark

Re: Asterisks in Python

#110

Post by olavk »

weberc2 wrote: post #100
olavk wrote: post #92

Earlier quoted context omitted.

Is that really true? Sure you can write cryptic code using operator overloads, but the convention is to only use them in cases where they improve readability. For example numpy code would be a lot less maintainable without operator overloading IMHO. I haven't written numerical code in Go but I am skeptical it will be as maintainable without operators. The lack of a particular feature does not in itself make code more…

It's been true in my experience. Operator overloads are marginally beneficial and for some reason they're prone to be abused. Put differently, `Add(x, y)` isn't any less maintainable than `x + y`, but the former is pretty much never abused, while the latter is a popular abuse target. I've been writing Python and Go extensively for the last 10 and 5 years respectively. I really recommend giving Go a shot; you can pick…

Oh I know Go, just haven't used it for numerical tasks.

If Add(x, y) is just as maintainable as x + y, why does Go use operators for the regular numeric types? Why have + at all?

Post reply on HN