Personally, I would almost always pay the x2 efficiency price in order
to use a class. But then I don't know what you're writing.
Of course, if you really need it to be efficient, you can write it as a
C extension, or use Pyrex, etc. and get -much- better results.
--
http://mail.python.org/mailm
[EMAIL PROTECTED] wrote:
> Yes, my implementation was less efficient because of the extra function
> call.
>
>> class Weird(object):
>> @staticmethod
>> def __call__(arg):
>> data = 42
>> def func(arg):
>> return arg+data
>>
Yes, my implementation was less efficient because of the extra function
call.
> class Weird(object):
> @staticmethod
> def __call__(arg):
> data = 42
> def func(arg):
> return arg+data
> Weird.__call__ = static
[EMAIL PROTECTED] wrote:
>
> What have we gained from this? Two major advantages:
> * no ugly 'global' statement
> * no reliance on the function's name
I don't dispute either of the above, however, the actual overhead of
your approach appears to be much higher (see below) probably becau
First of all, the test can be optimized by adding a boolean flag which
indicates if the data has been initialized or not, and then just
testing a boolean value instead of doing an "is" comparison, at the
cost of an extra global variable. But this is still ugly (actually
uglier IMO).
I think this
Ben C wrote:
...
>
> Why not just:
>
> data = None
> def func(a):
> global data
>
> if not data:
> data = somethingcomplexandcostly()
>
> return simple(data, a)
>
well in the original instance the above reduced to something like
data=None
def func(arg):
global da
John J. Lee wrote:
> Robin Becker <[EMAIL PROTECTED]> writes:
>
>> When young I was warned repeatedly by more knowledgeable folk that self
>> modifying code was dangerous.
>>
>> Is the following idiom dangerous or unpythonic?
>>
>> def
On 2006-04-29, Robin Becker <[EMAIL PROTECTED]> wrote:
> When young I was warned repeatedly by more knowledgeable folk that self
> modifying code was dangerous.
>
> Is the following idiom dangerous or unpythonic?
>
> def func(a):
> global func, data
> da
John J. Lee wrote:
> 1. I don't think most people would call that "self-modifying code". I
>won't try defining that term precisely because I know you'll just
>pick holes in my definition ;-)
Don't really disagree about the rewriting code, but the
Robin Becker <[EMAIL PROTECTED]> writes:
> When young I was warned repeatedly by more knowledgeable folk that self
> modifying code was dangerous.
>
> Is the following idiom dangerous or unpythonic?
>
> def func(a):
> global func, data
> data = somethin
Peter Otten wrote:
>>
>> def func(a):
>> global func, data
>> data = somethingcomplexandcostly()
>> def func(a):
>> return simple(data,a)
>> return func(a)
>>
>
> at the cost of just one object identity test whereas your func()
> implementation will do th
Robin Becker wrote:
> When young I was warned repeatedly by more knowledgeable folk that self
> modifying code was dangerous.
>
> Is the following idiom dangerous or unpythonic?
>
> def func(a):
> global func, data
> data = somethingcomplexandco
Robin Becker schrieb:
> When young I was warned repeatedly by more knowledgeable folk that self
> modifying code was dangerous.
>
> Is the following idiom dangerous or unpythonic?
>
> def func(a):
> global func, data
> data = somethingcomplexandco
When young I was warned repeatedly by more knowledgeable folk that self
modifying code was dangerous.
Is the following idiom dangerous or unpythonic?
def func(a):
global func, data
data = somethingcomplexandcostly()
def func(a):
return simple(data,a)
return func(a
Steven D'Aprano a écrit :
(snip)
> Having said that, here is a good example of self-modifying code:
>
> http://aspn.activestate.com/ASPN/Cookbook/Python/Recipe/68429
>
> The RingBuffer class dynamically modifies itself once it is full so that
> its behaviour changes.
&
Hi !
I often use the auto-modification of code, to allow the users to adapt
software to the evolution of their needs.
When this technique is controlled, and framed well, it presents only few
problems.
AMHA, to speak about danger, it is the result of a lack of practice and
tests. It is a litt
titi(1234)
>
> #now, change the function, "on instant"
> txt="""def titi(par):
> if par>222:
> return str(par)*2
> else:
> return str(par)*5
> """
> exec(txt,globals(),globals())
>
> print titi(
Hi, you, also !
A view, with a little difference :
def titi(par):
if par>222:
return par*2
else:
return par*10
print titi(123)
print titi(1234)
#now, change the function, "on instant"
txt="""def titi(par):
if par>222:
return str(par)*2
else:
retu
[EMAIL PROTECTED] wrote:
[regarding "self-modifying code"]
> fNew =open("newModule.py",'w')
> lNew=['print 123\n','print 454\n','print 789\n']
> fNew.writelines(lNew)
> fNew.close()
> from newModule import *
This isn
[EMAIL PROTECTED] schrieb:
> [...]
> Also Python can (writing and running a module, in-line):
>
> fNew =open("newModule.py",'w')
> lNew=['print 123\n','print 454\n','print 789\n']
> fNew.writelines(lNew)
> fNew.close()
> from newModule import *
> [...]
You don't even need a file for this.
Try: e
Hi all,
when I was young I programmed in an interpreted language that allowed
to modify itself.
Also Python can (writing and running a module, in-line):
fNew =open("newModule.py",'w')
lNew=['print 123\n','print 454\n','print 789\n']
fNew.writelines(lNew)
fNew.close()
from newModule import *
Runn
21 matches
Mail list logo
