Naming classes, functions, methods, etc

[GoogleCodeExporter]

=> Use CamelCase to name Python classes.

1) Functions in sympycore are classes (derived from Function) but also
behave like Python functions (Function is an instance to ClassType).

2) Mathematica uses CamelCase for naming functions.

1+2) => Use CamelCase to name sympycore functions like Sin, Cos, etc.

=> Expose public methods of Basic instances as Python functions.
   Use camelcase as that is Python convention for naming both
   functions and methods + these functions are generic Python
   functions:
     def expand(expr,..): return sympify(expr).expand(..)

=> sympycore defines number of singletons:
     oo, Pi, E, I
   that names look ok.

-> There will be additional singletons of classes RealSet, ComplexSet,
   IntegerSet, RationalSet, PrimeSet. Proposed naming for the instances
   of these singletons classes follows from Mathematica:
     Complexes, Reals, Rationals, Primes

-> sympycore defines also Empty and Universal as instances of
   EmptySet and UniversalSet, respectively

-> The set of even and odd integers are expressions of the above
   singletons: 
    Divisible(Integers, 2)
    Complementary(Divisible(Integers, 2), Integers)
   respectively. Proposed naming for these instances are:
    Evens, Odds
   respectively.

Note that Python style guide does not say much about naming
global variables more that 'hopefully they are global to
a module that defines them'. This is obviosly not the case
for us.

Original issue reported on code.google.com by pearu.peterson on 21 Oct 2007 at 10:00

[GoogleCodeExporter]

Arguments for exposing public methods as Python functions:

* Allows functional programming (compositions, etc)
* User doesn't need to call sympify() on input
* Functions are easier to find in documentation
* We can change the method API without affecting the public user interface

One question is: should all functions, including "expression operators" like 
expand
(as opposed to mathematical operators like diff) be named in CamelCase as well 
(e.g.
Expand)? I think they probably should; naming all public functions the same way
(optionally implementing them as Basic subclasses as well) would be most 
consistent.

Original comment by fredrik....@gmail.com on 5 Nov 2007 at 5:15

[GoogleCodeExporter]

I have no objections on exposing public methods as functions.

However, could you explain why do you prefer CamelCase for
functions while Python style guide recommends camelcase?
Note that I am ok with either way (as long as it is done consistently)
but some like to follow Python guide lines and so I would
choose camelcase as a first choice.

Original comment by pearu.peterson on 5 Nov 2007 at 7:34

[GoogleCodeExporter]

Mainly for consistency. I don't think it's a particularly important issue.

Original comment by fredrik....@gmail.com on 5 Nov 2007 at 7:47

[GoogleCodeExporter]

I have no objections on these, I think it doesn't matter that much, as long as 
it is
simple and follows Python conventions when possible.

It's true that it will be more work when integrating these changes in SymPy, but
that's the purpose of sympycore to create the best interface, without fearing of
breaking things. So let's do it.

Original comment by ondrej.c...@gmail.com on 5 Nov 2007 at 8:28

[GoogleCodeExporter]

http://www.python.org/doc/essays/styleguide.html says:

"A style guide is about consistency. Consistency with this style guide is 
important.
Consistency within a project is more important. Consistency within one module or
function is most important."

In fact, it also says:

"Plain functions exported by a module can either use the CapWords style or 
lowercase
(or lower_case_with_underscores). I have no strong preference, but believe that 
the
CapWords style is used for functions that provide major functionality (e.g.
nstools.WorldOpen()), while lowercase is used more for "utility" functions (e.g.
pathhack.kos_root())."

There, Guido said it ;-)

However, he appears to have changed his mind more recently. The revised style 
guide
at http://www.python.org/dev/peps/pep-0008/ says:

      Function names should be lowercase, with words separated by underscores
      as necessary to improve readability.

      mixedCase is allowed only in contexts where that's already the
      prevailing style (e.g. threading.py), to retain backwards compatibility.

Nothing about uppercase. Of course; that PEP is intended for the Python standard
library. While it's a good idea to follow it generally, there's always room for
making reasonable exceptions.

We have some good reasons for using uppercase:

* Avoid name clashes with builtins (e.g. abs/Abs, max/Max)
* Mathematica is a good precedent

Original comment by fredrik....@gmail.com on 5 Nov 2007 at 8:57

[GoogleCodeExporter]

Well done research. :) My own taste is also for lower case functions, but I 
don't
have a strong opinion on this.

Original comment by ondrej.c...@gmail.com on 5 Nov 2007 at 9:05