Right now, there are a handful of changes that need to be done.

Check this out :

For example, in conversions like the one below, method names can't really be used as effectively to convert the units.

# Watts to Ohms given Amps
def w_to_o(watts, amps):
    return watts / (amps * amps)

# Watts to Ohms given Volts
def w_to_o2(watts, volts):
    return (volts * volts ) / watts

Right now, most units are converted using the abbreviations from the user input (ex: cm to in) and then selecting the method based on those abbreviations (cm_to_in method), but would like to move to a more widely compatible method for using the API in other projects where user input isn't important.

For reference, this is how the correct method is selected.

conversion_method = units_from + '_to_' + units_to # Name of method to use
thismodule = sys.modules[__name__] # This module as object

try:
   value = getattr(thismodule, conversion_method)(value)
    return str(round(value, decimal_places)) + units_to
except AttributeError:
   return 'Incompatible units.'

1 N = 7.23301 Poundal is what is known.
The code converts as newtons * 7,23301 instead of newtons * 7.23301

Another useful conversion would be number base conversion. A user should be able to enter an number in one base, and provide the base they would like to convert it to and be returned the converted value.

Example input the user would provide:

[*] Enter a unit to convert from: 2 (or B2, meaning Base 2/binary, might be a better option)
[*] Enter a unit to convert to: 8 (or B8, meaning Base 8/octal)
[*] Enter a value to convert from B2 to B8: 1001100

Then the output would be something like: 1001100 in B8: 114

I would love to see the project more structured so it could be better tested (i know: nobody likes to write tests, but they are extremly helpful whenever i had rewritten the convert function selection)

http://docs.python-guide.org/en/latest/writing/structure/
^^^ Could be one possibility to structure the project ^^^

Looking to implement units of pressure (Pa, bar, atm, Torr, psi).

Currency conversion requires requests. A requirements.txt should be added so this and any future dependencies can be retrieved.

Right now, the input is being checked twice for proper syntax and this is redundant. For example, this line is repetitive and can be handled in a better way.

• Any number can be converted into moles, so just having a check for if the input contains "mol" in it before all of the method checks (before the "Check the rest of the conversion factors" comment in unit_converter.py) is fine.
• Essentially just a "moles" method that takes conversion factors of two different units.
• Use 6.022140857e23 for the Avogadro constant.

For example, the following could be turned into one method just by having an "inverse' parameter.

The existing two methods:

# Newtons to Dynes (dyn)
def n_to_dyn(n):
    return n * 10 ^ 5


# Dynes to Newtons (n)
def dyn_to_n(dyn):
    return dyn * 0.00001  # Precision of 5 significant digits

could be turned into one:

# Newtons (N) and Dynes (dyn)
# Decimal value, boolean inverse
def n_dyn(value, inverse):
    if inverse:
        return value / (10 ^ 5)

    return value * 10 ^ 5

This would require a rewrite of the method selection function that would allow it to select the function that has both the units_from and units_to in the name, and then decide if it's units_from_units_to , in which case inverse should be false, or if not then inverse should be set to true. Implementing this will require a bunch of changes to multiple files.

Google supports conversion of timezones. I ask what time it is in Tokio when it is 10 am in Berlin.
Maybe this conversion could be implemented.

If anyone has any ideas for a logo, or would like to take a shot at creating one, feel free.

Converted result should return as many significant digits as the input number with the fewest significant digits.

Below is a table from Wikipedia with units of force that can be clearly implemented using the module's current format.

A lot of people have Python2 as their default python interpreter. Currently, the code fails to run on python2. Here is the stacktrace :

$ python unit_converter.py
Python unit converter by mattgd.
     
Units supported:
     Circle     : radians (r), degrees (d) 
     Temperature    : Celsius (c), Fahrenheit (f), and Kelvin (k) 
     Speed      : Kilometers/hour (kph), miles/hour (mph), knots(kt) .


[-] Example entries: 1.345/r/d, 33/f/c, 2/mph/kph

[*] Enter a value and units to convert from and to: 33/f/c
Traceback (most recent call last):
  File "unit_converter.py", line 295, in 
    number = input('\n[*] Enter a value and units to convert from and to: ')
  File "", line 1, in 
NameError: name 'f' is not defined

Users should be able to convert from one unit to the same unit using any of the aliases in _internal_accepted_names.

For example: Celsius to C, or °f to Fahrenheit.

Maybe like some kind of menu:
Temperature
Force
Energy
...
And if entering one of the highlighted characters opening a submenu with all of the possible units for that category

And/Or if one unit is already entered show in which unit i can convert the already given unit.
e.g.: Program asks to enter a unit to convert from. Me entering "kph". Program asks me to enter a unit to convert to. Me asking the program to show me all possible units i can convert to. Program answers with "kt" and "mph". -> Then normal program execution.

To solve this one could use the already inflated UNITS array and only show all category names or all units in one category.

Possibly use an API like Fixer.io, which is updated daily.

• Implement energy units (Joule, BTU, Calorie)
• Implement power units (Watt, Horsepower)

Right now UnitConverter is more of a command line script, but it may be more useful if it could be used like a proper API.

This shouldn't be too difficult with some refactoring of the convert_units(value, from_unit, to_unit, **args) function, but we should also make use of exceptions where appropriate.

Please feel free to take a stab at this and/or discuss possible designs and their pros/cons below.