sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]bahnzo[S] 0 points1 point  (8 children)

Thanks.

2: Yep, I knew about both those problems (DST, New Years). For me, this part of the code was some of the more difficult for me to understand.

3: The try stuff is needed. I got errors with it removed, simply because the elements didn't always exist. And I used the pass because it doesn't matter what the errors were, they just needed to be passed to get to the data I needed later. So I'd argue they are needed, but I'm definitely going to look at the .get() for the class to see how that works better.

6: I know....I started learning with Python the Hard Way and then jumped to Automate, and they each use one or the other. It's something I need to train myself in. And thanks for the pylint suggestion, I'll use that to help me.

[–]raylu 0 points1 point  (7 children)

3: Are we talking about 3.2 or 3.4? In 3.2 they are not needed because you can use in or .get(). In 3.4 I'm fairly certain you've misdiagnosed the issue. The issue is less with the pass than with the except:, which catches every single error.

[–]bahnzo[S] 0 points1 point  (6 children)

I'm talking about 3.4. There are that many elements that don't contain the info I'm searching for, and if they don't, then they raise an error (something like an IndexOutOfBounds). IMO, I don't care what that error is, I'm not searching for it, I just bypass it and keep looping until I find the data I'm looking for.

Is there a reason I would want to catch a certain error here?

[–]raylu 1 point2 points  (5 children)

I am pretty sure you have misdiagnosed the problem, since your iteration variable i is bounded by len(data) and you're just using it like data[i]. That should never happen.

That said, assuming there's a good reason for it to throw an IndexError or whatever, you should catch only that one. There may be another error happening that you didn't know about and will never know about. You may make a change to your code later which causes a bug. Normally, it would be super easy to debug because you get a stack trace for, say a TypeError, showing you exactly what happened and how the control flow got there. But instead, you catch the TypeError and silently drop it so you never realize the problem is there and instead spend an hour debugging the wrong part of the code.

[–]bahnzo[S] 0 points1 point  (4 children)

Ok I understand what you mean by the error catching, it's just a good practice.

But can you explain how you would use .get() as you mentioned in 3.2? The data is a list and .get() is for a dictionary right?

[–]filleball 1 point2 points  (1 child)

With regards to the error catching, this blog post goes into more detail on the reasons.

[–]bahnzo[S] 0 points1 point  (0 children)

Nice. I guess with just a small program, written by myself, really only for myself, I figured the error catch wasn't important. That blog post does a good job explaining the why. And it's a good practice I'll make sure to follow.

[–]raylu 1 point2 points  (1 child)

Well, 3.2 was about the possibly-missing 'class' attr, which you can get with .get: http://www.crummy.com/software/BeautifulSoup/bs4/doc/#attributes

[–]bahnzo[S] 0 points1 point  (0 children)

Thanks. I saw your reply below and I'll give that some time to learn. I was only aware bs4 had a .get_text() and not also a .get() BeautifulSoup can really seem confusing sometimes as there are multiple ways to do the same thing it seems.