Convenience tweaks for Aggregation class (python)
Ben O'Steen
don't know ORE:
E.g.
#1 adding an __iter__ method to allow "for AR in Aggregation:" type
uses
#2 adding a __len__ method to allow len(Aggregation) (returns no. of
AR)
and even allow for:
a = Aggregation(uri)
a.append(AggregatedResource(uri))
Good or bad idea?
Rob Sanderson
On Tue, 2008-06-10 at 02:11 -0700, Ben O'Steen wrote:
> #1 adding an __iter__ method to allow "for AR in Aggregation:" type
> uses
> #2 adding a __len__ method to allow len(Aggregation) (returns no. of
> AR)
Done.
> and even allow for:
> a = Aggregation(uri)
> a.append(AggregatedResource(uri))
This can't be in place of add_resource() as it takes an optional proxy.
However it can simply call add_resource() and have proxy default to
None.
Equally .remove() should work in the same way.
I've added these and put into subversion.
Other list methods:
* Aggregation[n] --> nth aggregated resource?
I'm wary of this as the order in an aggregation is not specified. This
is for two reasons -- Atom doesn't have an order, and graphs certainly
don't have orders. index() sort() reverse() pop() insert() all have the
same problem.
Of course there /is/ an order, the order in which the objects were added
to the aggregation.
* AggRes in Aggregation --> boolean?
Is it really useful?
* Aggregation.extend(Aggregation2)
Would you ever want to smash two aggregations together?
* Aggregation.count(AggregatedResource) --> 0/1
Totally Pointless.
Thoughts?
Rob
Benjamin O'Steen
On Tue, 2008-06-10 at 11:02 +0100, Rob Sanderson wrote:
>
> On Tue, 2008-06-10 at 02:11 -0700, Ben O'Steen wrote:
>
> > #1 adding an __iter__ method to allow "for AR in Aggregation:" type
> > uses
> > #2 adding a __len__ method to allow len(Aggregation) (returns no. of
> > AR)
>
> Done.
A+ :)
> > and even allow for:
> > a = Aggregation(uri)
> > a.append(AggregatedResource(uri))
>
> This can't be in place of add_resource() as it takes an optional proxy.
> However it can simply call add_resource() and have proxy default to
> None.
>
> Equally .remove() should work in the same way.
> I've added these and put into subversion.
Extra credit :)
>
> Other list methods:
>
> * Aggregation[n] --> nth aggregated resource?
>
> I'm wary of this as the order in an aggregation is not specified. This
> is for two reasons -- Atom doesn't have an order, and graphs certainly
> don't have orders. index() sort() reverse() pop() insert() all have the
> same problem.
> Of course there /is/ an order, the order in which the objects were added
> to the aggregation.
I agree with you, but I'm not sure about whether it would be a great
idea to expose it as a linear list. Maybe just documenting the
Aggregation as a unordered list and for users not to rely on a
particular ordering due to the __iter__ method will be enough.
>
> * AggRes in Aggregation --> boolean?
>
> Is it really useful?
Not in a 'is Object in List' way, but maybe in a 'is URI_AR present as
either an AR or in a Proxy in Aggregation'
So not an object == object, but a object1.uri == object2.uri or
object1.uri in Proxy.uris
End of day so forgive me if I am not clear here
Leads on slightly to another pythony thing, what should __str__ do as
methods of the objects in the toolkit? respond with the uri?
i.e. what should >>> print Aggregation, AggregatedResource, ResourceMap
do?
>
> * Aggregation.extend(Aggregation2)
>
> Would you ever want to smash two aggregations together?
Not really, but I can see a case for a union, resulting in a third
Aggregation.
MungedAggregation = A1.union(A2)
or
MA = Aggregation.union([A1, A2]) # or pick-your-syntax
>
> * Aggregation.count(AggregatedResource) --> 0/1
>
> Totally Pointless.
Yep :)
>
> Thoughts?
Fantastic work, Rob, congrats :)
>
> Rob
>
>
> >
Robert Sanderson
> Other list methods:> * Aggregation[n] --> nth aggregated resource?
> I'm wary of this as the order in an aggregation is not specified. This
> is for two reasons -- Atom doesn't have an order, and graphs certainly
> don't have orders.
I agree with you, but I'm not sure about whether it would be a great
idea to expose it as a linear list. Maybe just documenting the
Aggregation as a unordered list and for users not to rely on a
particular ordering due to the __iter__ method will be enough.
As of Python 2.4, there's a builtin set type:
http://docs.python.org/lib/types-set.html
which we could expose as an api for aggregations, but I'm not sure how commonly used sets are compared to lists or dicts?
> * AggRes in Aggregation --> boolean?
> Is it really useful?
Not in a 'is Object in List' way, but maybe in a 'is URI_AR present as
either an AR or in a Proxy in Aggregation'
So not an object == object, but a object1.uri == object2.uri or
object1.uri in Proxy.uris
End of day so forgive me if I am not clear here
Yep, that sounds handy... esp as there are two entries to whether x is in a or not, as you say, the proxy and the resource itself.
Leads on slightly to another pythony thing, what should __str__ do as
methods of the objects in the toolkit? respond with the uri?
i.e. what should >>> print Aggregation, AggregatedResource, ResourceMap
do?
Good question. The uri seems the most sensible thing?
> * Aggregation.extend(Aggregation2)
> Would you ever want to smash two aggregations together?
Not really, but I can see a case for a union, resulting in a third
Aggregation.
MungedAggregation = A1.union(A2)
or
MA = Aggregation.union([A1, A2]) # or pick-your-syntax
Which would be a vote in favour of exposing the set API, I guess?
> Thoughts?
Fantastic work, Rob, congrats :)
Thanks :)
Rob