wiki:Orange25

Version 12 (modified by marko, 3 years ago) (diff)

Goals

Basically, the goals are the beauty of the interface and backwards compatibility. Let's be a bit more specific:

  • New structure. Adhere to the pythonic naming; in particular, replace camelCase with underscore_separated methods.
  • Backwards compatibility needs to be retained at any cost (old scripts and widgets have to work in their unmodified form). If it would not take too much work empty the old module. If you decide that this would introduce too many bugs leave the old module as it is.
  • Everything that was documented prior to 2.5 has to be documented now.

Documentation

Described on the rst documentation page.

Notes

 EtherPad page

Conventions

Names of methods, functions, (object) attributes and keyword attributes of functions should all be underscore_separeted. Janez has modified the wrapper which allows access to C++ code with both names and Ales has written name deprecation decorators for Python code.

As in Python (Miha has checked the sources code of standard modules), abbreviations should also be in lower case. For example, we should rename AUCWilcoxon to auc_wilcoxon (and not AUC_wilcoxon).

Classification methods (learners) are objects named with method followed by Learner:

Orange.classification.rules.CN2Learner()

C++ underscores vs. camelCase

The names of attributes and methods in C++ classes have been modified to underscore form (Value.var_type instead of Value.varType). Class names are in CamelCase (e.g. BayesClassifier). Names of functions within the module, e.g. orange.getClassDistributions are still in mixedCase.

Old names still work, except for referencing of unbound methods. E.g.

v = orange.EnumVariable(); v.getExisting()

is OK, but

orange.EnumVariable.getExisting()

is not. Former is uncommon, but needs to be found and modified manually.

For refactoring, mapping of names can be found in source/orange/aliases.txt, source/_underscored and source/_underscored_manual.

Things to check/fix later

Aliases in C code to make

  • Floating-point numbers and functions are formatted in a weird fashion when enumerating default function parameter values.
  • Base classes are determined inappropriately for our needs: for example, orange.RuleLearner is written (and linked) instead of its alias Orange.classification.rules.RuleLearner (or at least Orange.core.RuleLearner).

Refactoring tool orange2to25.py

In orange directory there is a orange2to25.py script

  • Use it like this (this will output a diff of proposed changes):
    python orange2to25.py myscripy.py
    
  • To overwrite the myscript.py (a backup will be saved in myscript.py.bak) use:
    python orange2to25.py -w myscripy.py
    
  • To use an aggressive name changer add the '-a' flag (will fix names in the global and local scope, e.g. it will replace ExampleTable (without the orange. prefix) with Orange.data.Table and import the appropriate package (Orange.data))
    python orange2to25.py -w -a myscripy.py
    
  • To write the changed script to a new file use '-o' argument
    python orange2to25.py -w -o mynewandimprovedscript.py myscript.py
    
  • For help type:
    python orange2to25.py --help
    

Adding mapped names and modules

Currently there are only a few MAPPING definitions in the both fixers available. Add all changed names and moved modules to the appropriate file:

  • Add other mapped names to orange/fixer/fix_changed_names.py in the MAPPING global variable (For instance .. "orange.ExampleTable":"Orange.data.Table", ...)
  • Add mapped modules to orange/fixer/fix_orange_imports.py in the MAPPING global variable (For instance ... "orngSVM": Orange.classification.svm", ...)

Reference documentation for conversion

Choose a part from the list below.

Data structures

  • Convering to/from Numeric and GSL (Janez)
  • Loading and saving data
  • Attribute types defined in Python

Preprocessing

  • Filters
  • Sampling - Orange.data.sample
  • Removal of unused attribute values

Miscellaneous classes

  • Cost matrix
  • Symmetric matrices
  • Probability estimation
  • Finding nearest neighbours
  • Generating subsets of attributes
  • Value transformers

Classification, Regression, Clustering

  • Simplify a network
  • Classifiers from Attributes
  • Classifiers in Python
  • Clustering
  • Random classifier

Other Topics

  • Random numbers
  • Subtyping Orange classes in Python
  • Extending Orange in C++

Still needs porting

  • orngIO
  • orngCA
  • orngCI
  • orngEnviron -> Orange.misc.site (Podobno kot python site module, morda .conf)
  • orngDimReduction, orngPCA -> Orange.projection.pca
  • orngInteract, orngInteractions
  • orngMCPrediction, orngMultiClass, orngMultivariatePrediciton
  • orngMySQL, orngSQL -> (Orange.data.io ?)
  • orngPade
  • orngProjectionPursuit
  • orngLinProj
  • orngLinVis, orngLinVis,
  • orngScaleData, orngScaleLinProjData, orngScalePolyvizData, orngScaleScatterPlotData
  • orngVisFuncts, orngVizRank
  • orngMosaic
  • matutil, fileutil, (widgetParser??)
  • updateOrange
  • orngContingency, orngInteract, orngCRS, orng2Array, orngDimRed