How to solve name mangling ?
hello, the beauty of Python is that you can "rename" everything . In the languages I've been using up to now, an integer is an integer and stays an integer forever (has it's beauty too). The modules I write for myself, I always start with the "dangerous": form scipy import * Now if I take modules form others, or take code snippets (with forgetting to use the scipy import), I get different type of arrays, with all kind of weird behavior. The module at it's own works perfect, but if I call the module from another program, it doesn't work (as expected) anymore. Any clever solution to solve this without thinking about those tiny details ? Is using form scipy import * as the last global import in each module, a solution ? thanks, Stef Mientki
Hi Stef On Thu, Jun 07, 2007 at 11:19:57PM +0200, Stef Mientki wrote:
the beauty of Python is that you can "rename" everything . In the languages I've been using up to now, an integer is an integer and stays an integer forever (has it's beauty too).
The modules I write for myself, I always start with the "dangerous": form scipy import *
"Namespaces are one honking great idea -- let's do more of those!" As you found out the hard way, not using namespaces effectively leads to problems. The "dangerous" shouldn't be in quotation marks! Why not use import scipy as S Thereby you protect yourself from other modules overwriting your method and variables, without having to do much extra typing. Cheers Stéfan
Stefan van der Walt wrote:
Hi Stef
On Thu, Jun 07, 2007 at 11:19:57PM +0200, Stef Mientki wrote:
the beauty of Python is that you can "rename" everything . In the languages I've been using up to now, an integer is an integer and stays an integer forever (has it's beauty too).
Agreed. Sometimes this can be useful (read: makes things more explict, but also more static). You have to pay attention to stuff like that, but with a #comment here and there, it's all OK. The power and flexibilty of Python/numpy/scipy weighs much more than this.
The modules I write for myself, I always start with the "dangerous": form scipy import *
"Namespaces are one honking great idea -- let's do more of those!" As you found out the hard way, not using namespaces effectively leads to problems. The "dangerous" shouldn't be in quotation marks!
Why not use
import scipy as S
Thereby you protect yourself from other modules overwriting your method and variables, without having to do much extra typing.
Beeing as explict as possible (e.g. scipy.integrate.odeint(...)) is a good thing. If you can be explicit, be it :) -- cheers, steve I love deadlines. I like the whooshing sound they make as they fly by. -- Douglas Adams
Steve Schmerler wrote:
Stefan van der Walt wrote:
Hi Stef
On Thu, Jun 07, 2007 at 11:19:57PM +0200, Stef Mientki wrote:
the beauty of Python is that you can "rename" everything . In the languages I've been using up to now, an integer is an integer and stays an integer forever (has it's beauty too).
Agreed. Sometimes this can be useful (read: makes things more explict, but also more static). You have to pay attention to stuff like that, but with a #comment here and there, it's all OK. The power and flexibilty of Python/numpy/scipy weighs much more than this.
The modules I write for myself, I always start with the "dangerous": form scipy import *
"Namespaces are one honking great idea -- let's do more of those!" As you found out the hard way, not using namespaces effectively leads to problems. The "dangerous" shouldn't be in quotation marks!
Why not use
import scipy as S
Thereby you protect yourself from other modules overwriting your method and variables, without having to do much extra typing.
Beeing as explict as possible (e.g. scipy.integrate.odeint(...)) is a good thing. If you can be explicit, be it :)
Steve and Stefan (and my name is Stef and was Stephan ;-), From a pure programmers point of view you might be fully right. btw I don't want to start a flame war, but from a non-programmers point of view (which is a growing group, me falling somewhere in between), reading the philosophy behind Python, I come to a totally different conclusion From what I remember some philosophical highlights are: Python should be intuitively, simple, universal and allow many solutions for the same problem. To drive my car, - I don't need to know the type of the spark-plug - I don't need to know how many spark-plugs my car has - I don't need to know if my car has any spark-plugs - I might even have never heard of a spark-plug To use Python, - I need to know what an numpy array is - I need to know what a numeric array is - I need to know what an array array is - I need to know what a scipy array is - and maybe a few others ... But I just want to use an array, and I just want that the array always to behave the same, even if I give the array to someone else. Ok, a car has a much longer history than programming languages. And "batteries included" is both the strong point and the weak point of a language like Python. From the viewpoint of the non-programmer, who just wants to drive their car (without wanting to have a look inside the car), there is still no good answer :-( cheers, Stef Mientki Kamer van Koophandel - handelsregister 41055629 / Netherlands Chamber of Commerce - trade register 41055629
Stef Mientki wrote:
Steve and Stefan (and my name is Stef and was Stephan ;-),
From a pure programmers point of view you might be fully right. btw I don't want to start a flame war, but from a non-programmers point of view (which is a growing group, me falling somewhere in between), reading the philosophy behind Python, I come to a totally different conclusion
From what I remember some philosophical highlights are: Python should be intuitively, simple, universal and allow many solutions for the same problem.
Python philosophy generally highlights one good solution for a given problem...
To drive my car, - I don't need to know the type of the spark-plug - I don't need to know how many spark-plugs my car has - I don't need to know if my car has any spark-plugs - I might even have never heard of a spark-plug
To use Python, - I need to know what an numpy array is - I need to know what a numeric array is - I need to know what an array array is - I need to know what a scipy array is - and maybe a few others ...
I've never used numeric or "array array", and there is no such a thing as scipy array... I find the analogy with a car totally bogus because in most countries anyway, you need to get a permit to drive, and this takes more time than typing many times N.foo instead of foo (at least it did for me). And anyway, driving a car without paying attention to what you are doing is the cause of many deaths every year :) Namespaces is one of the top reason why I started using python instead of matlab (a bit behind the not broken C api reason). There are so many weird things happening in matlab because of the lack of namespace (which only becomes worse because foo(1) can be the first element of foo or the function foo called with 1, and the fact that there is the stupid limit one public function / one m file). This may sound minor to you, N.sum vs sum, but this has *major* consequences for the whole codebase. Also, being explicit is easier than being implicit, not the contrary. For example, what do you thing is the easiest ? Typing numpy.sum(a, 1) or tracking down a bug because sum(a, 1) gives you a totally bogus result (python sum and numpy sum are different) ? And it happens (one recent bug in scipy was exactly caused by that).
But I just want to use an array, and I just want that the array always to behave the same, even if I give the array to someone else.
Ok, a car has a much longer history than programming languages. And "batteries included" is both the strong point and the weak point of a language like Python.
From the viewpoint of the non-programmer, who just wants to drive their car (without wanting to have a look inside the car), there is still no good answer :-( yes there is: call N.sum instead of sum in your module. Look at it that way: how many N. do you need to write, and how many character have you written instead in this email ?
David
yes there is: call N.sum instead of sum in your module. Look at it that way: how many N. do you need to write, and how many character have you written instead in this email ?
and now I forget just 1 N, and the program seems to work correctly ... cheers, Stef Kamer van Koophandel - handelsregister 41055629 / Netherlands Chamber of Commerce - trade register 41055629
Stef Mientki wrote:
yes there is: call N.sum instead of sum in your module. Look at it that way: how many N. do you need to write, and how many character have you written instead in this email ?
and now I forget just 1 N, and the program seems to work correctly ... Well, you have not given any code example yet, so it is kind of difficult to help you... Following you car analogy, saying that is seems to work is like saying driving without looking at the road works because you did it once in your backyard. It is easier, it may work sometimes; still, would you do it ?
cheers, David
Hi,
and now I forget just 1 N, and the program seems to work correctly ...
I think what we're all saying is: If you start in matlab - for example - it seems like a good idea to do: from numpy import * That's how I started. Gradually, writing code, you begin to realize that it is just much, much better - for clarity, and for namespace safety, to do import numpy as N Of course, if you do that, if you forget an N., you get a syntax error. And that is the right way to solve your 'what is an array' problem. It's an N.array Best, Matthew
Matthew Brett wrote:
Hi,
and now I forget just 1 N, and the program seems to work correctly ...
I think what we're all saying is:
If you start in matlab - for example - it seems like a good idea to do:
from numpy import *
That's how I started.
Gradually, writing code, you begin to realize that it is just much, much better - for clarity, and for namespace safety, to do
import numpy as N
Of course, if you do that, if you forget an N., you get a syntax error.
well I don't ;-) But that might have to do with my lousy organization. Here's what I have right now, from a friend I got a library, with the message, add this line at the top of your code, and you can use everthing in the library: from my_friends_module import * In my friends module there is the following code from array import array Now I get my N-less "array". So I probably shouldn't have followed my friends advice, and I should just have written import my_friends_module Another solution could be, but don't know if it's safe enough from my_friends_module import * # and always as the last import do my own from scipy import array Is this a good solution ? thanks, Stef Mientki Kamer van Koophandel - handelsregister 41055629 / Netherlands Chamber of Commerce - trade register 41055629
Now I get my N-less "array". So I probably shouldn't have followed my friends advice, and I should just have written
import my_friends_module
This is the correct way of doing things Another solution could be, but don't know if it's safe enough
from my_friends_module import * # and always as the last import do my own from scipy import array
Is this a good solution ?
No because when you'll want to use array, which array is it really ? What is more, there can be border effects in your friend's module, there shouldn't be, but how to be sure ? Matthieu
Another solution could be, but don't know if it's safe enough
from my_friends_module import * # and always as the last import do my own from scipy import array
Is this a good solution ?
No because when you'll want to use array, which array is it really ?
Sorry, I must be missing something here, doesn't "from scipy import array" (as the LAST line) override any previous definition of "array" ?? thanks, Stef Kamer van Koophandel - handelsregister 41055629 / Netherlands Chamber of Commerce - trade register 41055629
Another solution could be, but don't know if it's safe enough
from my_friends_module import * # and always as the last import do my own from scipy import array
Is this a good solution ?
No because when you'll want to use array, which array is it really ?
Sorry, I must be missing something here, doesn't "from scipy import array" (as the LAST line) override any previous definition of "array" ?? Yes it does, after from scipy import array, but you only solved the
Stef Mientki wrote: problem of array, that is what if other names arouse ? I still don't understand what the problem is with doing import my_friends_module as MF, and use the functions as MF.foo. Using from module import *, that is importing everything from a module totally defeats the purpose of namespace (and is not specific to python; C++ namespace are exactly the same: doing from module import * everywhere is exactly the same than doing using namespace std, etc... everywhere in your header files, which is an horrible thing to do). David
Stef Mientki wrote:
well I don't ;-) But that might have to do with my lousy organization.
Here's what I have right now, from a friend I got a library, with the message, add this line at the top of your code, and you can use everthing in the library:
from my_friends_module import *
In my friends module there is the following code
from array import array
Now I get my N-less "array". So I probably shouldn't have followed my friends advice, and I should just have written
import my_friends_module
Another solution could be, but don't know if it's safe enough
from my_friends_module import * # and always as the last import do my own from scipy import array
Why not this: from my_friends_module import foo,bar from scipy import array Which (if the apis) are compatible would allow a drop in replacement latter of: from my_friends_module2 import foo,bar from numpy import array with no other code changes. I'm assuming we're talking about long term maintained code, and not just a quick script. For that case I do the: import numpy as N import pylab as P Ryan -- Ryan May Graduate Research Assistant School of Meteorology University of Oklahoma
On 08/06/07, Ryan May <rmay@ou.edu> wrote:
with no other code changes. I'm assuming we're talking about long term maintained code, and not just a quick script. For that case I do the:
import numpy as N import pylab as P
I would take this a step further, and point out that for *interactive* code - i.e. typed at the ipython prompt - it's probably easier to do "from numpy import *". I'd also like to reiterate that scipy does not provide a function "array". If you import scipy, for some strange reason, it sets scipy.array to numpy.array - that is, for some reason scipy provides copies of a large number of numpy functions. Not reimplementations, not accelerated versions, just exactly the same functions under different names. Why is this? Anne M. Archibald
Hi,
Of course, if you do that, if you forget an N., you get a syntax error.
well I don't ;-) But that might have to do with my lousy organization.
No, it's not lousy organization, honestly. As you can see, your friend, and you, and me when I started, all did this - because it's less typing, and because it is what we are used to. Learning not to do this is something, like many good coding practices, that is not atall obvious at first, and seems inconvenient, but as you get used to doing it, you realize that it's The Right Way To Do It (TM). Explaining why is hard - it's really something you've got to learn for yourself - as a result of the kind of problems you've had here, and just by trying to do it that way, and finding that is works well.
from my_friends_module import * from array import array
If you use a lot of classes and so on from this module, you might do: import numpy as N import my_friends_module as MF from my_friends_module import array as MFA Then you'd be doing: a = N.array([1,2]) b = MFA.array([1,2]) and it will probably be more obvious what's going on, and therefore less error prone... Best, Matthew
Stef Mientki wrote:
From the viewpoint of the non-programmer, who just wants to drive their car (without wanting to have a look inside the car), there is still no good answer :-(
If you use a programming language to solve problems, you are programming -- so you are a programmer in my view. If you don't want to do that (consider yourself a non-programmer), you have to use "tools" like LabView. I agree that there is a whole lot of documentation out there for scipy&friends which can be somewhat overwhelming at the begining. That's why there are lists like this one where you can get the right directions. If you want to drive the car, you have to learn driving first. If you want to be a good driver, you have to practise a bit more and also know the internals of you car in some detail. If you are "just a driver", you will never have the driving skills to acomplish something outstanding (like winning a race). If you use a language (Python, C, whatever) and libraries for that language to acomplish something more complex (e.g. a project with more than one source file), you have to read documentation, experiment, get used, make mistakes, ask poeple for help. That's how things work. Unfortunately, there is no such thing as a solve-my-problem-button :) OK enough with that. Just start using the namespace thing properly and you'll see that will pay off for you in long run. Happy coding :) -- cheers, steve Random number generation is the art of producing pure gibberish as quickly as possible.
I'm enjoying reading all those comments also because sometime metaphors a re risky to use ;) (it seems like in a episode of House M.D.) because I can reply.. if you want to drive a car you need to have a license... ok but if you want to drive a car you dont' need to be a mechanich or a mechanic engineer and know how the engine works... otherwise i guess there will be really less car drivers .. ;) Giorgio
Giorgio Luciano ha scritto:
I'm enjoying reading all those comments also because sometime metaphors a re risky to use ;) (it seems like in a episode of House M.D.) because I can reply.. if you want to drive a car you need to have a license... ok but if you want to drive a car you dont' need to be a mechanich or a mechanic engineer and know how the engine works... otherwise i guess there will be really less car drivers .. ;)
Problem is, programming is a science in itself. I do not work in informatics, nor I have ever studied the theory of programming, and the only programming language I have a firm grasp of is Python. Still, I don't feel that "programming should be easy for everyone". Or better, it should be as easy as possible (I'm currenty trying to self-learn C++, and it's quite hellish...) but not easier. Otherwise we would all being coding with Logo. So, programming may be hard, but we can't expect it must be easy for everyone. It must be just as hard as it should be. (By the way, this is the same mentality of "computers should be easy for everyone". Computers are meta-tools, they are extremly complex objects. Using them is correspondingly complex. The fact that every layman can stay in front of a computer and write an email is a miracle of current technology, not something ordinary. We can't expect for computers to become much easier than they are today without being dumbed down: we must instead expect people to be educated about them.) IMHO, Python is just that: it is a really easy, ready-to-go language, but with all the guts to do everything. In this context, namespaces are a damn great Python feature, and using them correctly makes code: - more readable (because you now that module.function() belongs to module, whereas, by importing *, function() , you lose that information) - more robust (because there is no clash of different modules) - actually easier (because I do not have to worry that the function() I write myself will clash with some other function() I have imported - I had extremly quirky bugs due to that) And it is an extremly simple concept to grasp, IMHO. I also come from the early days of "from foo import *", and somewhere in my apps there are remains of that bad habit. But everytime I can I rewrite them correctly, because I quickly learned that importing * is the wrong way. m. -- Massimo Sandal University of Bologna Department of Biochemistry "G.Moruzzi" snail mail: Via Irnerio 48, 40126 Bologna, Italy email: massimo.sandal@unibo.it tel: +39-051-2094388 fax: +39-051-2094387
participants (11)
-
Anne Archibald -
David Cournapeau -
Giorgio Luciano -
massimo sandal -
Matthew Brett -
Matthieu Brucher -
Ryan May -
Stef Mientki -
Stef Mientki
-
Stefan van der Walt -
Steve Schmerler