Comment #5 on issue 950 by [email protected]: put all _sage_ methods to one
place
http://code.google.com/p/sympy/issues/detail?id=950
As I understand the same (about Ronan's "Having to hack the core") is with
_pretty_ and so on. Is not this?
I cite the old correspondence (the answer of Aaron to my first letter in
this mail-list, on wich I have not time to answer myself):
http://www.mail-archive.com/[email protected]/msg06813.html
Aaron wrote:
"By the way, I am assuming from the name and from the fact that you want to
do
this that MyClassExpr is inheriting from Expr. How would this work if your
class is a part of some other SymPy class, like an Add or a Mul? I'm not
too
familiar with how it works, but I know that pretty() internally has some
bounds
stuff to make the 2-dimensional printing work correctly with each other
(like
if you have an expression that is 3 lines tall surrounded by parentheses,
then
you need parentheses that are 3 lines tall). Would your idea work
seamlessly
with this?"
The current situation is that:
* we have base class (Basic with _sage_, or Expr with _pretty_), others
inherited classes (SameExpr), and the processor (sage.var or prettyPrint),
somewhere.
But processor have its own internal station.
* while the task of process with sage or pretty print arise then processor
created for parsing expression in recurrence (or more complicated) mode.
* when processor parse SomeExpr then
#1 it check if in Processor class or Basic class the method like
_pretty_SomeExpr exists
This way allow to the processor use its own state's variables, which it
keeps.
if #1 is not then:
#2 it check SomeExpr._pretty_ method existence and call it
But the situation for #2 as that that while calling SomeExpr._pretty_ he do
not supply processor (and state) itself.
In such a way the dilemma is raised how to isolate code and where to place
implementation:
On the one hand SomeExpr._pretty_ do not know about precise processor
implementation
On the other processor do not know precisely about SomeExpr.
The variant which had chosen is to place implementation to the processor,
or to base Basic._pretty_.
My opinion is that #2 must be corrected to permit calling with additional
unnecessary parameter - processor.
In this way I can fully create class with _sage_ or _print_ handlers in
isolated mode, without modification of any core files of Basic or Epr, and
at the same time I can operate with the state of processor, and (only if it
really needed) I can also modify only processor code.
I suppose that the task which described here is solved by adding a two
lines (near #2 checking), and by adding unnecessary parameter in _pretty_
definition of *all classes*.
I am going to make experiment about this reorganisation of architecture,
but before the idea must be discussed - all remarks are welcome.
May be it must general way for _handler_ like handlers, or there are
specificities for _sage_ or _pretty_ ways.
--
You received this message because you are subscribed to the Google Groups
"sympy-issues" 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-issues?hl=en.
