4 ms·

I like the additions of the f-strings and walrus operator, but I find myself wishing a breaking-release removing the old features that the new features covers.

I like the additions of the f-strings and walrus operator, but I find myself wishing a breaking-release removing the old features that the new features covers. Python's philosophy was to have one way to do something, but the current situation of Python is very inconsistent. Python 3 has like 4~5 ways to format strings, and due to the addition of the walrus operator, we have (I understand the differences between := and = but) two different syntaxes for variable declaration/assignment. I understand that Python can't break all kinds of code (as the 2->3 conversion is still a pain), but still I imagine a Python-esque language without all the warts that Python have with it's 'organic' growth.

jakear 7y ago
That's a good use case for a linter. Ban outdated constructs in your code, but still allow you to depend on things that use them. Beats another 2->3 split again.
- pcr910303 7y ago
  Yeah, and I already use linters to remove all outdated constructs; but... It's a pity that "There's only one way to do it" doesn't work in 2019 :-(
  - gimboland 7y ago
    It was never "there's only one way to do it". It is: "There should be one-- and preferably only one --obvious way to do it." The core of that statement is "There should be one obvious way to do it" - there's no "only" there, it just says that when you need to do something, there should be an/some obvious way to do it. Then, preferably, that should be the only obvious way — though of course that doesn't preclude there being many other less-obvious ways. With string interpolation we've certainly now got multiple ways to do it; that doesn't violate the principle. I agree that at least two of those are "obvious" (f-strings and .format()), and you could argue that %-interpolation is obvious too — but none of that is in violation of the principle that there should be an obvious way to do it, just of the preference that there's only one. Finally it's worth remembering where this idea came from: it was in contrast to the perl mantra of "there's more than one way to do it", and a reaction to the resultant confusion frequently experienced when reading someone else's perl code — this was python saying "we're not perl, we value clarity and comprehension". I think that much of that problem was bound up in perl's syntax choices, and that in the cases in python where there's more than one way to do it (say, string formatting, dataclasses/attrs/namedtuples/etc.), it's usually pretty obvious what machinery is actually being used. When was the last time you looked at a line of python and said "I have no idea what the fuck is going on here?" That was a frequent experience with perl in the heady days of the late 1990s.
eru 7y ago
Perhaps Python itself could worn you that certain constructs are deprecated and will be removed in future versions. And you could 'import something from future' to opt-in to making those warnings errors right now.
- pcr910303 7y ago
  That's a pretty good idea, deprecating & warning + providing automatic conversion utilities + using 'future' to make them errors... But that won't happen :-(
  - makapuf 7y ago
    And then import from past to remove warnings if you really want to use those constructs without warnings. Next time, feature would be removed or a depreciation warning when used with from past.
  - mixmastamyk 7y ago
    Some deprecation warnings have been enabled for a developers main source files recently. Though not in third-party libraries, which would be frustrating to the end-user. I forget the exact details though.

jakear 7y ago

That's a good use case for a linter. Ban outdated constructs in your code, but still allow you to depend on things that use them. Beats another 2->3 split again.

pcr910303 7y ago
Yeah, and I already use linters to remove all outdated constructs; but... It's a pity that "There's only one way to do it" doesn't work in 2019 :-(
- gimboland 7y ago
  It was never "there's only one way to do it". It is: "There should be one-- and preferably only one --obvious way to do it." The core of that statement is "There should be one obvious way to do it" - there's no "only" there, it just says that when you need to do something, there should be an/some obvious way to do it. Then, preferably, that should be the only obvious way — though of course that doesn't preclude there being many other less-obvious ways. With string interpolation we've certainly now got multiple ways to do it; that doesn't violate the principle. I agree that at least two of those are "obvious" (f-strings and .format()), and you could argue that %-interpolation is obvious too — but none of that is in violation of the principle that there should be an obvious way to do it, just of the preference that there's only one. Finally it's worth remembering where this idea came from: it was in contrast to the perl mantra of "there's more than one way to do it", and a reaction to the resultant confusion frequently experienced when reading someone else's perl code — this was python saying "we're not perl, we value clarity and comprehension". I think that much of that problem was bound up in perl's syntax choices, and that in the cases in python where there's more than one way to do it (say, string formatting, dataclasses/attrs/namedtuples/etc.), it's usually pretty obvious what machinery is actually being used. When was the last time you looked at a line of python and said "I have no idea what the fuck is going on here?" That was a frequent experience with perl in the heady days of the late 1990s.

eru 7y ago

Perhaps Python itself could worn you that certain constructs are deprecated and will be removed in future versions. And you could 'import something from future' to opt-in to making those warnings errors right now.

pcr910303 7y ago
That's a pretty good idea, deprecating & warning + providing automatic conversion utilities + using 'future' to make them errors... But that won't happen :-(
- makapuf 7y ago
  And then import from past to remove warnings if you really want to use those constructs without warnings. Next time, feature would be removed or a depreciation warning when used with from past.
- mixmastamyk 7y ago
  Some deprecation warnings have been enabled for a developers main source files recently. Though not in third-party libraries, which would be frustrating to the end-user. I forget the exact details though.