Make a class with a string name pass _test_args

[Sergiu Ivanov]

Hello,

I have a class Object, which has one meaningful attribute: a string
name. If I store the string name directly in Basic.args, Object will
not pass _test_args, because the only element of the tuple Basic.args
is a string, and is not an instance of Basic. Some other classes
(like IndexedBase) store an instance of Symbol with the proper name in
Basic.args.

What would be my best bet? Store a Symbol in Basic.args instead of a
string? Or is there a different canonical way to approach this
problem?

Sergiu

[Aaron Meurer]

Either use Symbol (directly or by subclassing) or look at how Symbol
does it. I think the key for Symbol is that it subclasses from Atom,
so it has an empty .args. Also, it overrides _hashable_content so that
it hashes correctly.

Aaron Meurer

> --
> You received this message because you are subscribed to the Google Groups "sympy" group.
> To post to this group, send email to sy...@googlegroups.com.
> To unsubscribe from this group, send email to sympy+un...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/sympy?hl=en.
>

[Sergiu Ivanov]

On Sun, Jun 10, 2012 at 11:24 PM, Aaron Meurer <asme...@gmail.com> wrote:
>
> Either use Symbol (directly or by subclassing) or look at how Symbol
> does it. I think the key for Symbol is that it subclasses from Atom,
> so it has an empty .args. Also, it overrides _hashable_content so that
> it hashes correctly.

Symbol has an empty .args.

However, I seem to have just got an asnwer from one of Tom's new
comments on my pull request [0]: store a Tuple(name). Is this going
to be OK?

I'm just afraid that using Symbol will bring too much stuff into my
simple class.

Sergiu

[Tom Bachmann]

Hi,

I have been slightly worried about having strings in the .args. I have
been wondering for a while now if it might be better to replace the
"name" attribute with a more generic "payload" attribute, which is used
to identify objects. You could still keep the "name" parameter, and in
the __new__ method construct a Symbol of that name as payload. Note that
this way you could put in Dummy as payload as well, and get anonymous
objects for free (as far as I can tell)!

This is just a suggestion, I don't feel strongly about it; but I think
it might be the easiest solution.

On 10.06.2012 21:27, Sergiu Ivanov wrote:
> On Sun, Jun 10, 2012 at 11:24 PM, Aaron Meurer<asme...@gmail.com> wrote:
>>
>> Either use Symbol (directly or by subclassing) or look at how Symbol
>> does it. I think the key for Symbol is that it subclasses from Atom,
>> so it has an empty .args. Also, it overrides _hashable_content so that
>> it hashes correctly.
>
> Symbol has an empty .args.
>
> However, I seem to have just got an asnwer from one of Tom's new
> comments on my pull request [0]: store a Tuple(name). Is this going
> to be OK?
>

My comment regarding Tuple was that it should be replacing the list of
components you are storing, not the name.

[Sergiu Ivanov]

On Sun, Jun 10, 2012 at 11:32 PM, Tom Bachmann <e_m...@web.de> wrote:
>
> I have been slightly worried about having strings in the .args. I have been
> wondering for a while now if it might be better to replace the "name"
> attribute with a more generic "payload" attribute, which is used to identify
> objects.

In abstract categories, objects are really just names. There's
absolutely nothing else about them, in the most abstract setting.
Absolutely no internal structure whatsoever :-)

The things which is usually perceived as internal structure is
described from CT point of view either by showing how an object
interacts with morphisms (e.g., if 0 is the trivial one-element,
group, then, for any group G there's exactly one homomorphism from G
to 0) or by using functors (that's beyond the scope of my project for
the summer; I hope to implement them later, though). In fact, there's
one subtle point in CT: objects don't matter; they are just a matter
of convenience. From what I know, the whole CT can work fine without
objects at all :-) (the principle is: forget objects, take identity
morphisms).

In practise, I expect to see additional data to appear in subclasses
of Object, but I'm not yet sure as to when one would want to subclass
from Object.

That's why Object doesn't have anything but a name. However, should
there arise a need for something else, it will be very easy to add
stuff to Object, of course.

> You could still keep the "name" parameter, and in the __new__
> method construct a Symbol of that name as payload. Note that this way you
> could put in Dummy as payload as well, and get anonymous objects for free
> (as far as I can tell)!

Oh, wow, that sounds much more lightweight that Symbol! Great, thank
you!

> This is just a suggestion, I don't feel strongly about it; but I think it
> might be the easiest solution.

I'll go for it in the meantime.

> On 10.06.2012 21:27, Sergiu Ivanov wrote:
>>
>> On Sun, Jun 10, 2012 at 11:24 PM, Aaron Meurer<asme...@gmail.com>  wrote:
>>>
>>>
>>> Either use Symbol (directly or by subclassing) or look at how Symbol
>>> does it. I think the key for Symbol is that it subclasses from Atom,
>>> so it has an empty .args. Also, it overrides _hashable_content so that
>>> it hashes correctly.
>>
>>
>> Symbol has an empty .args.
>>
>> However, I seem to have just got an asnwer from one of Tom's new
>> comments on my pull request [0]: store a Tuple(name).  Is this going
>> to be OK?
>>
>
> My comment regarding Tuple was that it should be replacing the list of
> components you are storing, not the name.

I was going to abuse Tuple ;-)

Sergiu

[Tom Bachmann]

On 10.06.2012 21:47, Sergiu Ivanov wrote:
> In abstract categories, objects are really just names. [...]

>
> That's why Object doesn't have anything but a name. However, should
> there arise a need for something else, it will be very easy to add
> stuff to Object, of course.
>

Sure, I was not suggesting making the "payload" so general that it would
suffice to implement all concrete objects. My only point was that "name"
need not equate to "string" (and that we already have a class which is
used to identify objects).

>> You could still keep the "name" parameter, and in the __new__
>> method construct a Symbol of that name as payload. Note that this way you
>> could put in Dummy as payload as well, and get anonymous objects for free
>> (as far as I can tell)!
>
> Oh, wow, that sounds much more lightweight that Symbol! Great, thank
> you!
>

Glad to be of help.

[Sergiu Ivanov]

And here comes part two of the show :-( How do I store a Boolean flag
in .args? Or should I make it an assumption? (wild eyes).

What I need is as follows. I have a class Morphism, which can be set
to be an identity by specifying a flag at initialisation. This sounds
a lot like something assumption-related, but my experience with
assumptions is so very limited that I'm not sure.

If this should really be a part of assumptions, could you please
suggest an example which I could follow? I know there are the "old"
and the "new" assumptions, but which one is which completely evades my
grasp.

Sergiu

[Aaron Meurer]

What difference does it make if it's an identity or not? My first
instinct would be to make it a separate class (you can still make it a
flag and use __new__).

Aaron Meurer

[Tom Bachmann]

On 11.06.2012 00:38, Aaron Meurer wrote:
> What difference does it make if it's an identity or not? My first
> instinct would be to make it a separate class (you can still make it a
> flag and use __new__).

Yes, that's what I would do. Just create subclass IdentityMorphism.

[Sergiu Ivanov]

Believe it or not, I had the same idea when I was already falling
asleep :-) I'll do the change, thank you.

Sergiu