Skip to content
This repository has been archived by the owner on Sep 5, 2019. It is now read-only.

Dev #156

Merged
merged 12 commits into from
Jul 22, 2019
Merged

Dev #156

merged 12 commits into from
Jul 22, 2019

Conversation

gh-PonyM
Copy link
Contributor

I wrote new wrappers for the error handling using new translations strings. The translations have not been updated yet.

@coveralls
Copy link

coveralls commented Jul 22, 2019

Coverage Status

Coverage decreased (-0.1%) to 94.856% when pulling 8462034 on dev into dd8166d on master.

@gh-PonyM gh-PonyM requested a review from href July 22, 2019 08:42
Copy link
Contributor

@href href left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks mostly good to me, though the assertions-bit has to be handled differently.


def get_candidate_id(line):
return str(int(line.knr))
def get_number_of_mandates(line):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tend to follow GO's dictum these days. For setter functions use set_, for getter functions omit the get_. I think we should adopt that in all new code.

See https://golang.org/doc/effective_go.html#Getters

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agree. In this case I left it since otherwise var names conflict with function names and the following routine gets harder to read.

col = 'ausmittlungsstand'
try:
t = int(line.ausmittlungsstand or 0)
assert 0 <= t <= 3
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You shouldn't use assertions and exceptions like this. Exceptions are for unexpected things (a value being invalid is expected in an import). Assertions on the other hand are for developers only. The end-user should never see the result of an assertion.

Here, you could simply use a condition, then raise a ValueError:

if not (0 <= t <= 3): 
   raise ValueError( _('Value ${col} is not between 0 and 3', mapping={'col': col})))

Of course you would have to do that outside the current try block (or you would catch your own exception). But that would be clearer anyway and it would make obvious that you are not returning the t anywhere in the function 😉

I would also rename t into something a bit more lengthy, like maybe result.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, agree 100%.

if not hasattr(line, col):
raise ValueError(_('Missing column: ${col}', mapping={'col': col}))
number = line.listnr or '0'
number = '999' if number == '99' else number # blank list
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not quite sure what # blank list means. Could you elaborate your comment here? Why is 99 turned into 999?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blank lists are lists without a candidate or those with a missing party. WabstiC uses code 99 for those, but they map to 999 that represents the same from other interfaces. This can read in open_data_de.md. I made the comment more clear referencing open_data_de.md.

@@ -549,6 +614,7 @@ def import_election_wabstic_proporz(
if election.domain == 'region' and districts and election.distinct:
if principal.has_districts:
if len(districts) != 1:
# FIXME: better error messages
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here it would make sense to also elaborate. Why can't you write a better error message at this time?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the moment I do not understand the difference between the two cases, so a better FIXME Message would be "Separate error msg for the two cases". I still lack the overview to write a good and valid error message.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Alright, then I would just elaborate. It's okay to write long FIXME's and to really write down your current thoughts and what you don't get yet. Otherwise the FIXME will be very cryptic to yourself when you stumble upon it in the future :)

raise ValueError(_('Missing column: ${col}', mapping={'col', col}))
if '.' in line.knr:
return line.knr.split('.')[0]
# replaces int(int(line.knr) / 100))
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this the previous function in place? If so, you can just remove it. Only leave the current code when changing functions. It is hard enough to understand old code when you look at it in a year, without having to look at even older code.

If you want to look at even older code, git log / git blame is better.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the old code hint, old code is not used anywhere anymore.

@gh-PonyM gh-PonyM merged commit 8e8e404 into master Jul 22, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants