23 ms·

A lot of early Python's appeal was in its simplicity. I miss that era. Soon Python is going to resemble C++'s bloated feature set where you're not supposed to u

A lot of early Python's appeal was in its simplicity. I miss that era. Soon Python is going to resemble C++'s bloated feature set where you're not supposed to use parts of the language because "that's the old way of doing things". Edit: Actually that's already true with string formatting.

_jjkk 6y ago
I agree completely. I hate how different reading C++0x and C++17 is. I hate reading a "C++ style guide" for a new project. I already feel that pretty soon, "Python Style Guide" will be a necessary evil...
- atoav 6y ago
  Really? I program Python for over a decade now and compared to other language it was always the one where style somewhat was the smallest issue with that language (compared to the C, C++, C#, Javascript, Java I have seen). Might be that the whitespace indentations focus the mind. Also: PEPs already act as style guides. And if you are worried to do it wrong, just run it through a code formatter like black. It really isn't that much of a problem IMO.
  - roelschroeven 6y ago
    I think grandparent is talking about something else. Large C++ codebases often have a guide that says which parts of the language to use and not to use. That can be useful if you have a team with people with different levels of expertise in the language, or expertise in different parts of the language. C++ has grown to be a language with a lot of different parts to choose from. And it looks like Python is heading in the same direction. It's not difficult to imagine a future where some Python projects are going to want such guides too.
    - atoav 6y ago
      Thanks for the clarification.
    - 533474 6y ago
      grandparent?
      - roelschroeven 6y ago
        The parent comment of the parent of my comment, and by extension the writer of that comment.
scatters 6y ago
And packaging!
superbcarrot 6y ago
It's difficult to balance it out correctly. F-strings were a significant improvement and I still think it was a great idea to include them and trade off some of the language simplicty for the added convenience. This new pattern matching... I'm not convinced yet.
- roelschroeven 6y ago
  Personally I don't feel f-strings are an improvement at all, but I think I can see why people prefer them. But a significant improvement, that I don't see at all. Can someone explain why e.g. f'gcd({a}, {b}) = {math.gcd(a, b)}' is so much better than 'gcd({}, {}) = {}'.format(a, b, math.gcd(a, b)) In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. I really like that separation. When the expressions get more complex, .format() doesn't really lose any clarity while f'' gets pretty unreadable quite fast IMO. Yes, you can simplify by assigning the expressions to variables, but .format() doesn't even need that.
  - superbcarrot 6y ago
    I find the f-string version better because I read from left to right and find it unnatural when my eyes need to jump around several times over the same expression in order to parse it. In your example that effect isn't too strong because there isn't a lot of additional text in the string and it's very clear what's going on either way.
  - IanCal 6y ago
    > In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. It makes it harder to see which values actually go where though. I really dislike the separation.
    - ju_sh 6y ago
      Thank goodness we still have both ;)
not_knuth 6y ago
Obligatory Bjarne Stroustrup quote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think it's an interesting point you make, because Python is actually one of the few languages that tried to break away from its past (the whole 2.7 to 3.7 fiasco), but it seems the need for a language to be stable is just much, much greater – so features are just piled onto the existing standard instead. If COBOL taught me one thing, it's that I'm pretty sure in 60 years time there will still be critical infrastructure running on Python 2.7.
- neysofu 6y ago
  That quote is seriously overused, to the point where valid criticisms will be met with disapproval simply because the language falls under condition (1).
  - rrdharan 6y ago
    There are quotations people complain about and ones that no one recognizes.
- chriswarbo 6y ago
  > There are only two kinds of languages: the ones people complain about and the ones nobody uses. My old boss used to say this thought terminating cliche whenever I encountered a problem with PHP. It's a rather useless form of binary thinking, since it completely ignores scale and severity. It's similar to statements like "all politicians are bad", which put the likes of Nick Clegg in the same bag as, say, Pol Pot. It's counter-productive to any meaningful discussion.
  - deleted 6y ago
    [deleted]
  - cat199 6y ago
    > It's a rather useless form of binary thinking, since it completely ignores scale and severity. You may also be interested in: "there are 10 kinds of people - those who understand binary, and those who do not"
cjauvin 6y ago
I understand your feeling and I would tend to agree for things in other domains.. but for a programming language, I find that if: (1) It doesn't make the language less efficient (2) The new feature is coherent with the rest of the language (3) It doesn't make learning the language harder (4) It brings joy in my life (as f-strings do) Then.. it's ok :-)
- rement 6y ago
  I have never seen f-strings! It's my lucky day! https://xkcd.com/1053/ https://xkcd.com/1053/ Time to refactor the project I am currently working on that is loaded with `str.format()`
  - ZephyrBlu 6y ago
    f-strings are truly amazing. They're very painless. The only gotcha I've run into is accessing a dict from inside one. You need to watch out for your quotations :).
    - mumblemumble 6y ago
      My most recent project makes liberal use of `f"""..."""`
  - ilovetux 6y ago
    Be aware that the only time this won't work is if you need to re-render the f-string with different context. For example you can do this: s = "this is {}" print(s.format("possible")) but you cannot do that with f-strings because they are resolved on definition, so you could do something like this: for message in messages: print(f"The message is {message}") But not this: s = f"The message is {message}" for message in messages: print(s) This is the same drawback of JavaScript's Template Literals [0]. EDIT: Fix syntax in examples. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - matt_trentini 6y ago
whalesalad 6y ago
String formatting with f"" has been the new sheriff in town for a while and it is really killer.
- pletnes 6y ago
  Yes, and it also takes approx 11 seconds to learn, since str.format already had exactly the same syntax, just slightly more verbose.
  - leadingthenet 6y ago
    I never understood why they didn't remove the previous ones. Isn't there supposed to be only one obvious way of doing these things?
    - elisaado 6y ago
      You can't just remove things, that'd break stuff!
      - spockz 6y ago
        That is why scala has scalafix[1] where library maintainers can provide rules along with newer versions of libraries that can be used to automatically, either at build time or out of band on the source, translate old constructs/patterns in the new. See it as deferred refactoring for library maintainers. Library maintainers that work in a monorepo with their users get this refactoring feature for free. [1]: https://scalacenter.github.io/scalafix https://scalacenter.github.io/scalafix
        lopatin 6y ago
        I have two thoughts on this: One is that tools like scalafix no-doubt rely heavily on static analysis to ensure correctness of their program transformations. I'm not sure a hypothetical "pythonfix" tool will be quite as feasible for untyped code bases. And also, the issue isn't really with library maintainers when it comes to Python syntax changes. It's with all the user code written in Python. I tried converting my programs from Scala 2.12 from 2.13, and I failed so hard. I couldn't justify the time commitment, even with tools like scalafix to automate stuff. It's just not that smart. All this is to say, let's not pretend that breaking changes to a programming language are ok. If you have to do break stuff once or twice in the lifetime of your language, fine. But accepting breaking changes as the status-quo is a failure of a language, by definition, IMO.
roelschroeven 6y ago
And probably other situations, like perhaps corporate environments, where you're not supposed to use the new more advanced parts because not everyone on the team knows them. Python is evolving into several different languages. "There should be one-- and preferably only one --obvious way to do it." Yeah right. I'm waiting for a PEP that deprecates PEP 20, "The Zen of Python". It's become more and more clear that the core developers don't follow it all anymore.
- make3 6y ago
  I think this comment is super exaggerated. In my experience pretty much all features in Python 3 by far are really welcome. The only features you're usually not supposed to use are very obvious ones, inspect, metaclasses and nested comprehensions, which are super uncommon and feel like dark magic that you would obviously not want to use, or just shit ugly code in the case of nested comprehensions.
  - pmart123 6y ago
    I agree with this up through Python 3.7. The recent updates though seem to be unnecessary or have obtuse syntax.
    - make3 6y ago
      do you have specific examples? honestly I was against the walrus operator but having played with it for just two seconds I think it's really great and that people are making a bigger deal than needed about this
  - cjohnson318 6y ago
    Yes, I think the general consensus on metaclasses is that if you don't already know what they are, then you probably don't need to use them. There's some metaclasses in Django, but it's pretty easy to see how you're expected to use them from examples, and you don't need to really understand what's going on.
  - enriquto 6y ago
pizza 6y ago
This feature could make a lot of code that people write quite often a fair amount simpler, though. I'm looking forward to this feature quite a bit.
01100011 6y ago
Maybe the problem with C++ is that it tries too hard to preserve backwards compatibility? I think it makes some of the newer features clunkier. If the C++ standards folks did something like Google's Abseil and provided an upgrade tool while discontinuing old features they might have ended up with a better language. I understand something like that might not work for everyone, but from what I've gathered in talking to other devs, there is a strong distaste for the current state of C++.
- Kototama 6y ago
  > Maybe the problem with C++ is that it tries too hard to preserve backwards compatibility? That's a funny one. The whole history of C++ is being backward compatible, originally with C.
74d-fe6-2c6 6y ago
I need to justify six digits in Germany - we're not the Bay Area.
cjohnson318 6y ago
I think str.format() was an improvement on from % formatting, and that the f strings are an improvement on str.format(). It's readable, concise, and it's familiar from other scripting languages. I think the advantage of switch statments and pattern matching is that you know the scope of the thing you're switching or matching on, but you don't have that restriction in if/elif/else blocks. There's nothing keeping me from adding a condition like, `elif day == "Tuesday":`, that has nothing to do with the task at hand. When I see switch or match, I feel like I know what I'm getting into.
asah 6y ago
sorry for the downvote: please propose solutions that allow the language to evolve and not stagnate. example: pylint-type tools that flag old ways of doing things, and suggest replacement syntax (e.g. https://pycodequ.al/docs/pylint-messages/r1717-consider-using-dict-comprehension.html https://pycodequ.al/docs/pylint-messages/r1717-consider-usin... )
- chriswarbo 6y ago
  I wouldn't treat 'evolution' as an inherently good thing; i.e. change for its own sake. My first thought whenever someone proposes changing a language is "could that be done with a library instead?". If it's possible then I think libraries are preferable to language changes; if it's not possible and we decide to change the language, then it may be better (if possible) to make a change which fixes whatever prevented us from implementing such a library. Only if we can't do that would I resort to adding individual features to the language. For example, Scheme has really good pattern matching, despite it not being part of the language. In fact, there are so many pattern matching libraries for Scheme that there are now attempts to standardise their APIs https://srfi.schemers.org/srfi-200/srfi-200.html https://srfi.schemers.org/srfi-200/srfi-200.html
  - lhjn 6y ago
    In scheme, or most other Lisps for that matter, you extend the language by writing a library, as the language extension tools are built-in and quite easy to use (macros). Very few other languages give you that kind of power, and certainly not python.
nickysielicki 6y ago
Already true with string formatting, map/filter versus comprehensions, plenty of other things. Find me a modern language where that isn't true, though.
0xbadcafebee 6y ago
If developers actually knew what simplicity was they'd stop worshipping it. Brainfuck is an extremely simple language. I mean, it's perfect. Only 8 instructions! Only 1 pointer! Turing complete! Why isn't everyone writing their code in this language? A bicycle attached to a wheelbarrow is extremely simple transportation. You can get anywhere you need to go, you can carry heavy loads, it's easy to use, easy to fix, cheap. Why would you use anything else? Wood is a great building material. You can build a building several stories tall, it's cheap, plentiful, easy to work with. We should just standardize all construction on wood. Water is the simplest beverage. It's clean, healthy, easy to ship, easy to store. We don't need to drink anything else.
- chriswarbo 6y ago
  I regularly read cutting edge research papers whose code examples are expressed in lambda calculus, a language from the 1930s with 3 syntax rules and 1 reduction rule.
  - visarga 6y ago
    Not a powerful argument because in 90 years it's still not mainstream and only exists in papers and blog posts. On the other hand pattern matching is widely used. 'Simple' can be 'complicated' in another way, otherwise we'd prefer to write machine code.
    - chriswarbo 6y ago
      > Not a powerful argument because in 90 years it's still not mainstream and only exists in papers and blog posts https://docs.python.org/3/reference/expressions.html#lambda https://docs.python.org/3/reference/expressions.html#lambda https://262.ecma-international.org/11.0/#sec-arrow-function-definitions https://262.ecma-international.org/11.0/#sec-arrow-function-... https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.27 https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.ht... https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda https://rosettacode.org/wiki/First-class_functions https://rosettacode.org/wiki/First-class_functions
adamc 6y ago
I don't really agree. I helped steer my organization to Python more than a decade ago -- its mix of capability and readability made it a great fit, and it remains so. Nothing I saw in this made me worried that people would struggle to read it. F-strings are great, a huge improvement on needing to say .format() all the time, and format was an improvement on the original use of % (more descriptive). C++ is a wholly different beast. Template metaprogramming achieves great things, but at significant cost to readability.
remram 6y ago
This has been true for many, many years with "old-style classes".
geofft 6y ago
That's been true for a very long while - in Python 2.1 (released just shy of 20 years ago), they added "new-style classes", class Foo(object), and for the entire life of Python 2 you weren't supposed to use "old-style classes", class Foo, because they behaved in confusing ways. (Python 3 got rid of old-style classes and made the two syntaxes equivalent.)
oconnor663 6y ago
This argument is totally valid, but I think the problem is that it's universal. It seems like it's equally valid as an argument against any feature. So to really apply it in practice, we need to go further, and come up with some way to quantify the value a new feature brings, so that we can compare that value to the downside of more bloat.
mechnesium 6y ago
This is generally how the evolution of technology works. If somebody whipped out a 3½ inch floppy, wouldn’t you say “that’s the old way of doing things?”
odonnellryan 6y ago
I wouldn't say it is true with string formatting. I would tell a new dev to use the cool new syntax if I saw them using old syntax, but I don't think using the old syntax is painful at all to read.
pansa2 6y ago
My concern with Python’s feature bloat is the opposite. That there aren’t parts you’re not supposed to use - developers are expected to know all of it. Three string formatting approaches are all in wide use. There are now two different ways to do something as fundamental as assignment. Some classes use explicit methods like __eq__, others hide them by using @dataclass. Async-await adds coloured functions [0], along with “red” versions of numerous language constructs. That’s not to mention type annotations, which I won’t deny are popular but are incredibly complex. [0] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...
gonzo41 6y ago
Come on down to golang town. Though I worry when the introduce generics things will spiral out of control.
- pansa2 6y ago
  Go has a different kind of complexity from Python, though. It makes you deal with low-level details like pointers and casting between different-sized integers, none of which are necessary in Python.

_jjkk 6y ago

I agree completely. I hate how different reading C++0x and C++17 is. I hate reading a "C++ style guide" for a new project. I already feel that pretty soon, "Python Style Guide" will be a necessary evil...

atoav 6y ago
Really? I program Python for over a decade now and compared to other language it was always the one where style somewhat was the smallest issue with that language (compared to the C, C++, C#, Javascript, Java I have seen). Might be that the whitespace indentations focus the mind. Also: PEPs already act as style guides. And if you are worried to do it wrong, just run it through a code formatter like black. It really isn't that much of a problem IMO.
- roelschroeven 6y ago
  I think grandparent is talking about something else. Large C++ codebases often have a guide that says which parts of the language to use and not to use. That can be useful if you have a team with people with different levels of expertise in the language, or expertise in different parts of the language. C++ has grown to be a language with a lot of different parts to choose from. And it looks like Python is heading in the same direction. It's not difficult to imagine a future where some Python projects are going to want such guides too.
  - atoav 6y ago
    Thanks for the clarification.
  - 533474 6y ago
    grandparent?
    - roelschroeven 6y ago
      The parent comment of the parent of my comment, and by extension the writer of that comment.

scatters 6y ago

And packaging!

superbcarrot 6y ago

It's difficult to balance it out correctly. F-strings were a significant improvement and I still think it was a great idea to include them and trade off some of the language simplicty for the added convenience. This new pattern matching... I'm not convinced yet.

roelschroeven 6y ago
Personally I don't feel f-strings are an improvement at all, but I think I can see why people prefer them. But a significant improvement, that I don't see at all. Can someone explain why e.g. f'gcd({a}, {b}) = {math.gcd(a, b)}' is so much better than 'gcd({}, {}) = {}'.format(a, b, math.gcd(a, b)) In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. I really like that separation. When the expressions get more complex, .format() doesn't really lose any clarity while f'' gets pretty unreadable quite fast IMO. Yes, you can simplify by assigning the expressions to variables, but .format() doesn't even need that.
- superbcarrot 6y ago
  I find the f-string version better because I read from left to right and find it unnatural when my eyes need to jump around several times over the same expression in order to parse it. In your example that effect isn't too strong because there isn't a lot of additional text in the string and it's very clear what's going on either way.
- IanCal 6y ago
  > In the .format() version, the formatting and the values are separate and that makes it more clear to see both the formatting and the values. It makes it harder to see which values actually go where though. I really dislike the separation.
  - ju_sh 6y ago
    Thank goodness we still have both ;)

not_knuth 6y ago

Obligatory Bjarne Stroustrup quote: "There are only two kinds of languages: the ones people complain about and the ones nobody uses." I think it's an interesting point you make, because Python is actually one of the few languages that tried to break away from its past (the whole 2.7 to 3.7 fiasco), but it seems the need for a language to be stable is just much, much greater – so features are just piled onto the existing standard instead. If COBOL taught me one thing, it's that I'm pretty sure in 60 years time there will still be critical infrastructure running on Python 2.7.

neysofu 6y ago
That quote is seriously overused, to the point where valid criticisms will be met with disapproval simply because the language falls under condition (1).
- rrdharan 6y ago
  There are quotations people complain about and ones that no one recognizes.
chriswarbo 6y ago
> There are only two kinds of languages: the ones people complain about and the ones nobody uses. My old boss used to say this thought terminating cliche whenever I encountered a problem with PHP. It's a rather useless form of binary thinking, since it completely ignores scale and severity. It's similar to statements like "all politicians are bad", which put the likes of Nick Clegg in the same bag as, say, Pol Pot. It's counter-productive to any meaningful discussion.
- deleted 6y ago
  [deleted]
- cat199 6y ago
  > It's a rather useless form of binary thinking, since it completely ignores scale and severity. You may also be interested in: "there are 10 kinds of people - those who understand binary, and those who do not"

cjauvin 6y ago

I understand your feeling and I would tend to agree for things in other domains.. but for a programming language, I find that if: (1) It doesn't make the language less efficient (2) The new feature is coherent with the rest of the language (3) It doesn't make learning the language harder (4) It brings joy in my life (as f-strings do) Then.. it's ok :-)

rement 6y ago
I have never seen f-strings! It's my lucky day! https://xkcd.com/1053/ https://xkcd.com/1053/ Time to refactor the project I am currently working on that is loaded with `str.format()`
- ZephyrBlu 6y ago
  f-strings are truly amazing. They're very painless. The only gotcha I've run into is accessing a dict from inside one. You need to watch out for your quotations :).
  - mumblemumble 6y ago
    My most recent project makes liberal use of `f"""..."""`
- ilovetux 6y ago
  Be aware that the only time this won't work is if you need to re-render the f-string with different context. For example you can do this: s = "this is {}" print(s.format("possible")) but you cannot do that with f-strings because they are resolved on definition, so you could do something like this: for message in messages: print(f"The message is {message}") But not this: s = f"The message is {message}" for message in messages: print(s) This is the same drawback of JavaScript's Template Literals [0]. EDIT: Fix syntax in examples. [0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Template_literals https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- matt_trentini 6y ago

whalesalad 6y ago

String formatting with f"" has been the new sheriff in town for a while and it is really killer.

pletnes 6y ago
Yes, and it also takes approx 11 seconds to learn, since str.format already had exactly the same syntax, just slightly more verbose.
- leadingthenet 6y ago
  I never understood why they didn't remove the previous ones. Isn't there supposed to be only one obvious way of doing these things?
  - elisaado 6y ago
    You can't just remove things, that'd break stuff!
    - spockz 6y ago
      That is why scala has scalafix[1] where library maintainers can provide rules along with newer versions of libraries that can be used to automatically, either at build time or out of band on the source, translate old constructs/patterns in the new. See it as deferred refactoring for library maintainers. Library maintainers that work in a monorepo with their users get this refactoring feature for free. [1]: https://scalacenter.github.io/scalafix https://scalacenter.github.io/scalafix
      - lopatin 6y ago
        I have two thoughts on this: One is that tools like scalafix no-doubt rely heavily on static analysis to ensure correctness of their program transformations. I'm not sure a hypothetical "pythonfix" tool will be quite as feasible for untyped code bases. And also, the issue isn't really with library maintainers when it comes to Python syntax changes. It's with all the user code written in Python. I tried converting my programs from Scala 2.12 from 2.13, and I failed so hard. I couldn't justify the time commitment, even with tools like scalafix to automate stuff. It's just not that smart. All this is to say, let's not pretend that breaking changes to a programming language are ok. If you have to do break stuff once or twice in the lifetime of your language, fine. But accepting breaking changes as the status-quo is a failure of a language, by definition, IMO.

roelschroeven 6y ago

And probably other situations, like perhaps corporate environments, where you're not supposed to use the new more advanced parts because not everyone on the team knows them. Python is evolving into several different languages. "There should be one-- and preferably only one --obvious way to do it." Yeah right. I'm waiting for a PEP that deprecates PEP 20, "The Zen of Python". It's become more and more clear that the core developers don't follow it all anymore.

make3 6y ago
I think this comment is super exaggerated. In my experience pretty much all features in Python 3 by far are really welcome. The only features you're usually not supposed to use are very obvious ones, inspect, metaclasses and nested comprehensions, which are super uncommon and feel like dark magic that you would obviously not want to use, or just shit ugly code in the case of nested comprehensions.
- pmart123 6y ago
  I agree with this up through Python 3.7. The recent updates though seem to be unnecessary or have obtuse syntax.
  - make3 6y ago
    do you have specific examples? honestly I was against the walrus operator but having played with it for just two seconds I think it's really great and that people are making a bigger deal than needed about this
- cjohnson318 6y ago
  Yes, I think the general consensus on metaclasses is that if you don't already know what they are, then you probably don't need to use them. There's some metaclasses in Django, but it's pretty easy to see how you're expected to use them from examples, and you don't need to really understand what's going on.
- enriquto 6y ago

pizza 6y ago

This feature could make a lot of code that people write quite often a fair amount simpler, though. I'm looking forward to this feature quite a bit.

01100011 6y ago

Maybe the problem with C++ is that it tries too hard to preserve backwards compatibility? I think it makes some of the newer features clunkier. If the C++ standards folks did something like Google's Abseil and provided an upgrade tool while discontinuing old features they might have ended up with a better language. I understand something like that might not work for everyone, but from what I've gathered in talking to other devs, there is a strong distaste for the current state of C++.

Kototama 6y ago
> Maybe the problem with C++ is that it tries too hard to preserve backwards compatibility? That's a funny one. The whole history of C++ is being backward compatible, originally with C.

74d-fe6-2c6 6y ago

I need to justify six digits in Germany - we're not the Bay Area.

cjohnson318 6y ago

I think str.format() was an improvement on from % formatting, and that the f strings are an improvement on str.format(). It's readable, concise, and it's familiar from other scripting languages. I think the advantage of switch statments and pattern matching is that you know the scope of the thing you're switching or matching on, but you don't have that restriction in if/elif/else blocks. There's nothing keeping me from adding a condition like, `elif day == "Tuesday":`, that has nothing to do with the task at hand. When I see switch or match, I feel like I know what I'm getting into.

asah 6y ago

sorry for the downvote: please propose solutions that allow the language to evolve and not stagnate. example: pylint-type tools that flag old ways of doing things, and suggest replacement syntax (e.g. https://pycodequ.al/docs/pylint-messages/r1717-consider-using-dict-comprehension.html https://pycodequ.al/docs/pylint-messages/r1717-consider-usin... )

chriswarbo 6y ago
I wouldn't treat 'evolution' as an inherently good thing; i.e. change for its own sake. My first thought whenever someone proposes changing a language is "could that be done with a library instead?". If it's possible then I think libraries are preferable to language changes; if it's not possible and we decide to change the language, then it may be better (if possible) to make a change which fixes whatever prevented us from implementing such a library. Only if we can't do that would I resort to adding individual features to the language. For example, Scheme has really good pattern matching, despite it not being part of the language. In fact, there are so many pattern matching libraries for Scheme that there are now attempts to standardise their APIs https://srfi.schemers.org/srfi-200/srfi-200.html https://srfi.schemers.org/srfi-200/srfi-200.html
- lhjn 6y ago
  In scheme, or most other Lisps for that matter, you extend the language by writing a library, as the language extension tools are built-in and quite easy to use (macros). Very few other languages give you that kind of power, and certainly not python.

nickysielicki 6y ago

Already true with string formatting, map/filter versus comprehensions, plenty of other things. Find me a modern language where that isn't true, though.

0xbadcafebee 6y ago

If developers actually knew what simplicity was they'd stop worshipping it. Brainfuck is an extremely simple language. I mean, it's perfect. Only 8 instructions! Only 1 pointer! Turing complete! Why isn't everyone writing their code in this language? A bicycle attached to a wheelbarrow is extremely simple transportation. You can get anywhere you need to go, you can carry heavy loads, it's easy to use, easy to fix, cheap. Why would you use anything else? Wood is a great building material. You can build a building several stories tall, it's cheap, plentiful, easy to work with. We should just standardize all construction on wood. Water is the simplest beverage. It's clean, healthy, easy to ship, easy to store. We don't need to drink anything else.

chriswarbo 6y ago
I regularly read cutting edge research papers whose code examples are expressed in lambda calculus, a language from the 1930s with 3 syntax rules and 1 reduction rule.
- visarga 6y ago
  Not a powerful argument because in 90 years it's still not mainstream and only exists in papers and blog posts. On the other hand pattern matching is widely used. 'Simple' can be 'complicated' in another way, otherwise we'd prefer to write machine code.
  - chriswarbo 6y ago
    > Not a powerful argument because in 90 years it's still not mainstream and only exists in papers and blog posts https://docs.python.org/3/reference/expressions.html#lambda https://docs.python.org/3/reference/expressions.html#lambda https://262.ecma-international.org/11.0/#sec-arrow-function-definitions https://262.ecma-international.org/11.0/#sec-arrow-function-... https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.html#jls-15.27 https://docs.oracle.com/javase/specs/jls/se15/html/jls-15.ht... https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda https://timsong-cpp.github.io/cppwp/n3337/expr.prim.lambda https://rosettacode.org/wiki/First-class_functions https://rosettacode.org/wiki/First-class_functions

adamc 6y ago

I don't really agree. I helped steer my organization to Python more than a decade ago -- its mix of capability and readability made it a great fit, and it remains so. Nothing I saw in this made me worried that people would struggle to read it. F-strings are great, a huge improvement on needing to say .format() all the time, and format was an improvement on the original use of % (more descriptive). C++ is a wholly different beast. Template metaprogramming achieves great things, but at significant cost to readability.

remram 6y ago

This has been true for many, many years with "old-style classes".

geofft 6y ago

That's been true for a very long while - in Python 2.1 (released just shy of 20 years ago), they added "new-style classes", class Foo(object), and for the entire life of Python 2 you weren't supposed to use "old-style classes", class Foo, because they behaved in confusing ways. (Python 3 got rid of old-style classes and made the two syntaxes equivalent.)

oconnor663 6y ago

This argument is totally valid, but I think the problem is that it's universal. It seems like it's equally valid as an argument against any feature. So to really apply it in practice, we need to go further, and come up with some way to quantify the value a new feature brings, so that we can compare that value to the downside of more bloat.

mechnesium 6y ago

This is generally how the evolution of technology works. If somebody whipped out a 3½ inch floppy, wouldn’t you say “that’s the old way of doing things?”

odonnellryan 6y ago

I wouldn't say it is true with string formatting. I would tell a new dev to use the cool new syntax if I saw them using old syntax, but I don't think using the old syntax is painful at all to read.

pansa2 6y ago

My concern with Python’s feature bloat is the opposite. That there aren’t parts you’re not supposed to use - developers are expected to know all of it. Three string formatting approaches are all in wide use. There are now two different ways to do something as fundamental as assignment. Some classes use explicit methods like __eq__, others hide them by using @dataclass. Async-await adds coloured functions [0], along with “red” versions of numerous language constructs. That’s not to mention type annotations, which I won’t deny are popular but are incredibly complex. [0] http://journal.stuffwithstuff.com/2015/02/01/what-color-is-your-function/ http://journal.stuffwithstuff.com/2015/02/01/what-color-is-y...

gonzo41 6y ago

Come on down to golang town. Though I worry when the introduce generics things will spiral out of control.

pansa2 6y ago
Go has a different kind of complexity from Python, though. It makes you deal with low-level details like pointers and casting between different-sized integers, none of which are necessary in Python.