Re: [Matplotlib-users] Re: matplotlib.mlab.find() not quite like Matlab"s

[John H. <jdh...@ac...>]

>>>>> "Chris" == Chris Barker <Chr...@no...> writes:

    Chris> Darren Dale wrote:
    >> >I guess there is no way in Python of emulating >Matlab"s
    >> detection of the number of output arguments.  I just got a
    >> response from c.l.p. Somebody remembered seeing this at ASPN:
    >> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/284742
    >> expecting() is the workhorse, equivalent to Matlab's nargout:

    Chris> Very cool. but I'd caution against using it. I'd much
    Chris> rather see matplotlib be pythonesque than an exact
    Chris> duplicate of MATLAB. This is NOT pythonesque!

I tend to agree with the caution against using it.  But it would be
useful in some contexts, like converting existing matlab m-files to
python/numeric/numarray, the desire for which has occurred in some
contexts.  Last time the discussion came up, the lack of nargout was
raised as a problem for any converter code.


    Chris> Precisely speaking, python functions ALWAYS return just one
    Chris> object: A tuple. That tuple can contain any number of other
    Chris> objects, and sequence unpacking means it can look like
    Chris> you're returning multiple values, but you're not
    Chris> really. i.e.

What do you mean that python functions always return a tuple?  How
about functions that return an int, or a string, or whatever?  

>>> def func(): return 1
>>> type(func())
<type 'int'>

Do you mean that python functions that return tuples always return
tuples <wink> ?

JDH