Hi Damian,<div><br></div><div>After looking at possible use cases, wouldn't it make sense to allow the caller to specify a file to be written to?  Regardless, we were thinking of creating two methods, one that takes a list of descriptors, and one that takes a single descriptor. This would remove the need to check for a list versus an object, allowing more consistent typing.</div>

<div><br></div><div>Just to clarify, the include_fields and exclude_fields parameters would have default values of none and since we are taking in descriptors are a list rather than a *arg, we don't need to worry about specifying the keyword parameters. That said, if a caller doesn't specify either, all parameters would be returned. Otherwise, it is expected that only one of these parameters would be specified by the caller.</div>

<div><br></div><div>Also, going back to features expected by the community, would users want a csv header to be written? Or simply a csv file?</div><div><br></div><div>- Erik & Megan<br><br><div class="gmail_quote">On Mon, Jul 9, 2012 at 1:22 PM, Damian Johnson <span dir="ltr"><<a href="mailto:atagar@torproject.org" target="_blank">atagar@torproject.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Mon, Jul 9, 2012 at 8:40 AM, Erik I Islo <<a href="mailto:eislo@wesleyan.edu">eislo@wesleyan.edu</a>> wrote:<br>


> Hello,<br>
><br>
> Megan and I have been working on the CSV export functionality that was being<br>
> discussed a little over a week ago, and given the recent discussion, we<br>
> would like to clarify the expected/desired implementation of this feature.<br>
><br>
> We have created an export.py module within /stem/descriptor, which contains<br>
> a single method as of now that takes a descriptor object and two possible<br>
> lists of fields.  These lists are to be specified as either the explicitly<br>
> included attributes of the descriptor or the attributes to be excluded.  As<br>
> we continue to work on this code, Megan and I were wondering if it wouldn't<br>
> be better to accept a file object as well, in addition to accepting any<br>
> number of descriptor objects (i.e. def csv_exp(..., *descriptors)).  Or are<br>
> there other suggestions request concerning what sort of input such a method<br>
> should take?<br>
><br>
> -Erik & Megan<br>
><br>
> On Fri, Jul 6, 2012 at 1:49 PM, Damian Johnson <<a href="mailto:atagar@torproject.org">atagar@torproject.org</a>><br>
> wrote:<br>
>><br>
>> > So is export intended to be an instance method of descriptor, one that<br>
>> > just dumps a single csv line of the instance attributes (maybe subject to<br>
>> > some selection of those attributes)?  Or a static method that takes a<br>
>> > collection?<br>
>><br>
>> Either would work fine. I was envisioning the former, though on<br>
>> reflection stem/descriptor/export.py module would probably be better<br>
>> since that localizes this functionality and allows for better<br>
>> expansion in the future (other formats such as json, or the inclusion<br>
>> of import functionality).<br>
>><br>
>> > It seems like it might be awkward to have to hack stem itself to add a<br>
>> > new export format (for example).  Is this a concern?<br>
>><br>
>> That depends on how useful users would find it to be. If researchers<br>
>> commonly want csv export functionality then we might as well support<br>
>> it. However, if it's a rarely desired feature then there's little<br>
>> reason to clutter our API. My understanding is that this feature is<br>
>> mostly for researchers and sysadmins, so as part of the target<br>
>> audience I'm happy to defer to you on how we handle this.<br>
>><br>
>> > Do all the known use-cases make need both an interface to Tor Control<br>
>> > and a descriptor utility library?<br>
>><br>
>> No, you're completely right. Stem's controller functionality utilizes<br>
>> its descriptor functionality but not vice versa. Another design that<br>
>> we could go with is to make several smaller libraries (descriptors,<br>
>> controller, response parsing, shared utilities, etc) if stem grows<br>
>> unwieldy. However, we're nowhere near that yet and keeping stem as a<br>
>> single library makes development, testing, installation and usage far<br>
>> easier.<br>
>><br>
>> Stem is a library to make working with Tor easier for developers and<br>
>> researchers, with the current scope of the Tor control and dir specs.<br>
>> My plan is to complete that, release it to the community, then see<br>
>> based on feedback where we should go from there.<br>
><br>
><br>
<br>
</div></div>Naif: This was your feature request. Thoughts?<br>
<div class="im"><br>
> Megan and I were wondering if it wouldn't<br>
> be better to accept a file object as well, in addition to accepting any<br>
> number of descriptor objects (i.e. def csv_exp(..., *descriptors)).<br>
<br>
</div>If we can make it work then that would be nice, though having a *list<br>
entry generally doesn't work well for optional keyword fields. Ie, if<br>
you had the signature...<br>
<br>
def csv_exp(include_fields = None, exclude_fields = None, destination<br>
= None, *descriptors)<br>
<br>
Then the caller needs to provide all of those keyword fields which<br>
kinda defeats the purpose of them being optional. For instance, to<br>
call it with the defaults and a single descriptor it would be...<br>
<br>
csv_exp(None, None, None, my_descriptor)<br>
<br>
My suggestion is to just accept a single argument that can either be a<br>
single descriptor or a list of descriptors.<br>
<br>
Cheers! -Damian<br>
</blockquote></div><br></div>