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

391–400 of 558 posts

Re: What's Coming in Python 3.8

#391

Post by sammorrowdrums »

fny wrote: post #224
heydenberk wrote: post #172

Earlier quoted context omitted.

I'd used f-string-like syntaxes in other languages before they came to Python. It was immediately obvious to me what the benefit would be. I've used assignment expressions in other languages too! Python's version doesn't suffer from the JavaScript problem whereby equality and assignment are just a typo apart in, eg., the condition of your while loop. Nonetheless, I find that it ranges from marginally beneficial to ma…

I love string interpolation! But this seems to take it to a bizarre level place just to save a few keystrokes. Seriously, how is f"{now=!s}" substantially better than f"now={str(now)}"? Ergonomically, I see little benefit for the added complexity.

It really feels like it's very explicit at this point that you want to cast whatever value interpolated into your format string to a string...

I don't want a type error for the most clear use case, in the same way I don't want one for print, because if I wanted a behaviour other than the basic string representation then I would still need to call something differently anyway.

Given that explicit control of the __str__ method is also baked into the language it's also very clear what to expect.

I like type errors when handling something like '1' + 1 because the JavaScript alternative is surprising and hides bugs. No surprises that a string formatter would coerce to string for me automatically (although I get that's maybe just personal feeling).

I love the f strings, they have made my codebase cleaner and clearer. Definitely a pythonic win.

Re: What's Coming in Python 3.8

#392

Post by mixmastamyk »

orf wrote: post #297
mixmastamyk wrote: post #277

Earlier quoted context omitted.

if logger.isEnabledFor(logging.DEBUG): logger.debug(f'{expensive_func()}')

I hope that’s a joke, because that is a verbose and ridiculous way of duplicating the work that the logging module does, while also making the code less readable and maintainable!

That’s how you defer an expensive function. The fstring part is the joke.

Re: What's Coming in Python 3.8

#393

Post by bluecalm »

ericdevries wrote: post #106
txcwpalpha wrote: post #97

Earlier quoted context omitted.

This honestly makes it seem more confusing to me. The fact that there is now an operator that can only be used in certain statements just makes things more confusing. And if there really is no overlap, then why wasn't the "=" operator just extended to also work in expressions? "while chunk = read()" seems like it makes just as much sense without adding the confusion of another operator.

One of the good things about not using the "=" operator is that you cannot accidentally turn a comparison into an assignment, a feature that is a common cause of errors in other languages that do support it. By adding a completely different character to the operator it is not very likely to cause bugs, compared to just forgetting to type that second =

Is it really that common? I made this typo a few times in my life. It was corrected every time before the program actually run because the compiler warned me about it. I don't see how you can make this mistake if you're not aggressively trying (by turning off warnings for example).

Re: What's Coming in Python 3.8

#394

Post by dwaltrip »

londons_explore wrote: post #70

I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…

All human languages change over time. It is the nature of language.

Re: What's Coming in Python 3.8

#395

Post by Dylan16807 »

stefco_ wrote: post #215
bulatb wrote: post #181

Earlier quoted context omitted.

> If `str.dedent` was a thing Have you looked at textwrap.dedent?

Yes! `textwrap.dedent` is great. On further reflection `wrap` is actually more useful for this kludge (see below). But my point is that that's a whole import for a kludge. Compare the f-string ideal (by my standards): raise ValueError("File exists, not uploading: " f"{filename} -> {bucket}, {key}") ...which is short enough that it's readable, and it's clear where exactly each variable is going. It's the single obviou…

f-strings are nice, but when the problem is indenting too far, what if you just... didn't do that?

  raise ValueError(("File exists, not uploading: {filename} -> "
      "{bucket}, {key}").format(filename=filename, bucket=bucket, key=key))

Re: What's Coming in Python 3.8

#396

Post by joshuamorton »

Animats wrote: post #96

The title made me think "Be afraid. Be very afraid". But it's all little stuff. Unchecked type annotations remain the worst addition since 3.0. Actual typing might be useful; it allows optimizations and checking. But something that's mostly a comment isn't that helpful.

If you don't like unchecked annotations, then check them. It's not hard to do.

Re: What's Coming in Python 3.8

#397

Post by choppaface »

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.

Was the walrus operator really worth "The PEP 572 mess"? https://lwn.net/Articles/757713/

That post makes a few things very clear:

* The argument over the feature did not establish an explicit measure of efficacy for the feature. The discussion struggled to even find relevant non-Toy code examples.

* The communication over the feature was almost entirely over email, even when it got extremely contentious. There was later some face-to-face talk at the summit.

* Guido stepped down.

Re: What's Coming in Python 3.8

#399

Post by Dylan16807 »

pmontra wrote: post #273
duckerude wrote: post #185

Earlier quoted context omitted.

f-strings need a prefix so old strings can keep working the same way. If `print("{x}")` printed "{x}" in Python 3.5, it shouldn't print something else in a newer version. But `print(f"{x}")` was a syntax error before f-strings, so no code is broken by giving it a meaning. JavaScript can't interpolate ordinary strings either, for the same reason. You need to use backticks (``).

You're correct about JavaScript. I forgot about the backticks. Thank you for the explanation of the f-strings. I'm pretty sure that migrating old strings to "\{x\}" could be automated but we can't force everybody to migrate their code. There is probably no other way than the one they followed.

It's also just safer. You want your default string type to have as few gotchas about what can be put in it as possible.

Re: What's Coming in Python 3.8

#400

Post by stefco_ »

colechristensen wrote: post #157
londons_explore wrote: post #70

I long for a language which has a basic featureset, and then "freezes", and no longer adds any more language features. You may continue working on the standard library, optimizing, etc. Just no new language features. In my opinion, someone should be able to learn all of a language in a few days, including every corner case and oddity, and then understand any code. If new language features get added over time, eventua…

This is why a lot of scientific code still uses fortran, code written several decades ago still compiles and has the same output. How long has the code which was transitioned to python lasted?

This isn't that good of a metric for code utility. Sure, very-long-lived code probably solved the problem well (though it can also just be a first-mover kind of thing), but a lot of code is written to solve specific problems in a way that's not worth generalizing.

I write a lot of python for astrophysics. It has plenty of shortcomings, and much of what's written will not be useful 10 years from now due to changing APIs, architectures, etc., but that's partly by design: most of the problems I work on really are not suited to a hyper-optimized domain-specific languages like FORTRAN. We're actively figuring out what works best in the space, and shortcomings of python be damned, it's reasonably expressive while being adequately stable.

C/FORTRAN stability sounds fine and good until you want to solve a non-mathematical problem with your code or extend the old code in some non-trivial way. Humans haven't changed mathematical notations in centuries (since they've mostly proven efficient for their problem space), but even those don't always work well in adjacent math topics. The bra-ket notation of quantum mechanics, , was a nice shorthand for representing quantum states and their linear products; Feynman diagrams are laughably simple pictograms of horrid integrals. I would say that those changes in notation reflected exciting developments that turned out to persist; so it is with programming languages, where notations/syntaxes that capture the problem space well become persistent features of future languages. Now, that doesn't mean you need to code in an "experimental" language, but if a new-ish problem hasn't been addressed well in more stable languages, you're probably better off going where the language/library devs are trying to address it. If you want your code to run in 40 years, use C/FORTRAN and write incremental improvements to fundamental algorithm implementations. If you want to solve problems right now that those langs are ill-suited to, though, then who cares how long the language specs (or your own code) last as long as they're stable enough to minimize breaking changes/maintenance? This applies to every non-ossified language: the hyper-long-term survival of the code is not the metric you should use (in most cases) when deciding how to write your code.

My point is just that short code lifetimes can be perfectly fine; they can even be markers of extreme innovation. This applies to fast-changing stuff like Julia and Rust (which I don't use for work because they're changing too quickly, and maintenance burdens are hence too high). But some of their innovative features will stand the test of time, and I'll either end up using them in future versions of older languages, or I'll end up using the exciting new languages when they've matured a bit.

Post reply on HN