> > Eh. Your suggestion conflicts with gz's. I do like the idea of letting the
> rest of bzrlib's guts tell me whether it's okay to declare a method, though,
> rather than handle an AttributeError myself. But you guys are more familiar
> with the gestalt of Bzr than I am, so perhaps I'm missing something?
>
> I think gz and I agree that there's no point in having redundant
> checks. As he says, we have to handle the case that it turns out not
> to be possible at runtime, and I guess it just seems a bit cleaner to
> me to avoid conditionally declaring functions. Either is ok though,
> so let me know when you're ready for this to be rereviewed/merged.
To be clear, I was trying to say the AttributeError handling is better written outside the method, but the functions still may throw EnvironmentError when called so that part had to be retained. It's a minor style point however.
> > Eh. Your suggestion conflicts with gz's. I do like the idea of letting the
> rest of bzrlib's guts tell me whether it's okay to declare a method, though,
> rather than handle an AttributeError myself. But you guys are more familiar
> with the gestalt of Bzr than I am, so perhaps I'm missing something?
>
> I think gz and I agree that there's no point in having redundant
> checks. As he says, we have to handle the case that it turns out not
> to be possible at runtime, and I guess it just seems a bit cleaner to
> me to avoid conditionally declaring functions. Either is ok though,
> so let me know when you're ready for this to be rereviewed/merged.
To be clear, I was trying to say the AttributeError handling is better written outside the method, but the functions still may throw EnvironmentError when called so that part had to be retained. It's a minor style point however.