Hi--
This seems as good a place as any to mention something I'd been trying to
do some time ago where I ran into the same battle versus __slots__.
I wanted to add a description attribute to my Symbols for documentation
purposes. I use Sympy almost exclusively inside of the IPython notebook
for engineering work, and wind up with long sheets of derivations,
substitutions, dead end attempts, etc. I'm also trying to build up a
personal library of formulas that I can import.
The problem I run in to is eventually, either due to complexity or time, I
can't keep track of what all my symbols mean. I like to keep the names
themselves short so the symbolic output is easily understandable, but that
relies on really strong conventions and a good memory to interpret-- which
aren't always present... =/
One solution was to put the description into the text of the notebook,
which I often do, but then I have to find the place where that Symbol was
defined to locate the descriptive text-- and then need to scroll back to
the active cell to edit, then back and forth.
The solution I was after was to add a x.desc string to the Symbol, so I
could just ask the Symbol itself what the hell I intended it to mean. I
then could modify Symbol to pretty print "F_{B}: the force of the bat". If
I got really energetic, I'd change Expr to pretty print:
"F_{B}=m_{b}*a_{b}
Newton's Second Law of Motion where:
F_{B} is the force of the bat
m_{b} is the mass of the ball
a_{b} is the acceleration of the ball"
For all the maintenance reasons you describe, these are changes that should
happen in the Sympy library itself, but it's easier for me to experiment in
my own sandbox without upsetting the core code and the __slots__ prevents
this. There's also the chance that I can't convince enough people this
should be a core part of the library, or to implement it in the way I'd
like, and then I'm stuck.
Maintenance isn't quite as big an issue for me as I'm not building long
standing applications-- I'm generating documents. Sure, I'd like those to
remain viable for as long as possible so I can edit them in the future, but
it's not the same has having deployed a large codebase. If I have to go
through and change all my references from .desc to .desc2 for my notebook
to run, it's not the end of the world.
Storing all of this in an outside data structure does have the potential
advantage in that I could then look up a symbol if I knew what it meant but
not its symbolic representation:
SymbolIndex['accel ball']
or find all the formulas I have involving the ball:
ExpressionIIndex['ball']
ExpressionIndex[a_{b}]
but that would have required some deeper hacking into the Symbol creation
and destruction mechanisms.
Anyway, probably wandered off topic a bit, but I just wanted to put a vote
in for user attributes and the possible elimination of __slots__ if that
isn't a significant performance hit.
On Monday, May 18, 2015 at 10:29:42 AM UTC-7, Joachim Durchholz wrote:
>
> Am 18.05.2015 um 15:56 schrieb Carsten Knoll:
> > I want to equip an Symbol with an additional attribute to store some
> > specific information right in place.
> >
> > For 'normal' Python classes it is no problem to dynamically create an
> > additional attribute for an already existing instance.
> >
> > However, for sympy Symbols if I try
> >
> > x = Symbol('x')
> > x.k = 0
> >
> > I get the error
> >
> > AttributeError: 'Symbol' object has no attribute 'k'
>
> That happens because we use __slots__ for performance reasons.
> However, storing attributes in that way is a bad idea in general,
> because you risk name conflicts with future versions of SymPy. (That's
> also the reason why using subclasses to extend a library tends to break
> over time.)
>
> Alternative 1: You could set up a dict with a Symbol-to-attributes
> mapping: Symbols are hashable (that's a guaranteed property).
>
> Alternative 2: We could add a `userdict` attribute in Symbol, so that
> SymPy users can store additional attributes there.
>
> I'm not too happy with either alternative.
> Maybe we can give you better help if you describe your use case in some
> more detail.
>
> Regards,
> Jo
>
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sympy+unsubscr...@googlegroups.com.
To post to this group, send email to sympy@googlegroups.com.
Visit this group at http://groups.google.com/group/sympy.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/c81f5af8-ef92-4ddb-add0-eb0053c51a5f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
