EAN13 calculate_checksum() generates inconsistent values

[zspherez]

When using the EAN13() constructor with a 12 digit argument to create an EAN13, the check digit generated in the constructor is different than if you were to call calculate_checksum() on the 13 digit value returned by the constructor.

>>> EAN13("842169142322")
<EuropeanArticleNumber13('8421691423220')>

gives that the check digit is 0

>>> ean = EAN13("842169142322")
>>> ean
<EuropeanArticleNumber13('8421691423220')>
>>> ean.calculate_checksum()
4

implying that the check digit is 4

This seems to be due to the fact that when calculate_checksum() is called on a 13 digit EAN via the object itself, the reverse traversal that is used in the method includes the 13th digit when summing and calculating the check digit.

[stonebig]

hum,

on my own method using the generic check digits algorithm given per GS/1, I get the same result as python-barcode:

so maybe this shall be "rebranded" as "ean_key_computation", but it's not faulty as you think

[WhyNotHugo]

The issue is that the implementation saves the whole number plus the checksum into self.ean, but then calculate_checksum calculates the checksum for self.ean (e.g.: a string which already includes the checksum).

[WhyNotHugo]

While this is the "expected behaviour" as per the documentation, it's obviously un-intuitive and can be improved. I'm just not sure how to improve it without breaking existing usages.

[WhyNotHugo]

I think that #215 should fix it. Can you confirm?

[WhyNotHugo]

Fixed in #213

[WhyNotHugo]

f242961 fixes EAN14