5 ms·

Spot the bug in this Python code (2023)

• simonblack 3y ago
  (0x00800513),x10,0x8 Well, I'm not a Python guy, but I saw something that would have been a bug. As numbers, the line above's variables would evaluate to 0x00800513 0x0000 0x8 In a language like C, in a compilation, that 'x10' would throw up a 'variable not declared' error. As data, it would most likely evaluate as above to zero (depending on the data-handling code).
  • dwrodri 3y ago
    In my case that field was completely ignored, and thankfully it wasn't a parsing error in Python.
• t-vi 3y ago
  The logic error seems to be that you have the second for loop where you only want to destructure the splitted line into a tuple. Now writing that decomposition as a for loop over a one-element list (as in the corrected code) works, but seems "hmhm". In other words, the misunderstanding here is that you want a chain of generators, not a "nested for loop"-generator. A more proper solution could be to chain the generator expressions: with lines = ["a,b", "c,d"] you could do ((a,b) for a, b in (l.split(',') for l in lines))
  • dwrodri 3y ago
    So fun fact, I had discussed this exact approach with a few people when i was debugging this, and in fact this was the first solution I had come up with. However, the approach in my code generates less bytecode and performed slightly faster, as the chained generator expressions add more overhead. See here: https://godbolt.org/z/nT8a5eMGa https://godbolt.org/z/nT8a5eMGa I agree that your approach requires less usage of (what I'd consider) unintuitive syntax, so I should probably add it as an alternative viable solution! Since if performance is so critical as to worry over something like this, we'd probably both agree that you should probably be wary of choosing Python in the first place.