Re: use strings to call functions
> Or perhaps is it me that failed to re-read a bit more of the thread > before answering - I obviously missed the irony (and made an a... of > myself), sorry :-/ There is nothing to be sorry about. I am grateful to all participants of this thread. I know a lot more about Python than before. -- http://mail.python.org/mailman/listinfo/python-list
Re: use strings to call functions
On Feb 10, 12:55 pm, Bruno Desthuilliers wrote: > KlausNeunera écrit : > > > > > All right, I admit that eval() is evil and should never be used. > > Can you tell the difference between your above statement and the following: As already pointed out in my second post (though perhaps not explicitly enough), I like the getattr-stuff better than eval(). That is why I will not use eval(). I don't have a reason to use eval(). All I wanted to say is this: If there are no circumstances at all under which eval() can reasonably be used, then it should not be part of Python. As it is part of Python (and as Python is a carefully designed language), there will most probably some situations in which one might want to use it. -- http://mail.python.org/mailman/listinfo/python-list
Re: use strings to call functions
On Feb 9, 11:01 am, Stefan Behnel wrote: > KlausNeuner, 09.02.2010 10:04: > > > my program is supposed to parse files that I have created myself and that > > are on my laptop. It is not supposed to interact with anybody else > > than me. > > Famous last words. > > Stefan All right, I admit that eval() is evil and should never be used. Under no circumstances. (Which is, of course, the reason, why Python has eval().) The same applies to knives. You shouldn't use them. You shouldn't even use them in your own kitchen. A man might enter your kitchen, take your knife away and use it against you. -- http://mail.python.org/mailman/listinfo/python-list
Re: use strings to call functions
> go to hell ;-), it is part of the language, it seems to match the > aforementioned question. Thats right. In fact, your code is the precise analogy of my Prolog example in Python. Obviously, eval() and call() are both inherently dangerous. They should never be used in programs that are used in programs that get input from people other than the author. Yet, my program is supposed to parse files that I have created myself and that are on my laptop. It is not supposed to interact with anybody else than me. On the other hand, I think, it is worthwhile getting acquainted with the getattr-stuff, because this method can be useful in many contexts. Anyway, thanks to all who participated in this thread. It taught me a lot. -- http://mail.python.org/mailman/listinfo/python-list
Re: use strings to call functions
>
> A file extension is not necessarily 3 chars long.
No, of course not. But it is, if I choose to use only (self-made) file
endings that are 3 chars long. Anyway, it was just an example.
> handlers = {
> ".txt" : handle_txt,
> ".py" : handle_py,
> # etc
> }
>
That is exactly what I would like to avoid: Having to map the function
'handle_txt' to '.txt'. Firstly, because I don't want to repeat
anything and secondly, because I will one day add a new function and
forget to add its name to the dictionary. (This is not severe if there
is only one dictionary for mapping functions, but it will make life a
lot harder, if a lot of mappings of this kind are used.)
What I want is calling the string directly. In Prolog, I would use
something like:
get_file_ending(File, Ending),
Predicate =.. [Ending, File],
call(Predicate).
--
http://mail.python.org/mailman/listinfo/python-list
use strings to call functions
Hello,
I am writing a program that analyzes files of different formats. I
would like to use a function for each format. Obviously, functions can
be mapped to file formats. E.g. like this:
if file.endswith('xyz'):
xyz(file)
elif file.endswith('abc'):
abc(file)
...
Yet, I would prefer to do something of the following kind:
func = file[-3:]
apply_func(func, file)
Can something of this kind be done in Python?
Klaus
--
http://mail.python.org/mailman/listinfo/python-list
list of all type names
Hello, Python has one feature that I really hate: There are certain special names like 'file' and 'dict' with a predefined meaning. Yet, it is allowed to redefine these special names as in dict = [1:'bla'] In order to avoid problems in the future, I tried to get the list of all those names, but I could not find it. (The Python Reference Manual only says that there is the type "Dictionary" in Python, but not that 'dict' is a semi-reserved word.) Can you point me to such a list? Klaus -- http://mail.python.org/mailman/listinfo/python-list
fast list lookup
Hello, what is the fastest way to determine whether list l (with len(l)>3) contains a certain element? Klaus -- http://mail.python.org/mailman/listinfo/python-list
Thanks (Re: gather information from various files efficiently)
Hello, (Sorry for beginning a new thread. Google does not allow me to reply to my own posting. And I cannot use a newsreader at the moment.) Thanks to all who participated in the thread. I tried the try- and the if-solution. The setdefault-solution didn't work in my program. With the try-solution the process took 37 seconds. With the if-solution the process took so much time that I didn't bother to wait. Klaus -- http://mail.python.org/mailman/listinfo/python-list
gather information from various files efficiently
Hello, I need to gather information that is contained in various files. Like so: file1: = foo : 1 2 bar : 2 4 baz : 3 = file2: = foo : 5 bar : 6 baz : 7 = file3: = foo : 4 18 bar : 8 = The straightforward way to solve this problem is to create a dictionary. Like so: [...] a, b = get_information(line) if a in dict.keys(): dict[a].append(b) else: dict[a] = [b] Yet, I have got 43 such files. Together they are 4,1M large. In the future, they will probably become much larger. At the moment, the process takes several hours. As it is a process that I have to run very often, I would like it to be faster. How could the problem be solved more efficiently? Klaus -- http://mail.python.org/mailman/listinfo/python-list
