Python question

On Wed, 01 Apr 2015 14:52:30 +0000, Grant Edwards wrote:

> 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:

Now see, this is why I asked here instead of comp.lang.something -- if I'd 
made a similar mistake an comp.lang.c or comp.lang.c++, the resulting sub-
thread would still be discussing my evolutionary distance from the amoeba 
in 2017.

You, instead, just correct my absent-mindedness and move on with something 
useful.

I will have to try comp.lang.python at some point, if I start using python.

-- 

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

On 2015-04-01, Tim Wescott <seemywebsite@myfooter.really> wrote:
> On Wed, 01 Apr 2015 14:52:30 +0000, Grant Edwards wrote:
>>
>>> 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:
>
> Now see, this is why I asked here instead of comp.lang.something -- if I'd 
> made a similar mistake an comp.lang.c or comp.lang.c++, the resulting sub-
> thread would still be discussing my evolutionary distance from the amoeba 
> in 2017.
>
> You, instead, just correct my absent-mindedness and move on with
> something useful.

I (or somebody else) would have done the same thing on c.l.p.

> I will have to try comp.lang.python at some point, if I start using
> python.

I never read c.l.c++, but I do remember how difficult c.l.c was...

-- 
Grant Edwards               grant.b.edwards        Yow! I'm ZIPPY the PINHEAD
                                  at               and I'm totally committed
                              gmail.com            to the festive mode.

On 31/03/15 23:20, Tim Wescott 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.
>

In C or C++, you have "variables" that are named areas of memory - when 
you write "int x = 1", x is the variable and currently holds the value "1".

In Python, you don't have variables like that.  When you write "x = 1", 
an integer object with value 1 is created, with a reference count of 1, 
and "x" is a name for it.

If you are familiar with C++11 share_ptr<T> and make_shared, you can 
imagine assignment in Python to be more akin to share_ptr references. 
Objects are created and attached to names - so in that sense, you are 
always "grabbing a handle".  For some things (usually small and 
immutable objects - I can't remember the exact rules, but it is mostly 
obvious at the time), assignments will make copies.  For other things 
(such as objects, lists, etc.), assignment is normally a new reference 
to the same object.

>>> or do function overloading?
>>
>> No.

In Python, you don't declare types of arguments - so the there is no way 
to distinguish between "foo(int x)" and "foo(float x)".  But you can use 
introspection if needed:

def foo(x) :
	if isinstance(x, int) :
		foo_int(x)
	elif isinstance(x, float) :
		foo_float(X)

However, this sort of thing is rare - you typically either use classes 
and methods (the method is attached to the type or the object), or take 
advantage of duck-typing (just use the operations you want, regardless 
of the type).

>>
>> 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.
>

We are not /all/ bad in comp.lang.c - or at least, not all of the time! 
  But threads do sometimes descend into a discussions of the details of 
the standards documents, which can get tedious to many people.

But comp.lang.python is a friendly place (or at least it was - I haven't 
visited it for a few years).

On 01/04/15 22:45, Grant Edwards wrote:
> On 2015-04-01, Tim Wescott <seemywebsite@myfooter.really> wrote:
>> On Wed, 01 Apr 2015 14:52:30 +0000, Grant Edwards wrote:
>>>
>>>> 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:
>>
>> Now see, this is why I asked here instead of comp.lang.something -- if I'd
>> made a similar mistake an comp.lang.c or comp.lang.c++, the resulting sub-
>> thread would still be discussing my evolutionary distance from the amoeba
>> in 2017.
>>
>> You, instead, just correct my absent-mindedness and move on with
>> something useful.
>
> I (or somebody else) would have done the same thing on c.l.p.
>
>> I will have to try comp.lang.python at some point, if I start using
>> python.
>
> I never read c.l.c++, but I do remember how difficult c.l.c was...
>

c.l.c++ is similar in style to c.l.c - except that mentions of C are 
allowed in a limited fashion in c.l.c++, while mentioning C++ in c.l.c. 
is considered heresy.  The groups can be entertaining, and sometimes 
enlightening, but they are not much use for beginners or programmers (no 
matter how experienced) simply interested in practical use of the languages.

On Mon, 06 Apr 2015 22:42:25 +0200, David Brown wrote:

> On 31/03/15 23:20, Tim Wescott 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.
>>
>>
> In C or C++, you have "variables" that are named areas of memory - when
> you write "int x = 1", x is the variable and currently holds the value
> "1".
> 
> In Python, you don't have variables like that.  When you write "x = 1",
> an integer object with value 1 is created, with a reference count of 1,
> and "x" is a name for it.
> 
> If you are familiar with C++11 share_ptr<T> and make_shared, you can
> imagine assignment in Python to be more akin to share_ptr references.
> Objects are created and attached to names - so in that sense, you are
> always "grabbing a handle".  For some things (usually small and
> immutable objects - I can't remember the exact rules, but it is mostly
> obvious at the time), assignments will make copies.  For other things
> (such as objects, lists, etc.), assignment is normally a new reference
> to the same object.
> 
>>>> or do function overloading?
>>>
>>> No.
> 
> In Python, you don't declare types of arguments - so the there is no way
> to distinguish between "foo(int x)" and "foo(float x)".  But you can use
> introspection if needed:
> 
> def foo(x) :
> 	if isinstance(x, int) :
> 		foo_int(x)
> 	elif isinstance(x, float) :
> 		foo_float(X)
> 
> However, this sort of thing is rare - you typically either use classes
> and methods (the method is attached to the type or the object), or take
> advantage of duck-typing (just use the operations you want, regardless
> of the type).
> 
> 
>>> 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.
>>
>>
> We are not /all/ bad in comp.lang.c - or at least, not all of the time!
>   But threads do sometimes descend into a discussions of the details of
> the standards documents, which can get tedious to many people.

I was tarring all of the group with one brush, when I shouldn't have.  
There are people there (you among them) who will give straight answers to 
straightforward questions of the "how do I do this" sort.  It's just that 
there's so many others who don't -- and who nit-pick any such attempt -- 
that I don't find the groups useful.

There needs to be a comp.language.c.users forum, ditto for C++ -- but I'm 
not sure either one would gain traction in today's USENET environment.

-- 

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

On Mon, 06 Apr 2015 22:42:25 +0200, David Brown wrote:

> If you are familiar with C++11 share_ptr<T> and make_shared, you can
> imagine assignment in Python to be more akin to share_ptr references.
> Objects are created and attached to names - so in that sense, you are
> always "grabbing a handle".  For some things (usually small and immutable
> objects - I can't remember the exact rules, but it is mostly obvious at
> the time), assignments will make copies.  For other things (such as
> objects, lists, etc.), assignment is normally a new reference to the same
> object.

Assignment is always a new reference to the same object. But for small,
immutable values, even creating a "new" value may return a reference to an
existing value.

For example, you'd expect this:

    x = 10
    y = x

to result in x and y referring to the same object. But this:

    x = 5 + 5
    y = 3 + 7

will (typically) also result in x and y referring to the same object, as
Python has a pool of small integers, and "creating" a small integer
returns (a reference to) one of the objects in that pool rather than
creating a new one.

Similarly, strings which conform to the syntax of Python identifiers
(consist only of alphanumerics and underscore) are "interned" in a shared
pool. This saves a lot of memory, as Python objects are basically hash
tables whose keys are strings.

On 07/04/15 00:21, Tim Wescott wrote:
> On Mon, 06 Apr 2015 22:42:25 +0200, David Brown wrote:
> 
>> On 31/03/15 23:20, Tim Wescott wrote:
>>> On Tue, 31 Mar 2015 17:55:34 +0000, Grant Edwards wrote:
>>>
>>>> On 2015-03-31, Tim Wescott <seemywebsite@myfooter.really> wrote:

>>>> 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.
>>>
>>>
>> We are not /all/ bad in comp.lang.c - or at least, not all of the time!
>>   But threads do sometimes descend into a discussions of the details of
>> the standards documents, which can get tedious to many people.
> 
> I was tarring all of the group with one brush, when I shouldn't have.  
> There are people there (you among them) who will give straight answers to 
> straightforward questions of the "how do I do this" sort.  It's just that 
> there's so many others who don't -- and who nit-pick any such attempt -- 
> that I don't find the groups useful.
> 

I've been known to make a few little nit-picking and navel-gazing posts
in c.l.c too - the type of post I make varies between groups.  The type
of posts people typically make in comp.arch.embedded and
sci.electronics.design are very different (which is why I hate it when
someone cross-posts to such disparate groups - comp.disp has a similar
"atmosphere" to comp.arch.embedded, and so cross-posting here is fine).

With good, well-written questions, I try to give good, helpful answers
(assuming I know an answer).  But with some of the other types of
threads in c.l.c., giving straight answers is not really polite
behaviour :-)

> There needs to be a comp.language.c.users forum, ditto for C++ -- but I'm 
> not sure either one would gain traction in today's USENET environment.
> 

The younger generation seems to prefer web forums, stack overflow,
facebook, etc.  It's incomprehensible to me - web-based communication is
so incredibly inefficient compared to Usenet (or mailing lists).  But it
means there are relatively few people who genuinely want answers,
discussions and advice about straightforward practical C programming,
and who want to do it using Usenet.

On 07/04/15 08:56, David Brown wrote:
> The younger generation seems to prefer web forums, stack overflow,
> facebook, etc.  It's incomprehensible to me - web-based communication is
> so incredibly inefficient compared to Usenet (or mailing lists).  But it
> means there are relatively few people who genuinely want answers,
> discussions and advice about straightforward practical C programming,
> and who want to do it using Usenet.

In general I don't have any real problem with the web having
overtaken usenet. But there /are/ some niggles...

Stackexchange seems to cater for people that want to be spoonfed
about which button to press. They seem to actively discourage
questions that don't have a one-paragraph answer. I'm more interested
in learning the general basics that can be applied anywhere;
generally I can figure out which button to press

There are some forums that /accidentally/ (but deliberately) go out
of their way to discourage conversations by only allowing one level
of quoting. Discarding context leads to shallow discussions
and misapprehensions.

Web content that isn't searchable is simply non-existent; anything
written that can't be found should be considered transient and
then lost.

On 07.4.2015 г. 16:16, Randy Yates wrote:
> Dimiter_Popoff <dp@tgi-sci.com> writes:
>
>> On 07.4.2015 &#1075;. 10:56, David Brown wrote:
>>> .....
>>>
>>> The younger generation seems to prefer web forums, stack overflow,
>>> facebook, etc.  It's incomprehensible to me - web-based communication is
>>> so incredibly inefficient compared to Usenet (or mailing lists).  But it
>>> means there are relatively few people who genuinely want answers,
>>> discussions and advice about straightforward practical C programming,
>>> and who want to do it using Usenet.
>>>
>>
>> I think it is indicative of the overall development, amazing how
>> H.G Wells has anticipated that in the 19-th century. Humans become
>> more and more useless, this is at the root of it all. Just because there
>> is no necessity for them to _do_ anything, they want just to click
>> and consume. We all want that, our curiousity is supposed to wrestle
>> this inclination but given enough temptation it just hopelessly loses
>> the battle. Only real need can win - and it is fading because we
>> have done our best to eliminate it, that's what we do by design
>> I guess.
>> I suppose I begin to sound like an old person, I am about to get 60
>> this year, may be my perception is just down to that, I don't know.
>
> Hear, hear, Dimiter. I feel the same way and I'm only 57... :)
>

Come to think of it, I have been feeling like this for 20+ years... :D.

I must have been aging prematurely I guess :-).

Dimiter

On 4/7/15 8:21 AM, Dimiter_Popoff wrote:
> On 07.4.2015 г. 10:56, David Brown wrote:
>> .....
>>
>> The younger generation seems to prefer web forums, stack overflow,
>> facebook, etc.

FB is a time suck (but, i guess we can say the same about USENET).

>> It's incomprehensible to me - web-based communication is
>> so incredibly inefficient compared to Usenet (or mailing lists).

dsp.stackexchange has eclipsed comp.dsp a little, for me because i can 
do legit math expression on it.

>> But it
>> means there are relatively few people who genuinely want answers,
>> discussions and advice about straightforward practical C programming,
>> and who want to do it using Usenet.
>>
>
> I think it is indicative of the overall development, amazing how
> H.G Wells has anticipated that in the 19-th century. Humans become
> more and more useless, this is at the root of it all. Just because there
> is no necessity for them to _do_ anything, they want just to click
> and consume. We all want that, our curiosity is supposed to wrestle
> this inclination but given enough temptation it just hopelessly loses
> the battle. Only real need can win - and it is fading because we
> have done our best to eliminate it, that's what we do by design
> I guess.
> I suppose I begin to sound like an old person, I am about to get 60
> this year, may be my perception is just down to that, I don't know.

same here.  i'm chomping at the bit to get to some of my IRA to use to 
retire some debt and i have to wait until July 1, when i am 59.5 y.o. 
otherwise there's a 10% early withdrawal penalty.


-- 

r b-j                  rbj@audioimagination.com

"Imagination is more important than knowledge."