Are the appropriate parameter types for the docstrings, listed
somewhere? In particular, in reviewing some docs I see both 'str' and
'string' used. Which one is correct?
Chris
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.sci
On Sun, Oct 25, 2009 at 12:14 AM, Christopher Burns wrote:
> Are the appropriate parameter types for the docstrings, listed
> somewhere? In particular, in reviewing some docs I see both 'str' and
> 'string' used. Which one is correct?
>
> Not all of them are listed in one place. For general advi
Cool, thanks. Mind if I update the HOWTO_DOCUMENT adding in the
partial list below?
Chris
On Sat, Oct 24, 2009 at 3:19 PM, Ralf Gommers
wrote:
> Not all of them are listed in one place. For general advice, see the
> Parameters section of
> http://projects.scipy.org/numpy/wiki/CodingStyleGuideli
On Sun, Oct 25, 2009 at 12:42 AM, Christopher Burns wrote:
> Cool, thanks. Mind if I update the HOWTO_DOCUMENT adding in the
> partial list below?
>
> Sure, that would be useful. While you're at it, could you get rid of the
{True, False}?
Cheers,
Ralf
> Chris
>
> On Sat, Oct 24, 2009 at 3:19
Done.
On Sat, Oct 24, 2009 at 3:52 PM, Ralf Gommers
wrote:
> Sure, that would be useful. While you're at it, could you get rid of the
> {True, False}?
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/nu
On Sun, Oct 25, 2009 at 1:11 AM, Christopher Burns wrote:
> Done.
>
> That section looks much better now. Except for the word "back-tics" :)
Thanks,
Ralf
> On Sat, Oct 24, 2009 at 3:52 PM, Ralf Gommers
> wrote:
> > Sure, that would be useful. While you're at it, could you get rid of the
> > {
Just committed a change to 'backticks'.
;)
On Sat, Oct 24, 2009 at 4:17 PM, Ralf Gommers
wrote:
> That section looks much better now. Except for the word "back-tics" :)
>
> Thanks,
> Ralf
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
htt
One other comment (sorry I'm late chiming in): in general, for something
like "sequence of ints," usually what is really intended as viable input is
"array-like of int-likes," and indeed, in the process of confirming this for
various functions, I have found bugs where what was intended was in fact
