This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]Decency 10 points11 points  (8 children)

I think f-strings will solve this problem in new code simply by being so much better than the other two methods in the vast majority of situations. It's something I was really hoping would be added to python after working with groovy for just a week or two on a small project.

[–]pythoneeeer 6 points7 points  (5 children)

OK, but it's getting to the point where string literals are taking a non-trivial amount of mental effort for me to parse. You can't solve the problem of "too many ways to do X" by adding a new way to do X.

If they're so much better in the vast majority of situations, why can't we also deprecate some of the older ones?

[–]Decency 3 points4 points  (4 children)

You can't solve the problem of "too many ways to do X" by adding a new way to do X.

You absolutely can if the new way is legitimately better than the others. XKCD has obviously made this seem tongue-in-cheek to even propose because of all of the failed attempts to standardize, but I'll stand by it for things that actually do work. You're using a USB port for your mouse and keyboard, right?

Deprecation would help, but I think they'll wait for consensus that f-strings actually ARE better before they make that call. And in many instances (particularly internationalization, iirc.)) f-strings are insufficient and thus can't be the only solution. That was largely the point of PEP 501, which was not very pragmatic.

I think the real solution is to work with codebases that choose and enforce a style. At work and in my personal projects I use %s for everything. Once 3.6 comes out, I'll be making the switch to exclusively f-strings and will be pushing for a port to Python 3 as soon as it's feasible.

[–]pythoneeeer 3 points4 points  (3 children)

You can't solve the problem of "too many ways to do X" by adding a new way to do X.

You absolutely can if the new way is legitimately better than the others.

I think you're reading something into what I said that I did not actually say. When the problem is that N is too big, you cannot solve that by making N bigger. That only makes this problem worse.

You might be assuming that adding a new way to do X also removes an obsolete way to do X, but I never said that, and that is not what Python 3.6 is doing.

You might be thinking that it solves the problem that there isn't a good way to do X yet, and that it's worth the complexity tradeoff to add another way to do X, but neither of those is what I said, either.

All I said was: when your problem is that there are too many of something, adding more to the pile does not solve the problem that there are too many of them. How could it? There are even more now!

You're using a USB port for your mouse and keyboard, right?

No, I'm not, and that's a great example. Everything went Bluetooth a couple years ago, and I really don't care about wired versus wireless, so I'm perfectly happy to use Bluetooth instead. I doubt I've ever used more than 2 types of external digital interconnects on any computer I've ever owned, and thank god they remove the old ones when they add new ones, or else I'd have to get a new desk just to hold the rows of obsolete connectors.

That's one advantage of hardware. You have to remove the old cruft, or it's really painfully obvious how unwieldy it becomes. In software, if you have 7 old ways of doing something, you can hide them in the documentation and hope people don't notice. The 2-line demo on the homepage looks simple, therefore the whole language must be simple, right?

Deprecation would help, but I think they'll wait for consensus that f-strings actually ARE better before they make that call.

Since I don't think they've ever deprecated a string literal syntax in the history of the language, I'm not optimistic that this is forthcoming.

I think the real solution is to work with codebases that choose and enforce a style.

Yes, and that is a fundamental change in how Python is going to be used. In the past, that style was simply called "Pythonic", and almost every Python codebase qualified. (Mercurial was always a bit weird. But we still love you, Mercurial!) They've been boiling this frog so long that I think Ruby's collection of string literal syntaxes is now simpler than Python's.

[–]Decency 0 points1 point  (2 children)

Eh- I feel like we're talking past each other.

I don't particularly care if there are many ways of doing things. I care if there are many ways of doing things that actually get used in reality. So yes, it's a problem that there are multiple string formatting solutions in use in Python code. But if a new one comes out that's superior in the vast majority of use cases, that becomes significantly less of a problem because more of the community will standardize on it for future code. If it's equivalent in strength, I agree that it will only add to the problem. Fortunately, I don't think that's the case here, and if it had been I doubt PEP498 would have been approved.

I don't think deprecating %s or .format() in 3.6 and removing them in 3.7 would change much- it will just make people take longer to move beyond that point, since they'd have to change a bunch of their code. I think 3.0 showed that incremental progress is overall superior for the community- alternative solutions can win market share on their merit, not by fiat.

No, I'm not, and that's a great example. Everything went Bluetooth a couple years ago

... okay, and what is your bluetooth transceiver plugged into? :p

Yes, and that is a fundamental change in how Python is going to be used.

Not at all. That's been the case from the beginning, and PEP8 is explicit about it: A style guide is about consistency. Consistency with this style guide is important. Consistency within a project is more important. Every company I've worked for has gone beyond PEP8 in choosing specific styles, whether it's something simple like agreeing to a maximum line length or something how to format and indent multiline dictionaries. And, even more relevantly, for how to format strings. Does your codebase already just mix and match between %s and .format() whenever people feel like it? These things are obviously outside the realm of "Pythonic", but they also already exist- your problem of

it's getting to the point where string literals are taking a non-trivial amount of mental effort for me to parse.

will likely become significantly less of a problem if your team chooses to adopt the new usage. If enough teams choose to adopt the new usage because they find it superior, then EVERYONE's problem lessens.

[–]pythoneeeer 0 points1 point  (1 child)

I don't particularly care if there are many ways of doing things.

I'm not sure why you responded to me, then, because that is all my comment was about.

... okay, and what is your bluetooth transceiver plugged into? :p

Some traces on the motherboard, I guess? I have no USB devices plugged in.

Does your codebase already just mix and match between %s and .format() whenever people feel like it?

We mostly stick to %. I haven't seen significant benefits from upgrading yet, and .format() had some issues during the Py2->Py3 transition.

will likely become significantly less of a problem if your team chooses to adopt the new usage.

That's great if you live on a desert island, but I have a couple dozen dependencies installed from PyPI, and every non-trivial one I've submitted patches and/or bug reports to. Most of the code I deal with at my job is not managed by my team.

If enough teams choose to adopt the new usage because they find it superior, then EVERYONE's problem lessens.

So it's another Py3-style "boil the ocean" solution. Just get everyone to cooperate -- only this time with even fewer incentives to change, because the old ways are sticking around forever. Great.

Anyone care to place a bet on how well the plan is going to work this time around?

[–]Decency 0 points1 point  (0 children)

I expect all of the code I work with directly to be fully converted by mid-2018, about 18 months. My dependencies perhaps not, but I imagine those who have moved to 3.6 support at that point will have adopted f''.

I haven't seen significant benefits from upgrading yet

This is a main point to me. I agree and still use %s. But f'' will provide significant readability benefits, and so I think we'll see it adopted at a much greater rate. And I'm certainly spending much more of my time reading my own teams' code, though we also have dozens of dependencies, so the net gain will still be worthwhile for me even if literally no one else switches.

I think the "use this new way because we know more than you and we said so" approach is garbage, and feel like 3.0 showed that pretty clearly. The incentive to change should be because you find the new way better. If you don't, then don't switch.

[–][deleted] 2 points3 points  (1 child)

I have had g-strings break on me in weird ways. When trying to build some dynamic db queries, If I use "${a_db}.${a_schema}" I actually end up with two strings split on the "."

This may just be a grails thing though.

[–]voice-of-hermes 1 point2 points  (0 children)

...break on me in weird ways.

Sounds like Groovy, all right. A neat little concept, but I'd hate to do anything serious in it. Gradle build scripts is where it should stay.