People automatically think "csv? I gotta install Pandas!" even if CSV is like 20 lines long. Then follows 15 lines of Pandas DSL that i have to decipher to modify anything
I hate it
For what it's worth, here's my defense: The data in this neat CSV actually came from simulations that were dumping Parquet files on the order of 100s of GiBs, which was the reason I was using pandas in the first place. This code snippet was lifted from a processing pipeline where pandas was used for other reasons, but I admit, it probably would have been best to break it out into its own little file and not include the module at all.
import csv
with open(filename, 'r') as f:
r = csv.reader(f)
for row in r:
tsc, _, pc, *_ = row
print(int(tsc, 16), int(pc, 16))It wasn't until I started writing code in Go years later that I really felt like I had encountered a programming experience that TRULY made me pay for my subconscious emotionally-driven need to get a dopamine hit after cramming a bunch of logic into a few lines of text. I have confess, when I worked on Go codebases, there is still a lack of "spark" that comes having code that feels so straightforward. But learning how to deal with the reality that it's quite frankly emotionally immature of me to shirk away from programming stuff just because it doesn't tickle my brain has probably been one of my most significant growth moments as a programmer.
If I'm writing code that pays my bills, I'm much better in the long run setting aside my emotions and keeping it as straightforward as possible, even if that occasionally means that simple stuff like walking through a CSV takes up an entire screen of text.
All of these words to say, you're right, and I thought it was worthwhile to discuss how I ended up realizing you were right.
I own a drill driver that delivers enough torque that it could cause a nasty wrist injury. Most of the time all is fine.
===== feel free to ignore this waffle =====
Screws will generally cam out first, when it is miss-applied - ie the driver jumps out of the screw and probably destroys the tracks in the screw head. You eventually learn the correct torque and speed settings etc. Drilling - hammer or not (conc/brick or wood/plastic), speed etc. Again, you eventually learn how to drill efficiently.
Then you put something like a 50cm long 16mm auger bit in. An auger bit is basically a sharp edged corkscrew shaped drill bit that is designed to drill a fairly wide and very deep hole in wood. There are also paddle bits which are flat paddle shaped (quelle surprise) with a pointy part to start the hole and guide the main part of the tool. These generally are used for wider and shallower holes than augers.
So you stab your long auger into say a sleeper (150mm thick, hardwood). The sleeper is part of a wall. Friction soon becomes an issue - around 30cm down or earlier for slightly built people. If you know what you are doing, you position a leg in such a way that the handle of the drill/driver hits it (in the horizontal plane) and your wrist is safe.
===== /feel free to ignore this waffle =====
I generally find that <statement> followed by ... "you're doing it wrong" is unhelpful. Why not critique what is on offer instead of a put down with no working?
In this case the author is using a tool for operating on lists on a thing that's not a list.
It's like they're trying to use a track / plunge saw for cross-cutting a single 2x4. You can do it, but you'll need to rig up some scaffolding (a list) around it in order for the track to have something to balance on. Meanwhile there's a circular saw and a speed square next to you on the table.
The use of the `for ... in [...]` to destructure the list is quite clever.
I would have simply indexed the list.
(
(int(tsc, 16), int(pc, 16))
for tsc, _, pc, *_ in (line.strip().split(",") for line in fp)
),
I think I would have written it like that:
def parse(line):
p = line.split(",")
return ((int(p[0], 16), int(p[2], 16))
(parse(line)) for line in fp)
The author is asking it to loop over a list (or any iterable) and destructure each of the elements. But is then providing a a list containing some strings, none of which can be destructured.
Reducing to just the second part of the loop:
[(x, z) for x, _, z, *_ in ["0x2d41854", "3", "0x80001a14", "(0xbffd)"]]
for x, _, z, *_ in ["0x2d41854", "3", "0x80001a14", "(0xbffd)"]:
x, _, z, *_ = "0x2d41854"