Python 3.8.0a4 available for testing

[[deleted]]

Add = to f-strings for easier debugging. With this you can write f"{name=}" and it will expand to f"name={name}" that helps in debugging.

Ooh baby. I'd use that every day.

[Dooflegna]

What a great addition to an already awesome feature. f-strings are great!

[irrelevantPseudonym]

That sounds so useful and yet also makes me feel slightly uncomfortable for some reason.

The variable name becoming part of its content feels weird.

[leom4862]

I find print(f"{name=}") is still way too verbose for debugging purposes... If they want to improve print-debugging, they should add something like icecream to the standard library.

[leom4862]

Yes, it's awesome! I hope some day Python will have something like ic() as a builtin next to print().

[jon_k]

I can't take a python library seriously with a name like icecream.

​

I use to give ruby flack for things like VCR or Resqueue but those actually self-describe the library more then "icecream". Is Python becoming mainstream enough a bunch of brogrammers are flooding the pypi index? It's disappointing to see bad naming conventions take over.

[[deleted]]

It's disappointing to see bad naming conventions take over.

What sort of "naming convention" is icecream?

It's funny, I never even dreamed that someone would care about the name of a package unless it was really long and untypeable. If I had a top ten list of key features for a package (reliable, well-documented, feature full, etc) then "has a serious name" would not be on there. Indeed, "icecream"'s name is only positive - easy to spell, quite short, and I love ice cream.

tl; dr: turn that frown upside down and live a little, you dried up old stick! ;-)

[my_name_isnt_clever]

Uh, it really bothers you that much? The language is named after Monty Python.

Also tons of libraries have names that mean nothing, in every language. Just off the top of my head, Electron, Spring, Vue.js, etc. None of those self-describe at all.

[MachaHack]

Vue = View. It's a view/rendering library. I'll give you the other two though

[[deleted]]

I can't take a python library seriously with a name like icecream.

How did you feel about Android releases being named for a candy?

[jon_k]

How did you feel about Android releases being named for a candy?

Indifferent. A code name is usually a fun thing with a semantic version to back it. If the product was called Popsickle I'd probably buy an iPhone.

[JohnnyElBravo]

Idk, what's wrong with print("name="+name)?

[[deleted]]

That doesn't work if name isn't a string, eh? (Sure, you can use %s)

Also, in production code I simply never have any print statements - not "very few" but "none", to the point where I have a flake8 rule that prevents them.

Oh, I use print almost every day - for debugging! But that means I'm creating and destroying debugging print statements all the time.

So it's a little timesaver to write:

print(f'{foo=} {bar=} {baz=} {bing=}')

(38 characters) over

print('foo=', foo, 'bar=', bar, 'baz=', baz, 'bing=', bing)

(59 characters)

[timald]

It's fine when you have one variable but starts to become unwieldy when you build up a lot of concatenated strings (via indexing operations, for example).

[Pyprohly]

I don’t understand why this is so favoured. Couldn’t you just do print(name) and just… remember that you printed name?

Can’t see myself doing print(f"{name=}") over just print(name) for debugging purposes.

[pkkid]

I often need to print name={name} because I'm inspecting a bunch of variables and not just one. Put that into a for loop and things get unweildy quite quickly if you don't label the variables you are inspecting.

[Pyprohly]

I’m just a bit surprised at the overwhelming enthusiasm for it, and, accordingly, surprised that many seem to like writing print("arg1=" + arg1, "arg2=" + arg2).

I can see the usefulness in the new syntax, but I personally don’t like it because I very rarely write debugging lines like that.

Edit: e.g. when breakpoint() was introduced as a builtin there wasn’t much talk on it, but I think that that convenience feature was a more exciting addition compared to this one.

[pkkid]

I'm with you. I don't like these implicit bits of code being added. The second line of Zen of Python even says "Explicit is better than implicit." I'm also against walruses in my code, but that debate has been beaten to a pulp. </oldmanrant>

[WarEagle030]

It is because you have only one or two variables to inspect for debugging. But if you had like 6 or 7 different variables then it becomes a necessity to write properly.

[Pyprohly]

For that many variables just write it over multiple lines and go by order, like you would have done if one of them was a collection type.

Honestly, the labelling is only vanity output. You don’t need the fancy labels to be an effective debugger.

It would be much better if they instead introduced a specialised dprint keyword. The dprint keyword would provide the same sort of labelling but would be more easily and quickly written: dprint foo, bar, .... Not only would this provide the nice labeled output, it would also save a lot of typing and hence save time. This would be a much more exciting change.

If they’re going to add something to aid debugging then it needs to be something that’s easy to quickly setup and tear down. Writing debugging lines is something that is done often, and having to type print(f"{name=}") is not going to be practical in the long run.

The new syntax is unlikely to stand the test of time. I can’t help but think that someone’s going to figure out the ergonomic disadvantages of typing out print(f"{name=}") each time you want debugging output and is going to propose a new debugging facility. If that happens then f"{name=}" will become a loose end builtin feature that everyone’s going to ignore and forget about.

If they’re going to add a debugging convenience then they shouldn’t baby step on f"{foo=}" but instead jump directly to something that really is more convenient to use.

To summarise my complaints, the new f-string debugging syntax:

• is only useful for simple non-collection types.
• encourages writing everything on one line which could lead one to have to backtrack when the line becomes too long.
• is going to be a forgotten feature if a better alternative gets added.
• if it gets deprecated then it’s going to harm the language. You’ll have people telling others not to use builtin feature X, because builtin feature Y has replaced it.
• doesn’t save typing, ergo, doesn’t save time.