8 ms·

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that jus

One of the biggest features I'm looking forward to is the more specific error messages. I can't tell you how much time I've wasted with cryptic errors that just point to a line that has a list comprehension or similar.

bilsbie 4y ago
When is that coming? Yes the error messages are confusing in a big list comprehension.
- alexfromapex 4y ago
  Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features https://docs.python.org/3.11/whatsnew/3.11.html#new-features
- teekert 4y ago
  Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
  - 8organicbits 4y ago
    "Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand Although, personally, I enjoy python list comprehensions.
    - timoteostewart 4y ago
      I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan https://en.m.wikiquote.org/wiki/Brian_Kernighan
      - 8organicbits 4y ago
        Maybe, I grabbed the first matching quote I found. I can't attribute it on my own.
        timoteostewart 4y ago
        No sweat. I’m a quote nerd so it jumped out at me
  - polski-g 4y ago
    All list comprehensions should error with message "FATAL PARSE ERROR: Will you really understand this in six months?"
    - TremendousJudge 4y ago
      If people complain about Rust's borrow checker already...
    - wheelerof4te 4y ago
      List comprehensions should be used for making quick lists that contain simple calculations or filters. Anything more will come back to bite you later.
    - teekert 4y ago
      Something like this I find ok (just a filter): [x for x in y if x is not z] Sometimes though, facilitated by Jupyter's notebooks making executing as you build the code very easy, I create a beast like this: [os.path.join([x for x in y if x is not z]) + '/bin' for a in b if 'temp' not in a] Yes this is fictional and probably contains an error but you get the point, you can filter lists of lists like this, but it's really unfriendly to anyone trying to understand it later.
  - mikepurvis 4y ago
    Not even with nesting— as soon as it's long enough that I'm breaking it into multiple lines, I'm immediately like, okay this is long enough to just be a normal for-loop, or maybe a generator function. But it doesn't need to be a list comprehension any more.
- agumonkey 4y ago
  In a way it's a nice incentive not to nest too much (I have that tendency too)
  - yantrams 4y ago
    Hold my beer! https://i.redd.it/8waggyjyyle51.png https://i.redd.it/8waggyjyyle51.png
    - ChadNauseam 4y ago
      Hold mine :D https://github.com/anchpop/genomics_viz/blob/master/genomics-viz/Assets/StreamingAssets/Chromosomal/Scripts/chromsdata_tools/chromsdata_tools/compilation.py#L292-L433 https://github.com/anchpop/genomics_viz/blob/master/genomics... That's one expression because it used to be part of a giant comprehension, but I moved it into a function for a bit more readability. I'm considering moving it back just for kicks though. My philosophy is: if you're only barely smart enough to code it, you aren't smart enough to debug it. Therefore, you should code at your limit, to force yourself to get smarter while debugging
      - teddyh 4y ago
        https://www.reddit.com/r/ProgrammerHumor/comments/uosex4/no_please_no/ https://www.reddit.com/r/ProgrammerHumor/comments/uosex4/no_...
      - agumonkey 4y ago
        That code is fine in my book, there's more static code than for-comp and it's at work 3 level deep with no hard coupling between levels. Also well spaced and worded.
      - int_19h 4y ago
        Yours is nice and readable. Parents' one is not, but it feels like the indentation is deliberately confusing. I'd lay it out like so: tags = list(set([ nel for subli in [ mel for subl in [ [[jel.split('/')[2:] for jel in el] for el in classified ] for mel in subl ] for nel in subli if nel ])) Still not very readable, tho. But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that doesn't scale at all. Side note: one other thing I always hated about those things in Python is that there's no way to bind an intermediary computation to a variable. In C# LINQ, you can do things like: from x in xs let y = x.ComputeSomething() where y.IsFoo && y.IsBar select y In Python, you have to either invoke ComputeSomething twice, or hack "for" to work like "let" by wrapping the bound value in a container: y for x in xs for y in [x.ComputeSomething()] if y.IsFoo and y.IsBar It's not just about not repeating yourself or not running the same code twice, either - named variables are themselves a form of self-documenting code, and a sequence pipeline using them even where they aren't strictly needed can be much more readable.
- psalminen 4y ago
  Big list comprehensions cause confusion in many ways. KISS is crucial with them.
  - mcronce 4y ago
    I agree. The rule of thumb I follow is that if the list comp doesn't fit on one line, whatever I'm doing is probably too complicated for a list comp.
    - gpderetta 4y ago
      But why? The only reason is that error messages are awful and intermediate values can't be named. There is in principle no reason why list comprehension need to be worse than straight line for loops. The deciding factor to chose betwee the two should be whether I'm writing something for side effects as opposed to for its value.
      - mcronce 4y ago
        You just listed two very good reasons: Intermediate values can't be named, and error messages are awful.
dec0dedab0de 4y ago
This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.
- joshmaker 4y ago
  The new error messages are much better. Take a look at this example: Traceback (most recent call last): File "calculation.py", line 54, in <module> result = (x / y / z) * (a / b / c) ~~~~~~^~~ ZeroDivisionError: division by zero In this new version it's now obvious which variable is causing the 'division by zero' error. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-error-locations-in-tracebacks https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
  - bredren 4y ago
    For a lot of folks dealing with getting something working, its way more useful to have the most likely spot where the error is occurring spit out for them like this. Stack trace is useful, especially in understanding how the code is working in the system. But if the goal is solve the problem with the code you've been working on, existing traces are way too verbose and if anything add noise or distract from getting to productive again. I could see tracebacks get swifty terminal UI that shows only the pinpointed error point that can be accordion'd out to show the rest.
- actuallyalys 4y ago
  I don’t think they’re that bad, but I think the bar has (fortunately) become higher.
  - urthor 4y ago
    Exactly right. The old Python stack trace, circa 2015, was the best in the world. The new ones are even better. The gap between Python and Rust, and the JVM languages/C/C++, is increasingly widening. Stack trace is one of the areas Python and Rust are making the case for why they're the languages of the future.
CobrastanJorji 4y ago
I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.
- dralley 4y ago
  The exception is std::io::Error, which doesn't provide any information about which file failed to be opened/closed/read/whatever. I know this is because doing so would require an allocation, but it's still painful.
  - estebank 4y ago
    The GP comment is referring to the compile time diagnostics and not the runtime diagnostics, which certainly could do with some out-of-the-box improvements but that you can extend in your own code (as opposed to compile errors which crate authors have little control over, at least for now).
  - rowanG077 4y ago
    huh a stack trace should tell you that.
  - tialaramex 4y ago
    Your parent is thinking about the compiler errors, whereas std::io::Error (which I'm guessing you mean) is an Error type your software can get from calling I/O functions at runtime. To be fair, if decorating the error with information about a filename is what you needed, since Rust's Error types are just types nothing stops you making your function's Error type be the tuple (std::io::Error, &str) if you have a string reference, or (though this seems terribly inappropriate in production code) leaking a Box to make a static reference from a string whose lifetime isn't sufficient.
- jmcgough 4y ago
  I wrote 2-3 of those and I really wish more languages had a similar approach with their standard library. When you get an error there's a verbose explanation you can ask for, which describes the problem, gives example code and suggests how you can fix it. The language has a longer ramp-up period because it contains new paradigms, so little touches like this help a lot in onboarding new devs.
kirillbobyrev 4y ago
Not saying that there isn't room for improvement but I wouldn't call the Python error messages "cryptic". C++, on the other hand...
- gpderetta 4y ago
  I program in both C++ and Python every day and I'm fluent in both. I would prefer 10000 lines template instantiation backtraces every time to the average python error message. Clang and GCC error messages have come a loooong way in the last 10 years or so and their quality is impressive. To be fair, I'm currently stuck at python 3.6 ATM and I hear that python has also improved a lot since.

bilsbie 4y ago

When is that coming? Yes the error messages are confusing in a big list comprehension.

alexfromapex 4y ago
Will be in the 3.11 release: https://docs.python.org/3.11/whatsnew/3.11.html#new-features https://docs.python.org/3.11/whatsnew/3.11.html#new-features
teekert 4y ago
Whenever I nest a list comprehension I feel dirty anyway, I wonder if a better error message will help solve something that is just hard to grasp sometimes.
- 8organicbits 4y ago
  "Debugging is twice as hard as writing the code in the first place. Therfore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it." - Rajanand Although, personally, I enjoy python list comprehensions.
  - timoteostewart 4y ago
    I believe that quote about debugging being twice as hard as coding is by Brian Kernighan. https://en.m.wikiquote.org/wiki/Brian_Kernighan https://en.m.wikiquote.org/wiki/Brian_Kernighan
    - 8organicbits 4y ago
      Maybe, I grabbed the first matching quote I found. I can't attribute it on my own.
      - timoteostewart 4y ago
        No sweat. I’m a quote nerd so it jumped out at me
- polski-g 4y ago
  All list comprehensions should error with message "FATAL PARSE ERROR: Will you really understand this in six months?"
  - TremendousJudge 4y ago
    If people complain about Rust's borrow checker already...
  - wheelerof4te 4y ago
    List comprehensions should be used for making quick lists that contain simple calculations or filters. Anything more will come back to bite you later.
  - teekert 4y ago
    Something like this I find ok (just a filter): [x for x in y if x is not z] Sometimes though, facilitated by Jupyter's notebooks making executing as you build the code very easy, I create a beast like this: [os.path.join([x for x in y if x is not z]) + '/bin' for a in b if 'temp' not in a] Yes this is fictional and probably contains an error but you get the point, you can filter lists of lists like this, but it's really unfriendly to anyone trying to understand it later.
- mikepurvis 4y ago
  Not even with nesting— as soon as it's long enough that I'm breaking it into multiple lines, I'm immediately like, okay this is long enough to just be a normal for-loop, or maybe a generator function. But it doesn't need to be a list comprehension any more.
agumonkey 4y ago
In a way it's a nice incentive not to nest too much (I have that tendency too)
- yantrams 4y ago
  Hold my beer! https://i.redd.it/8waggyjyyle51.png https://i.redd.it/8waggyjyyle51.png
  - ChadNauseam 4y ago
    Hold mine :D https://github.com/anchpop/genomics_viz/blob/master/genomics-viz/Assets/StreamingAssets/Chromosomal/Scripts/chromsdata_tools/chromsdata_tools/compilation.py#L292-L433 https://github.com/anchpop/genomics_viz/blob/master/genomics... That's one expression because it used to be part of a giant comprehension, but I moved it into a function for a bit more readability. I'm considering moving it back just for kicks though. My philosophy is: if you're only barely smart enough to code it, you aren't smart enough to debug it. Therefore, you should code at your limit, to force yourself to get smarter while debugging
    - teddyh 4y ago
      https://www.reddit.com/r/ProgrammerHumor/comments/uosex4/no_please_no/ https://www.reddit.com/r/ProgrammerHumor/comments/uosex4/no_...
    - agumonkey 4y ago
      That code is fine in my book, there's more static code than for-comp and it's at work 3 level deep with no hard coupling between levels. Also well spaced and worded.
    - int_19h 4y ago
      Yours is nice and readable. Parents' one is not, but it feels like the indentation is deliberately confusing. I'd lay it out like so: tags = list(set([ nel for subli in [ mel for subl in [ [[jel.split('/')[2:] for jel in el] for el in classified ] for mel in subl ] for nel in subli if nel ])) Still not very readable, tho. But that's largely due to Python's outputs-first sequence comprehension syntax being a mess that doesn't scale at all. Side note: one other thing I always hated about those things in Python is that there's no way to bind an intermediary computation to a variable. In C# LINQ, you can do things like: from x in xs let y = x.ComputeSomething() where y.IsFoo && y.IsBar select y In Python, you have to either invoke ComputeSomething twice, or hack "for" to work like "let" by wrapping the bound value in a container: y for x in xs for y in [x.ComputeSomething()] if y.IsFoo and y.IsBar It's not just about not repeating yourself or not running the same code twice, either - named variables are themselves a form of self-documenting code, and a sequence pipeline using them even where they aren't strictly needed can be much more readable.
psalminen 4y ago
Big list comprehensions cause confusion in many ways. KISS is crucial with them.
- mcronce 4y ago
  I agree. The rule of thumb I follow is that if the list comp doesn't fit on one line, whatever I'm doing is probably too complicated for a list comp.
  - gpderetta 4y ago
    But why? The only reason is that error messages are awful and intermediate values can't be named. There is in principle no reason why list comprehension need to be worse than straight line for loops. The deciding factor to chose betwee the two should be whether I'm writing something for side effects as opposed to for its value.
    - mcronce 4y ago
      You just listed two very good reasons: Intermediate values can't be named, and error messages are awful.

dec0dedab0de 4y ago

This is the first time I ever heard someone complain about Python's error messages in the 10+ years I've been using it. Even people who just learned it, pick up reading tracebacks after about a day of practice. The only problem I ever see is if a library swallows too much, and gives a generic error, but that's not something the language can fix. I really hope they don't change things too much.

joshmaker 4y ago
The new error messages are much better. Take a look at this example: Traceback (most recent call last): File "calculation.py", line 54, in <module> result = (x / y / z) * (a / b / c) ~~~~~~^~~ ZeroDivisionError: division by zero In this new version it's now obvious which variable is causing the 'division by zero' error. https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-error-locations-in-tracebacks https://docs.python.org/3.11/whatsnew/3.11.html#enhanced-err...
- bredren 4y ago
  For a lot of folks dealing with getting something working, its way more useful to have the most likely spot where the error is occurring spit out for them like this. Stack trace is useful, especially in understanding how the code is working in the system. But if the goal is solve the problem with the code you've been working on, existing traces are way too verbose and if anything add noise or distract from getting to productive again. I could see tracebacks get swifty terminal UI that shows only the pinpointed error point that can be accordion'd out to show the rest.
actuallyalys 4y ago
I don’t think they’re that bad, but I think the bar has (fortunately) become higher.
- urthor 4y ago
  Exactly right. The old Python stack trace, circa 2015, was the best in the world. The new ones are even better. The gap between Python and Rust, and the JVM languages/C/C++, is increasingly widening. Stack trace is one of the areas Python and Rust are making the case for why they're the languages of the future.

CobrastanJorji 4y ago

I've been learning Rust recently. There are a number of things about the language that I dislike, but its error messages are an absolute joy. They clearly put an incredible amount of effort into them, and it really shows.

dralley 4y ago
The exception is std::io::Error, which doesn't provide any information about which file failed to be opened/closed/read/whatever. I know this is because doing so would require an allocation, but it's still painful.
- estebank 4y ago
  The GP comment is referring to the compile time diagnostics and not the runtime diagnostics, which certainly could do with some out-of-the-box improvements but that you can extend in your own code (as opposed to compile errors which crate authors have little control over, at least for now).
- rowanG077 4y ago
  huh a stack trace should tell you that.
- tialaramex 4y ago
  Your parent is thinking about the compiler errors, whereas std::io::Error (which I'm guessing you mean) is an Error type your software can get from calling I/O functions at runtime. To be fair, if decorating the error with information about a filename is what you needed, since Rust's Error types are just types nothing stops you making your function's Error type be the tuple (std::io::Error, &str) if you have a string reference, or (though this seems terribly inappropriate in production code) leaking a Box to make a static reference from a string whose lifetime isn't sufficient.
jmcgough 4y ago
I wrote 2-3 of those and I really wish more languages had a similar approach with their standard library. When you get an error there's a verbose explanation you can ask for, which describes the problem, gives example code and suggests how you can fix it. The language has a longer ramp-up period because it contains new paradigms, so little touches like this help a lot in onboarding new devs.

kirillbobyrev 4y ago

Not saying that there isn't room for improvement but I wouldn't call the Python error messages "cryptic". C++, on the other hand...

gpderetta 4y ago
I program in both C++ and Python every day and I'm fluent in both. I would prefer 10000 lines template instantiation backtraces every time to the average python error message. Clang and GCC error messages have come a loooong way in the last 10 years or so and their quality is impressive. To be fair, I'm currently stuck at python 3.6 ATM and I hear that python has also improved a lot since.