Python question

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

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.

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

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.

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.

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

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.

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.

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.

'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)

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

Wouter

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

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

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.

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!

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

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.

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

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

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

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

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

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.

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.

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.

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

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.

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

------------------------------------------------------

Hear, hear, Dimiter. I feel the same way and I'm only 57... :)