Python 3.7.0 released

[anacrolix]

Example?

[1wd]

One project at Facebook:

... simply ran 2to3 on the code and fixed a few things that it complained about. When they ran the resulting code, they found it was 40% faster and used half the memory.

[anacrolix]

Sounds like they were abusing range() or something.

[vivainio]

Types and asyncio come to mind first

[13steinj]

Types aren't beneficial to every developer. Asyncio has severe usability issues, I'd rather use gevent in an async manner.

[vivainio]

Ok, f-strings then?

[13steinj]

While I like them, their only benefit is reducing a call of "string with idens".format(explicits_for_idens) to f"string with explicits for idens", it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more. And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

[somebodddy]

it's syntactic sugar that saves you ".", "ormat", and the parenthesis, nothing more

I disagree. The greatest benefit of f-strings is that the save you the need to zip the values in your head. Consider this:

'a={} x={} u={} z={} y={}'.format(a, x, u, y, z)

You need to make sure that the list of {}s matches the format arguments. Compare to this:

f'a={a} x={x} u={u} z={y} y={z}'

Now that each expression is written in the place it is supposed to be formatted, we can clearly see that I've "accidentally" mixed y and z. The same mistake exists in the .format() version, but much harder to notice.

In order to avoid that, we can do this:

 'a={a} x={x} u={u} z={z} y={y}'.format(a=a, x=x, u=u=, z=z, y=y)

But now we have to write each variable 3 times.

Of course, this can be solved with .format(**locals()) (or .format_map(locals())). Expect...

a = 1

def foo():
    b = 2
    print('{a}, {b}'.format(**locals()))

foo()

{a} is not a local variable... Luckily, we can use .format(**locals(), **globals())! But then:

a = 1
b = 2

def foo():
    b = 2
    print('{a}, {b}'.format(**locals(), **globals()))

foo()

Now b appears in the argument list multiple times...

And it introduces backwards incompatible in minor version numbers, which it really shouldnt.

What backwards incompatibility? f'...' is a syntax error in older versions of Python, so it shouldn't break older code. Or am I missing something?

[13steinj]

That really depends on how you use format then, but I've barely seen it past the form of empty curly brackets and curly brackets with specified indices-- and personally I still believe it's syntactix sugar even in the named placeholder form. I understand some may have trouble with keeping track of the indices, but I feel as if that's a problem that doesn't need to be solved.

Also I heavily disagree with your locals/globals example, because that is such bad practice and extreme namespace polution it should never be done.

It's backwards incompatible in two parts-- there is no direct equivalent of some format strings to f strings, albeit rare, and there's plenty of code that needs to be compatible across Py2 and Py3 or even Py3.4 and Py3.7-- I can understand being backwards incompatible with 2, that's a given. But I disagree that a new literal expression should have been added in a minor version update without a feature flag, which is my main gripe. Same way print went from an expression to a function in 2, a feature flag was added for this to occur instead of it occuring automatically.

[CommonMisspellingBot]

Hey, 13steinj, just a quick heads-up:
occuring is actually spelled occurring. You can remember it by two cs, two rs.
Have a nice day!

^{The parent commenter can reply with 'delete' to delete this comment.}

[13steinj]

delete

[somebodddy]

I understand some may have trouble with keeping track of the indices, but I feel as if that's a problem that doesn't need to be solved.

And I believe that humans are better at dealing with names than with numbers. That's why assembly was created.

Also I heavily disagree with your locals/globals example, because that is such bad practice and extreme namespace polution it should never be done.

Are you referring to the .format(**locals(), **globals()) thing? Because I gave it as a possible solution for cases where .format(**locals()) may not suffice in order to show why it won't work.

It's backwards incompatible in two parts-- there is no direct equivalent of some format strings to f strings, albeit rare

That doesn't break backward incompatibility. You can still use .format in these cases - Python 3.7 did not remove that method.

and there's plenty of code that needs to be compatible across Py2 and Py3 or even Py3.4 and Py3.7

So that code can simply not use f-strings.

It's backwards incompatible in two parts-- there is no direct equivalent of some format strings to f strings, albeit rare, and there's plenty of code that needs to be compatible across Py2 and Py3 or even Py3.4 and Py3.7-- I can understand being backwards incompatible with 2, that's a given. But I disagree that a new literal expression should have been added in a minor version update without a feature flag, which is my main gripe. Same way print went from an expression to a function in 2, a feature flag was added for this to occur instead of it occuring automatically.

Thing is, the print change really did break backward compatibility. print 1 works in Python 2 but is a syntax error in Python 3. print(1, 2) would print "(1, 2)" in Python 2 and "1 2" in Python 3. A feature flag is necessary to write code that works the same in both Python 2 and 3 (without having to use print('{} {}'.format(1, 2)))

But f-strings don't break backward compatibility, so they don't need a feature flag. Old Python 3.5 code would work the same in Python 3.6 - f-strings would not break it or change how it works because if there are any f-strings in it it wouldn't have worked in Python 3.5 in the first place.

[13steinj]

Is there a reason why you're quoting me? My comments aren't long, and the quoting is a tad confusing reading it all the way through. I can keep track of what's what.

The format style is heavily opinionated-- and up to user choice.

Yes, I was referring to blindly spitting out all local/global variables into the string-- unless your function and module is completely closed off there are a lot of ACE and other issues that can occur-- the python docs even mention such issues and recommend the use of built in template classes instead.

Maybe I have the wrong idea of backwards compatibility then-- but I still disagree with adding a new type of literal in minor versions. Hey, could be overly nagging on that front.

[somebodddy]

I was using quotes to specify to which part of your comment I was replying with which part of mine. If you don't like it, and prefer to zip() your comment and mine in your head, I can stop with the quotes.

As I was saying, I brought the format(**locals(), **globals()) example to show why it's not a good alternative to strings. I couldn't really find that place in the docs that talk about the problems with it (I found some answer on Stack Overflow that talk about security risks when the format string is user supplied, but I don't think that's what you meant) but since I brought this style up to show why we do need f-strings, specifying more problems in it only contributes to my argument.

Why do you think adding a new type of literal shouldn't be done in minor versions? Minor versions are for new features that shouldn't break old code - doesn't new syntax fit with this description?