5 ms·

Nobody talks much about the original goal of "There should be one-- and preferably only one --obvious way to do it." -- PEP 20 (!) Back when, I lurved me some

• simonh 7y ago
  It's not that it's never been possible to do things other ways in Python. The obvious way to do stuff is to use the latest module or feature. The obvious way to do string formatting is now f-strings.
  • dhuramas 7y ago
    In an enterprise-y environment, it's not always possible to keep upgrading to the latest. So assuming someone creates a project based on f-strings, that would be python 3.6+ only. Whereas using string.format will work across entire python 3+. Is that worth the upgrade- I'm not convinced.
    • pas 7y ago
      Yes, and? This still means that if someone gets the latest Python the f-strings should be used everywhere, because supposedly they solve every and all problems that the previous ones solved and some.
      • arshbot 7y ago
        But in reality, you can't ( and shouldn't ) go back and change how the rest of the legacy codebase does things just because there's a new way to do it.
        • e1ven 7y ago
          Right - They tried dropping legacy compatibility before, and people are still upset 10+ years later. For something as essential as strings, it makes sense to recommend the "new" way, and continue to support the "old" way.
  • imglorp 7y ago
    Until the newer way comes along and then there's n+1 ways.
    • pas 7y ago
      The new ways come for a reason. And the new ways should respect PEP20, meaning they should work for the old use cases, so that everyone can start using the new ways as soon as they can upgrade to that version. Now, of course Python is interpreted and packages are shipped as raw source code and this makes things harder for library authors, because were there a compile/transpile step, they could write using the new and shiny obvious ways, all the while providing compiled blobs (or transpiled libs) targeting multiple versions.
      • wund3rb4r88 7y ago
        So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language, and obliges a non-insignificant userbase to adapt? Technological purity or scratching some philosophical itch would be a poor reason, IMO, given how broad the externalized costs run. So is it provably easier to reason around the new style? Reduce computing time by an order of magnitude (in the modern era where compute cycles and memory are hella cheap)? Code is to be written so it’s understandable and useful for humans first, right? How does a third syntax for a solved usecase offer real value to the user base? Or are we just being sycophants of so-called experts, peddling some novel “look”. Experts who largely built a rep on first mover advantage, but have since seen that excuse for being deified evaporate as the rest of world learned all the same tricks?
        • SoReadyToHelp 7y ago
          > So what reason is there for adding a new string formatting syntax that looks nothing like string formatting syntax used in any other language The new syntax is more like other modern languages, not less.
        • simonh 7y ago
          >that looks nothing like string formatting syntax used in any other language PHP echo "There are $apples apples and $bananas bananas."; Ruby puts "I have #{apples} apples" TCL puts "I have $apples apples." Typescript console.log(`I have ${apples} apples`); Python print(f"I have {apples} apples") Looks pretty similar to me, and if you like understand-ability by humans so much I think f-strings win hands down. But if you disagree, there's plenty of code out there still using % strings or .format() and they're not going anywhere any time soon.
• deleted 7y ago
  [deleted]
• aeturnum 7y ago
  > how many string formatters do we have now? Could we please decruft and dump some of them while we're at it? % or f' or .format or whatever To me, there's a difference between "one way" and "one interface." I agree we should depricate %-formatting in strings, but .format / f"" are different interfaces on the same functionality - which seems fine.
  • aequitas 7y ago
    Except that f-strings are not lazy evaluated so you cannot replace something like: log.debug("foo bar %s", foobar) with fstrings. And you end up with part of your team enforcing f-strings because of cleaner look, the other half .format or '%' strings and the rest annoyed when their code is constantly rejected in reviews because they don't know/care which standard to use where.
    • aeturnum 7y ago
      My understanding was that you can use f-strings for the thing you outlined above, the f-string composition will just be evaluated as an expression whether or not log.debug is enabled. Personally I'd trade that for the %-string drawbacks.
    • marcinzm 7y ago
      Languages don't solve organizational issues. If you have a dysfunctional team without leadership then that will always show somewhere. A good team would establish some set of coding standards and then enforce those. Rejecting PRs for personal preference coding standards would result in a talk from the manager.
    • Caligatio 7y ago
      I don't think something like "foo bar %s".format(foobar) would work either in this situation. I think you're conflating format strings with the lazy evaluation associated with logging. I am, however, in complete agreement that logging should adopt at least the same formatting used by .format
    • pfranz 7y ago