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

What's Coming in Python 3.8

lwn.net

Post reply on HN
Print view View original

511–520 of 558 posts

Re: What's Coming in Python 3.8

#511

Post by kragen »

Izkata wrote: post #509
kragen wrote: post #483

Earlier quoted context omitted.

It's surprising to me that there are people who disagree with my opinion about this, but it suggests that my familiarity with Python has damaged my perspective. You're clearly much less familiar with Python (this code doesn't contain any list comprehensions, for example), so I think your opinion about readability is probably a lot more objective than mine.

> this code doesn't contain any list comprehensions, for example It does contain a generator expression though, which is the same as a list comprehension in general structure, but slightly more confusing because it doesn't have the relationship to lists that square brackets in a list comprehension would have given it.

Yes, it shares the structure of a list comprehension, but has different semantics. In this case a listcomp would have worked just as well.

My point, though, was that not being able to tell the difference was a key "tell" that the comment author was not very familiar with Python — in some contexts, that would tend to undermine credibility in their comment (and then it would be rude to point it out), but in this context, it probably makes their opinion more objective.

Re: What's Coming in Python 3.8

#512

Post by DangitBobby »

knome wrote: post #271
stakhanov wrote: post #56

Earlier quoted context omitted.

It's wrong to frame this as resistance to change for no reason. See my other comment. I see some of this stuff as repeating mistakes that were made in the design of Perl. ...but there are quite few people around these days who know Perl well enough to recognize the way in which history is repeating itself, and that has at least something to do with age.

"resistance-to-change for-no-reason" vs "resistance-to change-for-no-reason" :)

This is possibly the best example of the ambiguity of language I've ever seen. Two contradictory meanings expressed in the exact same phrase, and both of them are valid in the broader context.

Re: What's Coming in Python 3.8

#513

Post by DangitBobby »

kragen wrote: post #483
elcritch wrote: post #377

Earlier quoted context omitted.

I disagree this python version is as readable and here’s why. It’s about as many characters but more complex. The Kotlin version performs several distinct actions, each being clear to its purpose. These actions have the same syntax (eg requires less parsing effort). The Python version mixes at least 4 different language syntax/features, being list comprehension, if special form in the list comprehension, keywords, an…

It's surprising to me that there are people who disagree with my opinion about this, but it suggests that my familiarity with Python has damaged my perspective. You're clearly much less familiar with Python (this code doesn't contain any list comprehensions, for example), so I think your opinion about readability is probably a lot more objective than mine.

FWIW most of the programming I've ever done has been in Python, and while I have no trouble understanding either snippet, I think that the Kotlin snippet is much clearer in intent and structure.

Re: What's Coming in Python 3.8

#514

Post by vkaku »

vkaku wrote: post #427
hyperion2010 wrote: post #384

Earlier quoted context omitted.

That particular version opens the way for massive typo footguns and results in the insanity of defensive programming patterns like yoda expressions.

Well, for those used to those expressions, it definitely helps write that code with one line lesser (assignment by itself). Most likely, the assigned value is stored for use in one of the conditionals, so it really doesn't change any of that. Let's also understand that we are dealing with a decorated assignment here, so a = (b = c) should be no different from evaluating (b = c). It's not complicated, the way I at lea…

But now I see your point. A language must not give beginners an option to shoot themselves in the foot.

Re: What's Coming in Python 3.8

#515

Post by uranusjr »

heavenlyblue wrote: post #486
hjk05 wrote: post #463

Earlier quoted context omitted.

They could... but then they wouldn’t return the interpolated string, and they’d be just like using format, just saving the characters “.format” which ruins the exact thing people like about them.

Nah - you're clearly not using Python enough - the issue with current format is that of the identity of the arguments passed to it. I need to do 2 changes every time I change a format string - I need to remove the symbol representing it's placement and then I need to remove the argument passed to .format. Also old formatting does not easily support arbitrary expressions in the placements, thus in order to get those y…

I struggle to understand how what you talked about is relevant here. The problem parent talked about is how this laziness could be implemented without losing what makes f-string awesome right now. It’s not viable, which backs my reasoning why at least one alternative format method is required.

That said, I also struggle to understand how you’d claim parent clearly not using Python enough, when your description of str.format shows a lack of understanding to it yourself. One of the advantages of str.format over %-formatting is exactly that you do not need to modify the arguments passed to str.format when removing components from the source string:

    >>> '{0} {1} {2}'.format('a', 'b', 'c')
    'a b c'
    >>> '{0} {2}'.format('a', 'b', 'c')
    'a c'
Or preferably (using keyword arguments instead of positional):

    >>> '{x} {y} {z}'.format(x='a', y='b', z='c')
    'a b c'
    >>> '{x} {z}'.format(x='a', y='b', z='c')
    'a c'
But again, this doesn’t matter to parent’s argument. Nobody is arguing with you that f-string is better than alternatives for what it can do; we are trying to tell you that there are things it can’t do, and you did not get it.

Re: What's Coming in Python 3.8

#516

Post by kazinator »

Grue3 wrote: post #492
jimktrains2 wrote: post #488

Earlier quoted context omitted.

I don't understand why you think print or log debugging is inherently bad. Also, it's part of the format string and not a special print function so that it can be used for logs and other output as well, not just the console.

>I don't understand why you think print or log debugging is inherently bad. I use it myself all the time, but it just shows the weakness of the tooling that people have to resort to such measures. Fortunately, some people are working on it [1]. >Also, it's part of the format string and not a special print function so that it can be used for logs and other output as well, not just the console. Since print (and hypothe…

That's poor compared to just logging.warning('Unusual situation', foo, bar).

I.e. since print isn't a statement, you can give other functions the same argument conventions that it has, instead of making the programmer use a string-generating shim.

Speaking of Common Lisp, it has functions other than format which take format arguments.

  $ clisp -q
  [1]> (error "value of ~s should be less than ~s" 'bloop 42)

  *** - value of BLOOP should be less than 42
  The following restarts are available:

Re: What's Coming in Python 3.8

#517

Post by dual_basis »

linsomniac wrote: post #206
kbd wrote: post #118

Despite controversy, walrus operator is going to be like f-strings. Before: "Why do we need another way to..." After: "Hey this is great". People are wtf-ing a bit about the positional-only parameters, but I view that as just a consistency change. It's a way to write in pure Python something that was previously only possible to say using the C api.

I've literally been wanting something like the walrus operator since I first started using Python in '97. Mostly for the "m = re.match(x, y); if m: do_something()" sort of syntax.

I mean, that isolated example doesn't really demonstrate the benefit of a walrus operator does it? You could have just written "if re.match(x, y): do_something()". If you re-used the result of computation within the if statement, I feel that would be a better example, eg. "m = re.match(x, y); if m: do_something(m)".

Re: What's Coming in Python 3.8

#518

Post by Sohcahtoa82 »

Scarblac wrote: post #425
Sohcahtoa82 wrote: post #161

Earlier quoted context omitted.

I see this criticism every time the walrus operator is brought up. You do know that this: x := 1 Is going to be a syntax error, right? The walrus operator is not permitted in the case of a simple assignment statement. It's only in an expression.

But it used to be that any expression on its own was a valid statement. Is that going to change? When is an expression allowed to have := in it, is (x := 1) on its own allowed?

Allowed, yes. But the PEP that introduced walrus operators says not to do it.

Every possible line of code has an alternate ugly way to write it. This isn't a valid criticism. Anyone who decides to start writing simple assignment statements like that deserves to be ridiculed for writing ugly code.

Re: What's Coming in Python 3.8

#519

Post by elcritch »

kragen wrote: post #511
Izkata wrote: post #509

Earlier quoted context omitted.

> this code doesn't contain any list comprehensions, for example It does contain a generator expression though, which is the same as a list comprehension in general structure, but slightly more confusing because it doesn't have the relationship to lists that square brackets in a list comprehension would have given it.

Yes, it shares the structure of a list comprehension, but has different semantics. In this case a listcomp would have worked just as well. My point, though, was that not being able to tell the difference was a key "tell" that the comment author was not very familiar with Python — in some contexts, that would tend to undermine credibility in their comment (and then it would be rude to point it out), but in this contex…

Good point, though it's less my familiarity with Python and more that I tend to simplify and call generator expressions as list comprehensions unless the laziness is important to call out (meta laziness there? ;) ). Mainly since L.C.'s were first and describing the differences is tedious.

Re: What's Coming in Python 3.8

#520

Post by kragen »

DangitBobby wrote: post #513
kragen wrote: post #483

Earlier quoted context omitted.

It's surprising to me that there are people who disagree with my opinion about this, but it suggests that my familiarity with Python has damaged my perspective. You're clearly much less familiar with Python (this code doesn't contain any list comprehensions, for example), so I think your opinion about readability is probably a lot more objective than mine.

FWIW most of the programming I've ever done has been in Python, and while I have no trouble understanding either snippet, I think that the Kotlin snippet is much clearer in intent and structure.

I certainly didn't mean to imply that only someone unfamiliar with Python could prefer the Kotlin version! Perhaps you thought I meant that, but I didn't.
Post reply on HN