What's Coming in Python 3.8

Post by kbd » Fri, Jul 19, 2019, 6:55 PM UTC

brummm wrote: post #485

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 think in certain situations the walrus operator will probably be useful. But it definitely makes code less legible, which makes me cautious. The only useful use case I have found so far is list comprehensions where some function evaluation could be reduced to only one execution with the walrus operator.

    foos = []
    foo = func(a,b,c,d)
    while foo:
       foos.append(foo)
       foo = func(a,b,c,d)

    foos = []
    while foo := func(a,b,c,d):
        foos.append(foo)

Post by marmada » Sat, Jul 20, 2019, 12:42 AM UTC

orf wrote: post #312

marmada wrote: post #241

Earlier quoted context omitted.

I never felt like there was only one way to do something in Python. Every Stack Overflow question has a multitude of answers ranging from imperative to functional style and with various benefits and drawbacks. Python is one of the least "only one way to do things" languages I've used. This even extends to its packaging system, where you can choose between virtualenv, pipenv, pyenv, etc. Same goes for the installation…

Packaging isn’t really anything to do with the language syntax, or the zen of Python. Any critiques on Python-the-language? And pyenv is just a version manager, like rbenv or nvm. I wouldn’t consider its existence confusing, not would I say being able to install something in more than 1 way has any relevance to the zen of Python! Should Python create some cross-platform Uber-installer so that there is only one downlo…

Post by heavenlyblue » Sun, Jul 21, 2019, 10:59 PM UTC

uranusjr wrote: post #515

heavenlyblue wrote: post #486

Earlier quoted context omitted.

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…

Post by JoBrad » Mon, Jul 29, 2019, 12:59 PM UTC

bpchaps wrote: post #308

stefco_ wrote: post #215

Earlier quoted context omitted.

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…

Here's a clean way to do that: str_fmt = "File exists, not uploading: {filename} -> {bucket}, {key}" fmt_vals = dict(filename=filename, bucket=bucket, key=key) raise ValueError(str_fmt.dedent().format(**fmt_vals))

  raise ValueError(“File exists, not uploading: {filename} -> {bucket}, {key}”.format(**locals()))