> 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.
--
ht
Klaus Neuner a écrit :
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 perhap
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
Klaus Neuner a é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:
"""
eval() is potentially dangerous and can make code harder to debug. 99%
of the proposed use case for eval() are covered by si
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 e
On 9 fév, 11:01, Stefan Behnel wrote:
> Klaus Neuner, 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
I knew it.
Olivier
--
htt
Klaus Neuner, 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
--
http://mail.python.org/mailman/listinfo/python-list
> 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
p
Am 09.02.10 07:00, schrieb OdarR:
On 9 fév, 02:50, Jean-Michel Pichavant wrote:
Aahz wrote:
In article<0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
OdarR wrote:
and with eval(), did you try ?
WARNING: eval() is almost always the wrong answer to any question
Some
On Tue, 09 Feb 2010 07:29:33 +, Paul Rudin wrote:
>> It is surprisingly difficult to sanitize strings in Python to make them
>> safe to pass to eval. Unless you are prepared to trust the input data
>> explicitly, it's best to just avoid eval.
>
> Despite the fact that it's used in the standar
Steven D'Aprano writes:
> On Mon, 08 Feb 2010 14:43:46 -0800, Aahz wrote:
>
WARNING: eval() is almost always the wrong answer to any question
>>>
>>>warning : it works !
>>
>> Works for what?
>
> Code injection security bugs, of course.
>
> http://en.wikipedia.org/wiki/Code_injection
>
> It
On Mon, Feb 8, 2010 at 10:00 PM, OdarR wrote:
> On 9 fév, 02:50, Jean-Michel Pichavant wrote:
> > Aahz wrote:
> > > In article <
> 0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
> > > OdarR wrote:
> >
> > >> and with eval(), did you try ?
> >
> > > WARNING: eval() is almos
On 9 fév, 02:50, Jean-Michel Pichavant wrote:
> Aahz wrote:
> > In article
> > <0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
> > OdarR wrote:
>
> >> and with eval(), did you try ?
>
> > WARNING: eval() is almost always the wrong answer to any question
>
> Some say that ev
On Mon, Feb 8, 2010 at 5:51 PM, Steven D'Aprano <
ste...@remove.this.cybersource.com.au> wrote:
> On Mon, 08 Feb 2010 14:43:46 -0800, Aahz wrote:
>
> >>> WARNING: eval() is almost always the wrong answer to any question
> >>
> >>warning : it works !
> >
> > Works for what?
>
> Code injection secur
On Mon, 08 Feb 2010 14:43:46 -0800, Aahz wrote:
>>> WARNING: eval() is almost always the wrong answer to any question
>>
>>warning : it works !
>
> Works for what?
Code injection security bugs, of course.
http://en.wikipedia.org/wiki/Code_injection
It is surprisingly difficult to sanitize stri
Aahz wrote:
In article <0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
OdarR wrote:
and with eval(), did you try ?
WARNING: eval() is almost always the wrong answer to any question
Some say that eval is evil !
JM
--
http://mail.python.org/mailman/listinfo/py
In article <5790c33c-13d0-4596-91b0-b3c9aeebf...@f8g2000yqn.googlegroups.com>,
OdarR wrote:
>On 8 f=E9v, 22:28, a...@pythoncraft.com (Aahz) wrote:
>> In article <0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups=
>.com>,
>> OdarR =A0 wrote:
>>>
>>>and with eval(), did you try ?
>>
>>
On 8 fév, 22:28, a...@pythoncraft.com (Aahz) wrote:
> In article
> <0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
>
> OdarR wrote:
>
> >and with eval(), did you try ?
>
> WARNING: eval() is almost always the wrong answer to any question
warning : it works !
another questio
In article <0efe23a6-b16d-4f92-8bc0-12d056bf5...@z26g2000yqm.googlegroups.com>,
OdarR wrote:
>
>and with eval(), did you try ?
WARNING: eval() is almost always the wrong answer to any question
--
Aahz (a...@pythoncraft.com) <*> http://www.pythoncraft.com/
import antigravity
-
OdarR wrote:
On 8 fév, 11:57, Klaus Neuner wrote:
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.end
On 8 fév, 11:57, Klaus Neuner wrote:
> 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.endswi
Klaus Neuner wrote:
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)
...
Y
Klaus Neuner wrote:
>> 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
Klaus Neuner, 08.02.2010 11:57:
> 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'):
>
Klaus Neuner wrote:
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)
...
Y
On 08/02/2010 11:26, Klaus Neuner wrote:
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,
Klaus Neuner wrote:
> > 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
Klaus Neuner wrote:
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)
...
Y
>
> 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 wha
Klaus Neuner a écrit :
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)
...
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
31 matches
Mail list logo