On Dec 19, 6:03 pm, Christopher Lee <[email protected]> wrote:
> - 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() Maybe it could be made even be simpler than the way it currently works. Meaning that the default pygr.Data instance is constructed upon importing pygr. One may use that in most cases or make their own with some aptly named and customizable constructor. For example the default Data would in fact correspond to an initialization like this: Data = pygr.DataPath( rcfile='.pygrdata', namespaces=["Bio", "Test"], layers=["my", "here"] ) () Some of the issues that I have with the module occur while generating data in exploratory data analyises, when I want to isolate pygr.Data's to a single folder. I can do that via the environment variable externally, that means editing, sourcing the shell etc. can be confusing and tedious. It is great that pygr.Data offers a common view of all the data from any program, but it should also be easy to create and use isolated repositories that can be deleted without worry. > - 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. Yes that is great idea, I always liked that one can just start working with it. > - subclassing the namespace class is an interesting idea, but can you > give examples of what you wanted to use that for? Well I think of pygr.Data like a database, and one of the most powerful features of databases (the good ones) is that you can set up triggers and rules. For pygr.Data the analog behavior would be to set up some type of callback functions that execute when you manipulate data. Here is a subclass that I think would be useful. Say we plan to add lots of gff files to pygr.Data from various sources. I want it to check that the files that we add have indeed the right number of headers and columns. Basically adding a simple type checking to the saving step. You could create a type checker and remember to run it on any file before saving them, or the more elegant solution would be to create a custom pygr.Data() (and ResourcePath) class that has a callback that executes when saving to pygr.Foo.Bar.Gff and does this seamlessly. best, Istvan --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
