Hi all,
I'm having some trouble with S and C and would like to find out the root
cause, and which ways to deal with that are available.
The basic situation is that S and C do not show their members in the
source code, the members are created dynamically during import.
This is a nifty usage of Python's dynamic features, but it's giving code
analysis tools a really hard time.
For example, for every occurrence of C.<whatever> in SymPy, Eclipse
Pydev spits out a warning that C.<whatever> isn't present in class C.
Last time I ran that check, that was a four-digit number of warnings.
This in itself wouldn't be a problem. Pydev allows suppressing specific
kinds of warnings.
However, suppressing warnings can hide real problems. E.g. if a member
of C is renamed/removed during refactoring, but there's still a
reference to it somewhere inside SymPy, and unit tests happen to miss
the situation that would trigger the error.
For this reason, I'd like to eliminate the irrelevant warnings.
There are two issues that are blocking me from moving forward with this:
1) I do not fully understand what C and S actually do.
C says that it is needed to avoid problems with cyclic imports, but it
does not describe what the problem exactly is, or how having C avoids
those problems.
For S, it's similar to C but not saying anything about cyclic imports,
so I'm wondering if that's just not documented or whether S does indeed
serve a different purpose than C. S' purpose also remains unclear - it's
a singleton mechanism, I can see that easily, but if it's just an
implementation vehicle, I don't understand why all singletons are made
into members of S - the construction should rather be that S provides
the singleton machinery and classes that need a singleton use a member
that's a subclass of S.
2) I'm not sure how C and S are being used "in the wild", so I don't
know which kinds of publicly visible changes will break code of SymPy
users. This makes it hard to decide how to fix the problem, or whether
fixing it is even worth the potential breakage.
Here's a short list of approaches that could be explored. I'd like to
know what you people think about each:
a) Turn S into a pure implementation vehicle, making S instances into
hidden members of all classes that need a singleton.
I think some initialization code populates S with singletons that are
available to user code, so that would break a lot of user code. It would
be the conceptually cleanest approach for S (if S was indeed intended to
be just an implementation vehicle).
b) Eliminate C, solve the import cycle problems in some other way (one
could shortcut the second invocation of the import, or the cyclic
dependency could be factored out into a separate module that's imported
by all classes that are part of the cycle).
This could break huge amounts of user code because people tend to use
C.<whatever>. It would require changing all the call sites to C inside
SymPy itself (something I'm willing to do so, sacrifices must be made).
C) Make sure each member exists as source code.
E.g. extend C and S with a stub for each member that gets introduced by
some other module. The stub just throws an exception that says "Please
import module Foo to use C.bar" so that people get meaningful error
messages if they forget to import something that should have populated C
(or S).
This adds another clerical task on anybody who wishes to extend C or S
with a new member. On the other hand, it will give them a heads-up if
they create a name conflict, or make them look whether what they're
adding isn't already available under a slightly different name, so it
can be argued that that's not just bad.
D) Leave everything as it is, declaring it's not worth it.
Obviously, I would like to do something else than D, but I need input to
decide whether that's actually a good idea and whether it should be A+B
or C, or something else altogether.
Thoughts? Comments?
Regards,
Jo
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
