On Dec 19, 2008, at 7:59 AM, Istvan Albert wrote: > One question: what is the rationale for having pygr.Data a module > level namespace. While I can't say that I understand all the > internals, it appears that turning a module behavior into a class > instance like behavior brings about some unexpected problems and > complex or annoying behaviors. The question then is why not make it > into a class right away: > > data = pygr.Data() > data.Bio.Test.Download() > > that way one could customize the constructor by passing various > parameters, allows subclassing, and overall makes it a lot easier to > add other types of functionality without having to modify the main > module. I am playing around with this right now a bit, to see if it > was feasible.
Yes, I've been thinking along similar lines: - fundamentally, pygr.Data aimed to create a "namespace for all the world's data". Accessing this namespace by the Python import statement (i.e. the namespace is a module) is an intuitive, one-step operation. For that reason and data integrity concerns (see below), I implemented it as a module. But this clearly suffers some disadvantages that we've discussed. Turning this into an object would solve most of those problems, and we can probably make this just as simple to use. - One problem to bear in mind: to guarantee data integrity, different requests for the same ID must return the same Python object; that is what we mean when we say "Bio.Seq.Genome.HUMAN.hg17 is an identifier", i.e. the name has a one-to-one mapping to an actual resource. All sorts of subtle problems can occur if this basic persistence / integrity requirement is not guaranteed. We should be careful to retain this guarantee. - I'd like to keep the interface for accessing this as simple as possible, e.g. to access the namespace object, the user need do nothing more than type from pygr import Data I guess you were suggesting a two step process to access the namespace object: import pygr data = pygr.Data() - A user can pass arguments to the namespace object by calling its methods, just as easily as by passing arguments to its constructor. - I want the namespace object to work immediately upon import, without requiring an extra initialization step by default. If the user wants to add special conditions that change default behavior, he can call the object's methods to pass those arguments, before he starts using the namespace. - subclassing the namespace class is an interesting idea, but can you give examples of what you wanted to use that for? The top-level namespace object could be nothing more than an empty box representing the root of the namespace tree. The internal structure of pygr.Data (currently) has three basic classes: * namespace node (ResourcePath): pretty trivial -- it just implements __getattr__, __setattr__, __delattr__ to handle requests to retrieve, add or delete items from the namespace. You could subclass this but what exactly would you use that for? ResourcePath objects simply pass pygr.Data requests on to the... * ResourceFinder: this class implements most of the "business logic" of pygr.Data: it provides the getResource interface that a user can call directly to perform various operations on data and schemas in the namespace. It relays these requests to the... * resource database classes: these actually store and retrieve data and schema in a particular backend. There is one such class for each type of storage (shelve, mysql, XMLRPC at present). I can easily imagine people wanting to write their own resource database class for a different kind of storage... The pygr.Data module creates a single ResourceFinder instance during import. This object acts as the gateway for all pygr.Data requests, and guarantees that multiple requests for the same ID will return the same Python object. Yours, Chris --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pygr-dev" 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/pygr-dev?hl=en -~----------~----~----~----~------~----~------~--~---
