Re: [Gnu-arch-users] Re: cached rev support in pyarch

[David Allouche]

On Fri, Jun 11, 2004 at 09:30:02AM -0400, Aaron Bentley wrote:
> David Allouche wrote:
> >The interface should look like:
> >
> >arch.Revision.cache(self, root=None)
> >
> >  Cache a full source tree for this revision in the archive.
> >
> >  DirName root: cache root for trees with pristines
> >    (NOTE: not sure how that should be used...)
> 
> The cachereving process needs a reference tree to create a cacherev.  If 
> you supply a cache root, it will search that tree for pristines of the 
> target revision or a related revision, to reduce/elimitate reference 
> tree construction.

Okay, but should the cache directory be a tree-root, or a directory
containing zero or more arch source trees?

> >The exception stuff is probably imperfect and still being thought out.
> >But the recent patches from abentley suggest there is a need for better
> >exception reporting. Comments welcome.
> 
> Ultimately, the exception stuff is hard, because you must either predict 
> errors, or interpret them afterward.  tla doesn't have a good way of 
> handling errors in itself either-- you've just got library functions 
> printing errors and exiting.

Yes, it is hard. But only cataloging the exceptional conditions and
raising them in the common case, even if there are corner cases, would
be vastly useful. Right now, I am still trying to figure out what would
be the correct exception classes.

I envision several solutions to the exception classification problem:

  1. Check input for sanity when it enters the pyarch framework.
  
     For example, functions which are given a string in place of a
     namespace object will first parse and validate the name, that can
     be as simple as instanciating the namespace object, which will
     eventually benefit from namespace objects interning.

     That should be done in arch.py.

  3. Interpret error messages.

     When a tla invokation fails, it raises an ExecProblem. The
     exception should contain a copy the stderr output of the command.
     Then the _tla.py commands can check the message for well identified
     errors and raise approriate exceptions.

     The scope of this solution is limited the risk of false
     positives.

  2. Diagnose after failure.

     When a tla invokation fails, some command in the call chain will be
     able to check for preconditions. Most of the time, when the check
     is not safe and race-free, the check should go in
     _tla.py. It might be possible to make the check in arch.py for a
     few cases.

     The goal here is to be correct and helpful most of the time.
    
  4. Fix libtla.

     Not there yet... but I think the work in PyArch will prove useful
     when libtla is actually done. All exceptions raised from within
     _tla.py, should eventually be reported by libtla.

> >PS: in a future version, I am considering dropping the iter prefix from
> >most (or all) commands which create iterators, not sure whether that
> >would be a good idea or not. What is your opinion?
> 
> I tend to agree that iter_ clarifies things.  Since Python doesn't have 
> explicit return types, it's hard to know without scanning for a "yield". 

In a chat on #python some time ago, I got the idea that Python3 will use
iterators much more pervasively.

For example, the dict.iterkey method (and friends) seems to be required
for backward-compatibility with code which relies on the return type of
dict.keys being list. The contracts will be weakened to replace most
occurences of "list" with "iterable".

However, trying to be forward compatible with the backward-incompatible
coding style of a version of Python which does not exist yet is maybe
overdoing it...

What annoys me most at the moment is functionality duplication, like
Category.iter_branches and Category.get_branches. The typical change I'm
considering is:

  - removing the Category.branches property

  - removing the Category.get_branch method

  - renaming Category.iter_branches to Category.branches
    (making it a method instead of a property)

Of course, since that would probably break a lot of code, that would
go only in the next version.

Simple feedback, like "makes sense", or "you're on crack", is welcome.


>  (OTOH, I know I didn't name the change classifier "iter_filechange"-- 
> maybe I should have.)

For consistence with the rest of pyarch, it should be called
iter_filechange. Do not worry, I'll handle it... I am doing some quite
heavy duty editing on your patches. When I'm satisfied with them, I'll
mirror the microbranches and ask you for feedback.

-- 
                                                            -- ddaa