Python question

Apropos to the question "Python for DSP" in comp.dsp (http://
www.dsprelated.com/showthread/comp.dsp/243722-1.php):

How fully object-oriented is Python?  I'm doing an app that really wants 
to be prototyped in something Scilab-ish (i.e., interpreted so it's easy 
to do graphs or computation on bits of it), but which is seriously 
challenging Scilab's sorta-object oriented-ness.  I'm running (again) into 
Scilab's inability to really overload functions, or to provide handles to 
data, etc.

So -- does Python let you grab a handle to a data object, or do function 
overloading?  Does it slow down much if you use those features?

Thanks...

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
> Apropos to the question "Python for DSP" in comp.dsp (http://
> www.dsprelated.com/showthread/comp.dsp/243722-1.php):
>
> How fully object-oriented is Python?

42

> I'm doing an app that really wants to be prototyped in something
> Scilab-ish (i.e., interpreted so it's easy to do graphs or
> computation on bits of it), but which is seriously challenging
> Scilab's sorta-object oriented-ness.  I'm running (again) into 
> Scilab's inability to really overload functions, or to provide
> handles to data, etc.
>
> So -- does Python let you grab a handle to a data object,

Sorry, I've no clue what "grab a handle" means.

> or do function overloading?

No.  

But you can write a function that will accept varying numbers and
types of arguments.

You might want to ask Python questions on comp.lang.python.

-- 
Grant Edwards               grant.b.edwards        Yow! Someone in DAYTON,
                                  at               Ohio is selling USED
                              gmail.com            CARPETS to a SERBO-CROATIAN

On Tue, 31 Mar 2015 17:55:34 +0000, Grant Edwards wrote:

> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>> Apropos to the question "Python for DSP" in comp.dsp (http://
>> www.dsprelated.com/showthread/comp.dsp/243722-1.php):
>>
>> How fully object-oriented is Python?
> 
> 42
> 
>> I'm doing an app that really wants to be prototyped in something
>> Scilab-ish (i.e., interpreted so it's easy to do graphs or computation
>> on bits of it), but which is seriously challenging Scilab's
>> sorta-object oriented-ness.  I'm running (again) into Scilab's
>> inability to really overload functions, or to provide handles to data,
>> etc.
>>
>> So -- does Python let you grab a handle to a data object,
> 
> Sorry, I've no clue what "grab a handle" means.

In C/C++ it's taking an address.

>> or do function overloading?
> 
> No.
> 
> But you can write a function that will accept varying numbers and types
> of arguments.
> 
> You might want to ask Python questions on comp.lang.python.

If they're as self-entranced a bunch of pissy navel-gazers as the folks on 
comp.lang.c -- no, I will ask the question of people who are interested in 
giving practical answers to practical questions.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On 31/03/2015 22:20, Tim Wescott wrote:

>
> If they're as self-entranced a bunch of pissy navel-gazers as the folks on
> comp.lang.c -- no, I will ask the question of people who are interested in
> giving practical answers to practical questions.
>

They're not. It's one of the few groups with a consistently high signal 
to noise ratio and has many genuinely helpful inmates.

As a seasoned newsgroup warrior, you will know how to sort the wheat 
from the chaff in answers you get should you decide to post.

On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Tue, 31 Mar 2015 17:55:34 +0000, Grant Edwards wrote:
>> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>> Apropos to the question "Python for DSP" in comp.dsp (http://www.dsprelated.com/showthread/comp.dsp/243722-1.php):
>>>
>>> How fully object-oriented is Python?
>> 
>> 42
>> 
>>> I'm doing an app that really wants to be prototyped in something
>>> Scilab-ish (i.e., interpreted so it's easy to do graphs or computation
>>> on bits of it), but which is seriously challenging Scilab's
>>> sorta-object oriented-ness.  I'm running (again) into Scilab's
>>> inability to really overload functions, or to provide handles to data,
>>> etc.
>>>
>>> So -- does Python let you grab a handle to a data object,
>> 
>> Sorry, I've no clue what "grab a handle" means.
>
> In C/C++ it's taking an address.

You can't do that explicity in Python, but it's done implicitly every
time you use an object in an expression or pass it to a function.

In Python everything is an object, and objects are always passed by
reference.

That said, some objects are mutable, and some objects are not.

Strings, tuples, and numbers (floats/integers) are not mutable.

Lists, Dictionaries (non-ordered mappings), and many other types of
objects are mutable.

Python doesn't have "variables" in the way that C does where a
variable is a specific hunk of named memory that has a fixed address.

Python has objects, and any object can have zero or more names bound
to it in zero or more namespaces. It's more like Scheme/Lisp in that
regard.

>>> or do function overloading?
>> 
>> No.
>> 
>> But you can write a function that will accept varying numbers and types
>> of arguments.
>> 
>> You might want to ask Python questions on comp.lang.python.
>
> If they're as self-entranced a bunch of pissy navel-gazers as the
> folks on comp.lang.c -- no, I will ask the question of people who are
> interested in giving practical answers to practical questions.

Comp.lang.python is a very friendly and helpful place.  Not at all
like c.l.c.

-- 
Grant Edwards               grant.b.edwards        Yow! World War III?
                                  at               No thanks!
                              gmail.com            

On Tue, 31 Mar 2015 21:38:56 +0000, Grant Edwards wrote:

> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>> On Tue, 31 Mar 2015 17:55:34 +0000, Grant Edwards wrote:
>>> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>>> Apropos to the question "Python for DSP" in comp.dsp
>>>> (http://www.dsprelated.com/showthread/comp.dsp/243722-1.php):
>>>>
>>>> How fully object-oriented is Python?
>>> 
>>> 42
>>> 
>>>> I'm doing an app that really wants to be prototyped in something
>>>> Scilab-ish (i.e., interpreted so it's easy to do graphs or
>>>> computation on bits of it), but which is seriously challenging
>>>> Scilab's sorta-object oriented-ness.  I'm running (again) into
>>>> Scilab's inability to really overload functions, or to provide
>>>> handles to data,
>>>> etc.
>>>>
>>>> So -- does Python let you grab a handle to a data object,
>>> 
>>> Sorry, I've no clue what "grab a handle" means.
>>
>> In C/C++ it's taking an address.
> 
> You can't do that explicity in Python, but it's done implicitly every
> time you use an object in an expression or pass it to a function.

That's a significant advantage over Scilab, then.  At least, if I can do:

modifySomething(something)

and change the "something" (subject to your restrictions).

In Scilab, you can say:

something = modifySomething(something);

but if "something" is big then it gets copied into temporary memory (under 
the hood, of course), then copied back.  And that's a huge speed hit.

> In Python everything is an object, and objects are always passed by
> reference.
> 
> That said, some objects are mutable, and some objects are not.
> 
> Strings, tuples, and numbers (floats/integers) are not mutable.
> 
> Lists, Dictionaries (non-ordered mappings), and many other types of
> objects are mutable.
> 
> Python doesn't have "variables" in the way that C does where a variable
> is a specific hunk of named memory that has a fixed address.
> 
> Python has objects, and any object can have zero or more names bound to
> it in zero or more namespaces. It's more like Scheme/Lisp in that
> regard.
> 
>>>> or do function overloading?
>>> 
>>> No.
>>> 
>>> But you can write a function that will accept varying numbers and
>>> types of arguments.

I'll need to think about whether that's enough.  It does sorta-kinda allow 
for function overloading, but I like the C++ syntax of

object.memberFunction()

for keeping things straight.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

On Tue, 31 Mar 2015 18:09:53 -0500, Tim Wescott wrote:

> On Tue, 31 Mar 2015 21:38:56 +0000, Grant Edwards wrote:
> 
>> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>> On Tue, 31 Mar 2015 17:55:34 +0000, Grant Edwards wrote:
>>>> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:
>>>>> or do function overloading?
>>>> 
>>>> No.
>>>> 
>>>> But you can write a function that will accept varying numbers and
>>>> types of arguments.
> 
> I'll need to think about whether that's enough.  It does sorta-kinda
> allow for function overloading, but I like the C++ syntax of
> 
> object.memberFunction()
> 
> for keeping things straight.

One other thing about overloading is that, as far as overloading for 
different types, the question is meaningless in Python.  C++ has typed 
variables.  Python variables are typeless handles to typed data; the 
nearest C++ equivalent being templates.  So if I wrote:

def trisum(x, y, z):
    return x + y + z

Then as long as x, y, and z are all of types that have a '+' operator 
defined relative to one another, trisum will just work.

>>> trimsum(1, 2, 3)
6
>>> trimsum('a', 'b', 'c')
'abc'

The other thing that saves me from missing true overloading is default 
arguments.

def printlist(lst, sep='\n'):
    for L in lst:
        print(L, sep)

-- 
Rob Gaddi, Highland Technology -- www.highlandtechnology.com
Email address domain is currently out of order.  See above to fix.

> I'll need to think about whether that's enough.  It does sorta-kinda allow
> for function overloading, but I like the C++ syntax of
>
> object.memberFunction()
>
> for keeping things straight.

Python has object methods, the syntax you show is valid Python.

Wouter

On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:

>>>> Sorry, I've no clue what "grab a handle" means.
>>>
>>> In C/C++ it's taking an address.
>> 
>> You can't do that explicity in Python, but it's done implicitly every
>> time you use an object in an expression or pass it to a function.
>
> That's a significant advantage over Scilab, then.  At least, if I can do:
>
> modifySomething(something)
>
> and change the "something" (subject to your restrictions).

Yes, you can.  You may also do someting.modify()

> In Scilab, you can say:
>
> something = modifySomething(something);
>
> but if "something" is big then it gets copied into temporary memory (under 
> the hood, of course), then copied back.  And that's a huge speed hit.

Python is very popular for scientific computing, data analysis, and
numerical stuff.  You may want to check out numpy and scientific python

http://www.numpy.org/
http://www.scipy.org/

In numpy, all the array operations are written in C.  A lot of the
heavy lifting when doing number crunching in Python is actually done
under the cover by FORTRAN libraries like BLAS and ATLAS. That means
that Python can be suprisingly fast.

>>>>> or do function overloading?
>>>> 
>>>> No.
>>>> 
>>>> But you can write a function that will accept varying numbers and
>>>> types of arguments.
>
> I'll need to think about whether that's enough.  It does sorta-kinda allow 
> for function overloading, but I like the C++ syntax of
>
> object.memberFunction() for keeping things straight.

That's not function overloading.  At least that's not how I was
taught.  Function overloading is being able to write a set of
functions/methods with the same name and differing signatures:

float max(float *a, int count)
{
  float m;
  ...
  return m;
}

int   max(int *a, int count)
{
  int m;
  ...
  return m;
}

long max(long *a, long count)
{
  long m;
  ...
  return m;
}

Then the compiler generates calls to the appropriate "version" of
max() depending on the parameter types.

In python you don't usually _need_ to jump through hoops like that
because arrays don't care what's in them, comparison operators don't
care what types you give them, and "return" can return anything you
want:

def max(a):
    m = v[0]
    for v in a[1:]:
       if v > m:
           m = v
    return m

That max() function will work on any collection of objects that can be
indexed and whose contents support the '>' operator.

Python also has full support for classes, objects, and methods.

You can write as many different classes as you want that implement a
method named foo(), and then pass any instance of any of those classes
to this function and it's happy:

def bar(o):
    o.foo();

In Python, you can even replace at run-time method 'foo' of
_a_single_object_ without affecting other instances.  [But, if you
find that you think you need to do that, you're doing something
wrong.]

----------------------------------------------------------------------
class MyClass(object):
    def foo(self):
       print "hello!"

a = MyClass()
b = MyClass()

a.foo()
b.foo()

def monkeyPatchFunction():
   print "hi!"

print "monkey-patching object a"
a.foo = monkeyPatchFunction;

a.foo()
b.foo()
----------------------------------------------------------------------

That outputs:

hello!
hello!
monkey-patching object a
hi!
hello!

-- 
Grant Edwards               grant.b.edwards        Yow! I once decorated my
                                  at               apartment entirely in ten
                              gmail.com            foot salad forks!!

On Tue, 31 Mar 2015 18:09:53 -0500, Tim Wescott wrote:

[snip]

>>>> But you can write a function that will accept varying numbers and
>>>> types of arguments.
> 
> I'll need to think about whether that's enough.  It does sorta-kinda allow 
> for function overloading, but I like the C++ syntax of
> 
> object.memberFunction()
> 
> for keeping things straight.

Python has a nice coherent namespace and object inheritance rules.  See,
for example:

https://docs.python.org/2/tutorial/classes.html#python-scopes-and-namespaces