Forums

Python question

Started by Tim Wescott March 31, 2015
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 Thursday, April 2, 2015 at 9:45:24 AM UTC+13, 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... > > -- > Grant Edwards grant.b.edwards Yow! I'm ZIPPY the PINHEAD > at and I'm totally committed > gmail.com to the festive mode.
Yeh, the whole computing world went to shit after Fortran fell out of favour by the new generation of programmers who got upset at a GOTO statement. Although C was made in 1968 or thereabouts they gave the impression that it was like they had re-invented the wheel. Now for the new methods of micro programming I am sure it was and still is fantastic, but for Scientific programming everything had to be re-written and it din't even have a type complex! You had to write your own complex routines in the early days and even now you can't do x=a*b*c where they are all type complex without using functions. C++ then came along and we were told that we were all bad programmers and needed to program in Classes instead. Thank God for MATRIXx and then MATLAB. Some of us don't want to write professional software for distribution, we only want to do research - one offs and testing.
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 &#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. Dimiter ------------------------------------------------------ Dimiter Popoff, TGI http://www.tgi-sci.com ------------------------------------------------------ http://www.flickr.com/photos/didi_tgi/