pymoney-general

[Pymoney-general] Structure for per-country currency information

[Facundo B. <fac...@gm...>]

I proposed originally that we have a structure, after parsing the ISO list =
at
http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html?pri=
ntable=3Dtrue
like the following:

 {..., "ARS": ("ARGENTINA", "Argentine Peso", "032"), ... }

Darek Suchojad noted that the first code, as different countrys have the
exactly same currency, will be reapeated (which is a problem as we're using
a dictionary), so he proposed:

{..., "ARS": (("ARGENTINA", "Argentine Peso", "032"),), ...
      "USD": (("AMERICAN SAMOA", "US Dollar", "840"),
               ("BRITISH INDIAN OCEAN TERRITORY", "US Dollar", "840"),
                ...
             ), ...
}

Jeff Kowalczyk went a step further and suggested a new denomination for
currencies, just to make them univocal, proposing the following structure
(note how he flattened the structure).

{ ...,
 "AS-USD" : ("AMERICAN SAMOA", "US Dollar", "840"),
 "IO-USD" : ("BRITISH INDIAN OCEAN TERRITORY", "US Dollar", "840"),
 "US-USD" : ("UNITED STATES",  "US Dollar", "840"),
 ...,
}

This brings the need of another structure, to map the original currency
string to the invented ones, something like

{ ..., "USD":("AS-USD", "IO-USD", "US-USD"), ...}


I have issues with the three structures proposed so far:

1. Mine: Clearly wrong! The currency string is repeated and we can not use
   it as a dictionary key.

2. Darek's: Don't like the not-flat property

3. Jeff's: Brings another layer of complexity: How do you choose (as a
   developer) and how do you predict (as user) the inserted two letters?


Before chosing one, keeping proposing others, or discuss the actual ones, I
think that we must focus in specifying what we need:

1. What information we want in the structure (or structures)

2. The standard source of that information

3. How we want to access that information

Then, we could specify the structure/s that we'll use.

So, start shooting! :)

Regards,

.    Facundo

Blog: http://www.taniquetil.com.ar/plog/
PyAr: http://www.python.org/ar/

[Pymoney-general] Re: Structure for per-country currency information

[Mariano D. <ch...@si...>]

Facundo Batista wrote:
[... snip ...]
> I have issues with the three structures proposed so far:
> 
> 1. Mine: Clearly wrong! The currency string is repeated and we can not use
>    it as a dictionary key.
> 
> 2. Darek's: Don't like the not-flat property
> 
> 3. Jeff's: Brings another layer of complexity: How do you choose (as a
>    developer) and how do you predict (as user) the inserted two letters?
> 

About Jeff's proposal: I think the "inserted two letters" are the ISO 
standard code for the country, aren't they? If they are, we don't have 
to predict anything, given that I know the currency I need to work with, 
and the country in wich I need to use it.

> 
> Before chosing one, keeping proposing others, or discuss the actual ones, I
> think that we must focus in specifying what we need:
> 
> 1. What information we want in the structure (or structures)
> 

My biggest problem with any of the structures discussed so far is that 
they seem to be too rigid. I think we need an extensible structure.
Maybe that's because I live in Argentina... and we have "experience" 
changing currencies (and even using "pseudo-currencies") at leaste once 
every ten years or so...
So today our currency is "ARS". But what if next year it's "Australes" 
again? If that happen, I'd like to extend and/or update the structures 
to reflect that change, and even using BOTH currencies at the same 
time... at least for a few months.

I like Jeff's proposal, because it links together a country-code and a 
currency-code. That way, I can use as many currencies as I need for a 
given country, assuming I won't be forced to choose an "ISO" code for 
the currency (what's the ISO code for "Patacones" or "LECOPS" or 
"Guaraníes" or any of the pseudo-currencies that the argentinian 
government created not so long ago?)

I'm sure the structure should have a country code and a currency code.

> 2. The standard source of that information
> 

For the country I'd choose the standard two-letter ISO code .
For the currency, we might use the standard ISO code too, but it should 
be possible to add new currency-codes to the structure, even if they 
aren't standard.


> 3. How we want to access that information
> 

I'm not sure how I'd like to access that structure
a) Given a country, access its currency(ies);
b) Given a currency, access the country(ies) where it is used;
c) both;


> Then, we could specify the structure/s that we'll use.
> 
> So, start shooting! :)
> 

There you're :)

-- 
Mariano

[Pymoney-general] Re: Structure for per-country currency information

[Mariano D. <ch...@si...>]

Facundo Batista wrote:
> I proposed originally that we have a structure, after parsing the ISO list at
> http://www.iso.org/iso/en/prods-services/popstds/currencycodeslist.html?printable=true
> like the following:
[... snip ...]


Damn! Please, ignore my previous post... at least for now.
I've just subscribed to the list and replied to this thread without 
reading the posts about the sprint. For some reason I thought they 
weren't important (maybe because I wasn't there :p)

Now I see that you've already come to some kind of agreement about these 
structures... so I need to take a look at what you decided before 
opening my mouth again.

Sorry about the noise!

-- 
Mariano