Rename variables, proposed by issue #257

[mvargas33]

Closes #257 as suggested by @bellet . Tests pass as expected.

This refactor is relevant from a user perspective.

[terrytangyuan]

LGTM. PTAL @bellet

[bellet]

@mvargas33 We should avoid breaking compatibility right away: instead, you should keep older names with 'deprecated' value and have deprecation warnings for the next release (0.7.0), before we remove them permanently in 0.8.0.

See for instance what was done here: #193

[mvargas33]

@mvargas33 We should avoid breaking compatibility right away: instead, you should keep older names with 'deprecated' value and have deprecation warnings for the next release (0.7.0), before we remove them permanently in 0.8.0.

See for instance what was done here: #193

@bellet

So, the existing code is not broken anymore. Following #193 I've added a warning mentioning deprecation in each part of the code. These warnings are FutureWarnings in order to show them to end users. If I use DeprecationWarning the warning won't show up unless the user configure their program to show more warnings (according to docs and tested myself).

To take note:

• The pattern is to change the old name with a 'deprecated' value by default. If its not, the warning is triggered, and the value is assigned to the variable with the new name.
• The old name must have a value, otherwise some tests get broken, for instance, the check_estimator test from sklearn, checks that all params received in the constructor are set in the Estimator, including the deprecated one, even if it is not used anywhere.
• All tests have the new name now, not the old one
• No additional test were made to check if warnings are being triggered
• Maybe the docs needs an additional modification, just like in [MRG] Uniformize num_dims and add it for LMNN #193, but I did not do modified the docs.

[perimosocordiae]

Changes look good, merging.