4 ms·

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 tea

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
  What's the problem with nested comprehensions? How else do you create bi-dimensional stuff?
  - magnusmundus 6y ago
    Not the same kind of nesting, is it? [[None for _y in range(y)] for _x in range(x)] for two dimensions is fine, while [None for _x in range(x) for _y in range(y)] (to create a flattened 2-dim list? excuse the dummy example) is just begging for later headache. Explicit looping is much more readable. Note the flipped order of expressions -- these two statements create the same iterators. Not to mention, you can even reuse the name for extra evil: [i for i in range(2) for i in range(3)] results in [0, 1, 2, 0, 1, 2]
    - joshuamorton 6y ago
      Fwiw, I find creating a 2d array and then flattening (`itertools.chain.from_iterable([[None for _y in range(y)] for _x in range(x)])` to be both readable and reasonably concise, though yes explicit loops are also fine.
      - cat199 6y ago
        nice trick.. though if you are relying on the 'generator' aspect of comprehensions this may be problematic (will create in-memory copies)
mrfusion 6y ago
I thought I’d learn Perl once so I started reading a book on it. I was shocked that literally the bottom half of every page was footnotes. I gave up after a few pages. Too much mental overhead. Other people love that kind of stuff though.
- 0xbadcafebee 6y ago
  This is the first time in the history of the internet that anyone has complained about too much documentation.
- ghshephard 6y ago
  I was a Perl developer/scripter for the better part of 3 years - wrote a 2-way LDAP<-> HRIS synchronization system in it, complete with customizeable Schemas. Then, 3 or so years into my Perl experience, in which I still needed to look at template code every time I did a HashOfArray/ArrayOfHash, I tripped across some python code explaining how everything was objects. Within a few seconds I tested that theory, by populating a list with dicts and voila - just worked. Close to the last day I ever touched Perl. The python language expansions that have come recently, f-strings, walrus operator, and now matching - are great in that they don't make the language more complex - all three of these are easily explainable in a few minutes to the novice, and once they understand it, they can quickly (and profitably) incorporate it into their code. I wan't there to be a steady drumbeat of these improvements that let me write more elegant code, more concisely. Try and find a single python developer who would give up their f-strings now.
  - adamc 6y ago
    Yeah, this. I love Python, and I hated Perl. Even Java was a pleasure compared to Perl. At one time, a trainer was trying to tell us Ruby was the new hotness (2009 or 2010, I think). I liked Ruby OK, but Python seems cleaner and we stuck with it. I have not felt the slightest regret.
  - kbenson 6y ago
    > in which I still needed to look at template code every time I did a HashOfArray/ArrayOfHash Honestly, that sounds like someone that didn't bother to learn what's actually going on and understand what the language was doing. I mean, that's fine, we all do that... but I wouldn't blame the language for that. Perl makes nested data structures very easy and obvious once you learn what's going on. You just need to actually learn it and not rely on the little shortcuts Perl allows you to use to never make that next step to learning exactly why. Perl will "just do what you mean" so much that it papers over some of the early learning friction points enough that they build up to a later point. At that point, people either throw up their hands and move on because it's annoying when some shortcut they've relied on isn't working in this one weird instance, or they learn what's really going on (Hint: it's almost always either about understanding references or context at this stage) and it's no longer a problem. > Try and find a single python developer who would give up their f-strings now. Things like f-strings and list comprehensions in Python are the exact thing that Python devs used to point out as too complex in other languages (I mean, f-strings look to be pretty much just string interpolation). I think that's evidence that perhaps a language isn't always best suited for all audiences. Python used to be aimed at learning and easy of understanding and use. Now that it's often more targeted for complex engineering projects, you get stuff sneaking in that was specifically avoided by design initially.
kelnos 6y ago
First off I'll say that I'm very sympathetic to your point of view, and mostly agree with it. But... after I learned Scala a bunch of years ago, working in any language without pattern matching has felt like significantly more of a chore than it used to be. It's like you've been doing something the hard way for years, someone teaches you an easier, better, more readable way, and just when you get used to it and love it, then tells you that you can't use it anymore. Certainly that's not true of all possible high-mental-load new features that could be added to Python. But I don't want to believe that features that drastically increase ergonomics shouldn't be added to a language because they make the language less simple.

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
What's the problem with nested comprehensions? How else do you create bi-dimensional stuff?
- magnusmundus 6y ago
  Not the same kind of nesting, is it? [[None for _y in range(y)] for _x in range(x)] for two dimensions is fine, while [None for _x in range(x) for _y in range(y)] (to create a flattened 2-dim list? excuse the dummy example) is just begging for later headache. Explicit looping is much more readable. Note the flipped order of expressions -- these two statements create the same iterators. Not to mention, you can even reuse the name for extra evil: [i for i in range(2) for i in range(3)] results in [0, 1, 2, 0, 1, 2]
  - joshuamorton 6y ago
    Fwiw, I find creating a 2d array and then flattening (`itertools.chain.from_iterable([[None for _y in range(y)] for _x in range(x)])` to be both readable and reasonably concise, though yes explicit loops are also fine.
    - cat199 6y ago
      nice trick.. though if you are relying on the 'generator' aspect of comprehensions this may be problematic (will create in-memory copies)

mrfusion 6y ago

I thought I’d learn Perl once so I started reading a book on it. I was shocked that literally the bottom half of every page was footnotes. I gave up after a few pages. Too much mental overhead. Other people love that kind of stuff though.

0xbadcafebee 6y ago
This is the first time in the history of the internet that anyone has complained about too much documentation.
ghshephard 6y ago
I was a Perl developer/scripter for the better part of 3 years - wrote a 2-way LDAP<-> HRIS synchronization system in it, complete with customizeable Schemas. Then, 3 or so years into my Perl experience, in which I still needed to look at template code every time I did a HashOfArray/ArrayOfHash, I tripped across some python code explaining how everything was objects. Within a few seconds I tested that theory, by populating a list with dicts and voila - just worked. Close to the last day I ever touched Perl. The python language expansions that have come recently, f-strings, walrus operator, and now matching - are great in that they don't make the language more complex - all three of these are easily explainable in a few minutes to the novice, and once they understand it, they can quickly (and profitably) incorporate it into their code. I wan't there to be a steady drumbeat of these improvements that let me write more elegant code, more concisely. Try and find a single python developer who would give up their f-strings now.
- adamc 6y ago
  Yeah, this. I love Python, and I hated Perl. Even Java was a pleasure compared to Perl. At one time, a trainer was trying to tell us Ruby was the new hotness (2009 or 2010, I think). I liked Ruby OK, but Python seems cleaner and we stuck with it. I have not felt the slightest regret.
- kbenson 6y ago
  > in which I still needed to look at template code every time I did a HashOfArray/ArrayOfHash Honestly, that sounds like someone that didn't bother to learn what's actually going on and understand what the language was doing. I mean, that's fine, we all do that... but I wouldn't blame the language for that. Perl makes nested data structures very easy and obvious once you learn what's going on. You just need to actually learn it and not rely on the little shortcuts Perl allows you to use to never make that next step to learning exactly why. Perl will "just do what you mean" so much that it papers over some of the early learning friction points enough that they build up to a later point. At that point, people either throw up their hands and move on because it's annoying when some shortcut they've relied on isn't working in this one weird instance, or they learn what's really going on (Hint: it's almost always either about understanding references or context at this stage) and it's no longer a problem. > Try and find a single python developer who would give up their f-strings now. Things like f-strings and list comprehensions in Python are the exact thing that Python devs used to point out as too complex in other languages (I mean, f-strings look to be pretty much just string interpolation). I think that's evidence that perhaps a language isn't always best suited for all audiences. Python used to be aimed at learning and easy of understanding and use. Now that it's often more targeted for complex engineering projects, you get stuff sneaking in that was specifically avoided by design initially.

kelnos 6y ago

First off I'll say that I'm very sympathetic to your point of view, and mostly agree with it. But... after I learned Scala a bunch of years ago, working in any language without pattern matching has felt like significantly more of a chore than it used to be. It's like you've been doing something the hard way for years, someone teaches you an easier, better, more readable way, and just when you get used to it and love it, then tells you that you can't use it anymore. Certainly that's not true of all possible high-mental-load new features that could be added to Python. But I don't want to believe that features that drastically increase ergonomics shouldn't be added to a language because they make the language less simple.