On Mon, Apr 6, 2020 at 6:36 PM ast wrote:
>
> Hello
>
> I wrote a decorator to add a cache to functions.
> I realized that cache dictionnary could be defined
> as an object attribute or as a local variable in
> method __call__.
> Both seems to work properly.
> Can you see any differences between t
09.10.19 14:02, Chris Angelico пише:
The decorator has full access to the function object, including a
reference to that function's module globals.
def trace(func):
log = func.__globals__["log"]
... proceed as before
As long as you can depend on "log" always being a module-level
(glob
On 9/10/19 13:02, Chris Angelico wrote:
> On Wed, Oct 9, 2019 at 9:53 PM Antoon Pardon wrote:
>> I have some logging utilities so that when I write library code, I just use
>> the following.
>>
>> from logutil import Logger
>>
>> log = Logger(__name__)
> Are you always absolutely consistent with
Antoon Pardon wrote:
> I have some logging utilities so that when I write library code, I just
> use the following.
>
> from logutil import Logger
>
> log = Logger(__name__)
If logutil is under your control you can make log a callable object with a
tracing method:
[logutil.py]
class Logger:
On Wed, Oct 9, 2019 at 9:53 PM Antoon Pardon wrote:
>
> I have some logging utilities so that when I write library code, I just use
> the following.
>
> from logutil import Logger
>
> log = Logger(__name__)
Are you always absolutely consistent with this? Do you always have it
as a module-level v
On Fri, Feb 10, 2017 at 10:18 AM, Terry Reedy wrote:
> Perhaps "There are also cases in which evaluating 'fi(arg)' before rather
> than after the def statement makes a difference." should be added.
Perhaps not. The word "roughly" covers the odd edge cases, and Python
has a general principle of ev
On 2/9/2017 2:03 AM, ast wrote:
Hi
In python courses I read, it is explained that
@decor
def f():
pass
is equivalent to:
def f():
pass
f = decor(f)
But that's not always true. See this code
Which is why the official docs now say 'roughly equivalent'
'''
For example, the following co
"Steven D'Aprano" a écrit dans le message de
news:589c2cdc$0$1584$c3e8da3$54964...@news.astraweb.com...
On Thu, 09 Feb 2017 08:03:32 +0100, ast wrote:
Congratulations, you've found a microscopic corner of the language where
the two different ways of applying decorators are different.
Are y
On Thu, 09 Feb 2017 08:03:32 +0100, ast wrote:
> Hi
>
> In python courses I read, it is explained that
>
> @decor
> def f():
> pass
>
> is equivalent to:
>
> def f():
> pass
>
> f = decor(f)
>
> But that's not always true. See this code
[...]
> any comment ?
Congratulations, you've
On Thu, Feb 9, 2017 at 6:03 PM, ast wrote:
> class Temperature:
> def __init__(self):
>self.value = 0
>
> # @property
>def celsius(self):return self.value
> celsius = property(celsius)
> # @celsius.setter def celsius(self, value):<--
> overwri
Dave Angel wrote:
> Peter Otten <__pete...@web.de> Wrote in message:
>
>>
>> In your code change
>>
>> fib1 = isOddMy(fib)
>>
>> to
>>
>> fib = isOddMy(fib)
>>
>> and the without@ version will produce the same output as the with@
>> version.
>>
>>
>
> I expect that one more thing is need
Peter Otten <__pete...@web.de> Wrote in message:
>
> In your code change
>
> fib1 = isOddMy(fib)
>
> to
>
> fib = isOddMy(fib)
>
> and the without@ version will produce the same output as the with@ version.
>
>
I expect that one more thing is needed, since the above is inside
a functio
muru kessan wrote:
> Is there a difference between accessing decorators via '@' symbol and
> hard coding that ? esp when the function passed to the decorator is a
> recursive one?
The difference is not the decorator but the recursive function call.
Consider
Case 1:
@deco
def f():
...
On 4 July 2013 06:39, Peter Otten <__pete...@web.de> wrote:
> Joshua Landau wrote:
>
>> On 3 July 2013 23:19, Joshua Landau wrote:
>>> If you don't want to do that, you'd need to use introspection of a
>>> remarkably hacky sort. If you want that, well, it'll take a mo.
>>
>> After some effort I'm
>Well, technically it's
>
>func.func_closure[0].cell_contents.__name__
>
>but of course you cannot know that for the general case.
Hah, I admit I lacked perseverance in looking at this in PyCharms debugger as I
missed
that.
Much appreciated!
jlc
--
http://mail.python.org/mailman/listinfo/python
Joshua Landau wrote:
> On 3 July 2013 23:19, Joshua Landau wrote:
>> If you don't want to do that, you'd need to use introspection of a
>> remarkably hacky sort. If you want that, well, it'll take a mo.
>
> After some effort I'm pretty confident that the hacky way is impossible.
Well, technical
>> If you don't want to do that, you'd need to use introspection of a
>> remarkably hacky sort. If you want that, well, it'll take a mo.
>
> After some effort I'm pretty confident that the hacky way is impossible.
Hah, I fired it in PyCharm's debugger and spent a wack time myself, thanks
for the c
On 3 July 2013 23:19, Joshua Landau wrote:
> If you don't want to do that, you'd need to use introspection of a
> remarkably hacky sort. If you want that, well, it'll take a mo.
After some effort I'm pretty confident that the hacky way is impossible.
--
http://mail.python.org/mailman/listinfo/py
On 3 July 2013 23:09, Joseph L. Casale wrote:
> I have a set of methods which take args that I decorate twice,
>
> def wrapped(func):
> def wrap(*args, **kwargs):
> try:
> val = func(*args, **kwargs)
> # some work
> except BaseException as error:
>
On 6/19/2013 4:03 AM, Wolfgang Maier wrote:
Wolfgang Maier biologie.uni-freiburg.de> writes:
andrea crotti gmail.com> writes:
2013/6/18 Terry Reedy udel.edu>
Decorators are only worthwhile if used repeatedly. What you specified can
easily be written, for instance, as
def save_doc(db=No
Wolfgang Maier biologie.uni-freiburg.de> writes:
>
> andrea crotti gmail.com> writes:
>
> > 2013/6/18 Terry Reedy udel.edu>
> >
> > Decorators are only worthwhile if used repeatedly. What you specified can
> easily be written, for instance, as
> > def save_doc(db=None):
> > if db is None:
andrea crotti gmail.com> writes:
>
> 2013/6/18 Terry Reedy udel.edu>
> On 6/18/2013 5:47 AM, andrea crotti wrote:
> Using a CouchDB server we have a different database object potentially
> for every request.
> We already set that db in the request object to make it easy to pass it
> around for
On Tue, 18 Jun 2013 10:47:57 +0100, andrea crotti wrote:
> Using a CouchDB server we have a different database object potentially
> for every request.
>
> We already set that db in the request object to make it easy to pass it
> around form our django app, however it would be nice if I could set
2013/6/18 Terry Reedy
> On 6/18/2013 5:47 AM, andrea crotti wrote:
>
>> Using a CouchDB server we have a different database object potentially
>> for every request.
>>
>> We already set that db in the request object to make it easy to pass it
>> around form our django app, however it would be nic
On 6/18/2013 5:47 AM, andrea crotti wrote:
Using a CouchDB server we have a different database object potentially
for every request.
We already set that db in the request object to make it easy to pass it
around form our django app, however it would be nice if I could set it
once in the API and
andrea crotti gmail.com> writes:
>
> 2013/6/18 Wolfgang Maier biologie.uni-freiburg.de>
>
>
> andrea crotti gmail.com> writes:
> >
> >
> > Using a CouchDB server we have a different database object potentially for
> every request.
> >
> > We already set that db in the request object to make
2013/6/18 Wolfgang Maier
> andrea crotti gmail.com> writes:
>
> >
> >
> > Using a CouchDB server we have a different database object potentially
> for
> every request.
> >
> > We already set that db in the request object to make it easy to pass it
> around form our django app, however it would b
andrea crotti gmail.com> writes:
>
>
> Using a CouchDB server we have a different database object potentially for
every request.
>
> We already set that db in the request object to make it easy to pass it
around form our django app, however it would be nice if I could set it once
in the API an
On Tue, Jun 18, 2013 at 10:47 AM, andrea crotti
wrote:
> def with_optional_db(func):
> """Decorator that sets the database to the global current one if
> not passed in or if passed in and None
> """
> @wraps(func)
> def _with_optional_db(*args, **kwargs):
> func_args = func.func_code.co_varnames
>
Jason Swails於 2013年3月28日星期四UTC+8上午4時33分08秒寫道：
> On Wed, Mar 27, 2013 at 3:49 PM, Joseph L. Casale
> wrote:
>
> I have a class which sets up some class vars, then several methods that are
> passed in data
>
> and do work referencing the class vars.
>
>
>
>
>
> I want to decorate these meth
> When you say "class vars", do you mean variables which hold classes?
You guessed correctly, and thanks for pointing out the ambiguity in my
references.
> The one doesn't follow from the other. Writing decorators as classes is
> fairly unusual. Normally, they will be regular functions.
I
On Wed, 27 Mar 2013 22:38:11 -0400, Jason Swails wrote:
>> The second case is the easiest. Suppose you have a class like this,
>> with many methods which have code in common. Here's a toy example:
>>
>>
>> def MyClass(object):
>> x = "class attribute"
>>
>> def __init__(self, y):
>>
On Wed, Mar 27, 2013 at 7:29 PM, Steven D'Aprano <
steve+comp.lang.pyt...@pearwood.info> wrote:
>
> The one doesn't follow from the other. Writing decorators as classes is
> fairly unusual. Normally, they will be regular functions. If your
> decorator needs to store so much state that it needs to
On Wed, 27 Mar 2013 19:49:54 +, Joseph L. Casale wrote:
> I have a class which sets up some class vars, then several methods that
> are passed in data and do work referencing the class vars.
When you say "class vars", do you mean variables which hold classes? Like
"string vars" are variable
> So decorators will never take instance variables as arguments (nor should
>they, since no instance
> can possibly exist when they execute).
Right, I never thought of it that way, my only use of them has been trivial, in
non class scenarios so far.
> Bear in mind, a decorator should take a
On Wed, Mar 27, 2013 at 3:49 PM, Joseph L. Casale wrote:
> I have a class which sets up some class vars, then several methods that
> are passed in data
> and do work referencing the class vars.
>
>
> I want to decorate these methods, the decorator needs access to the class
> vars, so I thought
>
On 27 March 2013 19:49, Joseph L. Casale wrote:
> I have a class which sets up some class vars, then several methods that are
> passed in data
> and do work referencing the class vars.
>
>
> I want to decorate these methods, the decorator needs access to the class
> vars, so I thought
> about ma
On Mon, Jun 11, 2012 at 1:51 AM, Tom Harris wrote:
> Greetings,
>
> I have a class that implements the iterator protocol, and tokenises a string
> into a series of tokens. As well as the token, it keeps track of some
> information such as line number, source file, etc.
So each processor needs to
Chris Rebert於 2012年1月10日星期二UTC+8下午1時15分53秒寫道：
> On Mon, Jan 9, 2012 at 8:14 PM, contro opinion wrote:
> > test1.py
> >
> > def deco(func):
> > print 'i am in deco'
> >
> > @deco
> > def test():
> > print 'i am in test'
> >
> >
> > when you run it ,you get :
> > i am in deco
> >
> >
> >
>
Cheers,
Chris
--
http://rebertia.com
On Mon, Jan 9, 2012 at 8:34 PM, contro opinion wrote:
>
> def deco(func):
> def wrap():
> print 'i am in deco'
> return func()
> return wrap
>
> @deco
> def test():
> print "i am in test"
> when you run it ,there is no result ,
>
On Mon, Jan 9, 2012 at 7:59 PM, contro opinion wrote:
> test1.py
>
> def deco(func):
> print 'i am in deco'
> return func
>
> @deco
>
> def test():
> print 'i am in test'
>
> when you run it ,you get :
>
>
>
> test2.py
>
> def tsfunc(func):
> def wrappedFunc():
> print '[%s] %s
On Mon, Jan 9, 2012 at 8:14 PM, contro opinion wrote:
> test1.py
>
> def deco(func):
> print 'i am in deco'
>
> @deco
> def test():
> print 'i am in test'
>
>
> when you run it ,you get :
> i am in deco
>
>
>
> test2.py
>
> def tsfunc(func):
> def wrappedFunc():
> print 'i
On Mon, 14 Nov 2011 17:00:38 -0800, Russell E. Owen wrote:
> Oops, I stripped so much out of my example that I stripped the ugly bit.
> This is closer to the original and demonstrated the issue:
>
> def timeMethod(func):
> name = func.__name__ + "Duration"
> def wrapper(self, *args, **key
In article
,
Ian Kelly wrote:
> On Thu, Nov 10, 2011 at 2:52 PM, Russell E. Owen wrote:
> > I am trying to write a decorator that times an instance method and
> > writes the results to a class member variable. For example:
> >
> > def timeMethod(func):
> > def wrapper(self, *args, **keyArgs
On Thu, Nov 10, 2011 at 2:52 PM, Russell E. Owen wrote:
> I am trying to write a decorator that times an instance method and
> writes the results to a class member variable. For example:
>
> def timeMethod(func):
> def wrapper(self, *args, **keyArgs):
> t1 = time.time()
> res = fu
On 21 août, 18:31, Emile van Sebille wrote:
> On 8/18/2011 5:02 AM Makiavelik said...
>
> > Hi,
> > Here is a sample code that reproduces the issue :
>
> Not really 'sample' enough to allow others to investigate...
>
> ImportError: No module namedgobject
> ImportError: No module nameddbus
> Import
On 8/18/2011 5:02 AM Makiavelik said...
Hi,
Here is a sample code that reproduces the issue :
Not really 'sample' enough to allow others to investigate...
ImportError: No module named gobject
ImportError: No module named dbus
ImportError: No module named dbus.mainloop.glib
Try to eliminate th
On 01/-10/-28163 02:59 PM,
mhearne808[insert-at-sign-here]gmail[insert-dot-here]com wrote:
I am just trying to wrap my head around decorators in Python, and I'm
confused about some behavior I'm seeing. Run the code below (slightly
adapted from a Bruce Eckel article), and I get the following outp
On Fri, Jul 22, 2011 at 2:38 PM,
mhearne808[insert-at-sign-here]gmail[insert-dot-here]com
wrote:
> I am just trying to wrap my head around decorators in Python, and I'm
> confused about some behavior I'm seeing. Run the code below (slightly
> adapted from a Bruce Eckel article), and I get the fol
On Mar 21, 8:59 pm, Mike Patterson wrote:
> In my Python class the other day, the professor was going over
> decorators and he briefly mentioned that there had been this huge
> debate about the syntax and using the @ sign to signify decorators.
>
> I read about the alternative forms proposed here
And I'm willing to bet that there are plenty of
scripts out there that use "dec" as a name for Decimal objects.
You won. I owe you a beer ;)
Laurent
--
http://mail.python.org/mailman/listinfo/python-list
On Mon, Mar 21, 2011 at 7:31 PM, Benjamin Kaplan
wrote:
> On Mon, Mar 21, 2011 at 8:59 PM, Mike Patterson
> wrote:
>> In my Python class the other day, the professor was going over
>> decorators and he briefly mentioned that there had been this huge
>> debate about the syntax and using the @ sign
On Mon, Mar 21, 2011 at 8:59 PM, Mike Patterson
wrote:
> In my Python class the other day, the professor was going over
> decorators and he briefly mentioned that there had been this huge
> debate about the syntax and using the @ sign to signify decorators.
>
> I read about the alternative forms p
On Jan 27, 2:42 am, "Thomas L. Shinnick" wrote:
> At 08:17 PM 1/26/2011, Chris wrote:
>
> >I have a class (A, for instance) that possesses a boolean (A.b, for
> >instance) that is liable to change over an instance's lifetime.
>
> >Many of the methods of this class (A.foo, for instance) should not
At 08:17 PM 1/26/2011, Chris wrote:
I have a class (A, for instance) that possesses a boolean (A.b, for
instance) that is liable to change over an instance's lifetime.
Many of the methods of this class (A.foo, for instance) should not
execute as long as this boolean is false, but should instead
On 27/01/2011 02:17, Chris wrote:
I have a class (A, for instance) that possesses a boolean (A.b, for
instance) that is liable to change over an instance's lifetime.
Many of the methods of this class (A.foo, for instance) should not
execute as long as this boolean is false, but should instead ra
On Jan 26, 6:17 pm, Chris wrote:
> I have a class (A, for instance) that possesses a boolean (A.b, for
> instance) that is liable to change over an instance's lifetime.
>
> Many of the methods of this class (A.foo, for instance) should not
> execute as long as this boolean is false, but should ins
On 16 Okt, 16:49, Peter Otten <__pete...@web.de> wrote:
> Lucasm wrote:
> > I have a decorator problem and hope someone is able to help me out/
> > assist me. Thanks in advance.
>
> > Suppose:
> > ### Begin some_library_module ###
>
> > def some_decorator(some_method):
> > def inner(an_arg, *ar
Lucasm wrote:
> I have a decorator problem and hope someone is able to help me out/
> assist me. Thanks in advance.
>
> Suppose:
> ### Begin some_library_module ###
>
> def some_decorator(some_method):
> def inner(an_arg, *args, **kwargs):
> return some_method(an_arg, *args, **kwargs
On Sat, 13 Mar 2010 11:02:44 -0800, Jon Clements wrote:
> If I can re-explain slightly, say I have a class 'compute':
>
> class Compute(object):
> def __init__(self, something):
> self.something = something
> # misc other methods here.
>
> then...
>
> class ComputeAdd(Comput
On 13 Mar, 17:42, Jack Diederich wrote:
> On Sat, Mar 13, 2010 at 12:10 PM, Jon Clements wrote:
> > On 13 Mar, 16:42, Jack Diederich wrote:
> >> On Sat, Mar 13, 2010 at 11:19 AM, Jon Clements
> >> wrote:
> >> > This is semi-experimental and I'd appreciate opinions of whether it's
> >> > the co
On Sat, Mar 13, 2010 at 8:19 AM, Jon Clements wrote:
> The name 'some_function' is completely redundant -- don't need it,
> don't actually care about the function afterwards, as long as it
> becomes a __call__ of a 'B' *instance*.
>
Special methods are looked up on the class, not the instance, s
On Sat, Mar 13, 2010 at 12:10 PM, Jon Clements wrote:
> On 13 Mar, 16:42, Jack Diederich wrote:
>> On Sat, Mar 13, 2010 at 11:19 AM, Jon Clements wrote:
>> > This is semi-experimental and I'd appreciate opinions of whether it's
>> > the correct design approach or not. It seems like a good idea,
On 13 Mar, 16:42, Jack Diederich wrote:
> On Sat, Mar 13, 2010 at 11:19 AM, Jon Clements wrote:
> > This is semi-experimental and I'd appreciate opinions of whether it's
> > the correct design approach or not. It seems like a good idea, but it
> > doesn't mean it is.
>
> > I have a class 'A', thi
On Mar 13, 10:38 am, Jon Clements wrote:
> On 13 Mar, 16:26, Patrick Maupin wrote:
>
>
>
> > On Mar 13, 10:19 am, Jon Clements wrote:
>
> > > What I'd like to achieve is something similar to:
>
> > > @inject(B):
> > > def some_function(a, b):
> > > pass # something useful
>
> > So, just ty
On Sat, Mar 13, 2010 at 11:19 AM, Jon Clements wrote:
> This is semi-experimental and I'd appreciate opinions of whether it's
> the correct design approach or not. It seems like a good idea, but it
> doesn't mean it is.
>
> I have a class 'A', this provides standard support functions and
> excepti
On 13 Mar, 16:26, Patrick Maupin wrote:
> On Mar 13, 10:19 am, Jon Clements wrote:
>
> > What I'd like to achieve is something similar to:
>
> > @inject(B):
> > def some_function(a, b):
> > pass # something useful
>
> So, just typing at the keyboard here, you mean something like:
>
> class
On Mar 13, 10:19 am, Jon Clements wrote:
> What I'd like to achieve is something similar to:
>
> @inject(B):
> def some_function(a, b):
> pass # something useful
So, just typing at the keyboard here, you mean something like:
class InjectClass(object):
def __init__(self, func, *args, *
Bruno Desthuilliers wrote:
Short answer: this makes no sense.
Absolutely right, took me a while to figure that out though :-)
Lesson learned (again): If it really seems impossible to do something in
Python, it is likely the proposed solution is flawed.
--
MPH
http://blog.dcuktec.com
'If con
Martin P. Hellwig a écrit :
Hi all,
I have been trying out to wrap my mind around the advantages of
decorators and thought I found a use in one of my experiments. (see code
after my sig).
Although it works, I think it should be able to do it better.
My particular problem is that I want to re
On Apr 7, 7:57 am, Daniel Fetchinson
wrote:
> > have always seen the decorator module
> > as a temporary hack waiting for a proper solution
> > at the language level. I wanted the possibility to modify the
> > signature of a function. Everybody more or less agreed
> > that this was a good idea on
>> Similar functionality is already provided by
>> functools.update_wrapper() and functools.wraps().
>> Seehttp://docs.python.org/library/functools.html
>> You might consider proposing the modification of these functions instead.
>
> Unfortunately functools.update_wrapper() and functools.wraps()
>
On Apr 7, 2:50 am, Chris Rebert wrote:
> Similar functionality is already provided by
> functools.update_wrapper() and functools.wraps().
> Seehttp://docs.python.org/library/functools.html
> You might consider proposing the modification of these functions instead.
Unfortunately functools.update_w
On Mon, Apr 6, 2009 at 5:41 PM, Daniel Fetchinson
wrote:
> The decorator module [1] written by Michele Simionato is a very useful
> tool for maintaining function signatures while applying a decorator.
> Many different projects implement their own versions of the same
> functionality, for example t
Steven D'Aprano wrote:
> On Sun, 02 Nov 2008 09:33:41 -0800, Bryan wrote:
>
> > I'm coming from a .Net background, and yes, one of the reasons I did not
> > consider raising exceptions was to avoid the overhead of an exception
> > handler clause, which in .Net land is expensive.
>
> Actually catchi
On Sun, 02 Nov 2008 09:33:41 -0800, Bryan wrote:
> I'm coming from a .Net background, and yes, one of the reasons I did not
> consider raising exceptions was to avoid the overhead of an exception
> handler clause, which in .Net land is expensive.
Actually catching an exception in Python is expens
Bryan <[EMAIL PROTECTED]> writes:
> However, hoping to make client code cleaner and to avoid setter
> functions doing expensive db lookup validations, I do not validate
> during the setter, but instead defer it until the client explicitly
> asks for the validity of the business object. So the ess
On Nov 1, 6:57 pm, Steven D'Aprano <[EMAIL PROTECTED]
cybersource.com.au> wrote:
> On Sat, 01 Nov 2008 17:12:33 -0700, Bryan wrote:
> > The list of validation error descriptions is returned instead of raising
> > exceptions so clients can show the errors to the user for fixing.
> > Raising exceptio
On Sat, 01 Nov 2008 17:12:33 -0700, Bryan wrote:
> The list of validation error descriptions is returned instead of raising
> exceptions so clients can show the errors to the user for fixing.
> Raising exceptions seems like an uneeded burden for the client, as there
> is nothing exceptional about
Steven D'Aprano wrote:
> On Fri, 31 Oct 2008 11:26:19 -0700, Bryan wrote:
>
> > I want my business objects to be able to do this:
> [snip code]
>
> The code you show is quite long and complex and frankly I don't have the
> time to study it in detail at the moment, but I can make a couple of
> qui
On Fri, 31 Oct 2008 11:26:19 -0700, Bryan wrote:
> I want my business objects to be able to do this:
[snip code]
The code you show is quite long and complex and frankly I don't have the
time to study it in detail at the moment, but I can make a couple of
quick comments. I see by your subject li
On Oct 31, 6:26 pm, Bryan <[EMAIL PROTECTED]> wrote:
> I want my business objects to be able to do this:
> class Person(base):
>
> def __init__(self):
> self.name = None
>
> @base.validator
> def validate_name(self):
> if not self.name: return ['Name cannot be empty']
>
Lee Harr wrote:
I have a class with certain methods from which I want to select
one at random, with weighting.
The way I have done it is this
import random
def weight(value):
def set_weight(method):
method.weight = value
return method
return set_weight
class A(o
Steven D'Aprano wrote:
I agree with you that the simple explicit approach is better.
Now, to answer the question the OP didn't ask:
> def choose_with_weighting(actions, weights=None):
> if weights is None:
> weights = [1]*len(actions) # equal weights
> # Taken virtually unchanged
On Sep 17, 5:56 pm, Lee Harr <[EMAIL PROTECTED]> wrote:
> I have a class with certain methods from which I want to select
> one at random, with weighting.
>
> The way I have done it is this
>
> import random
>
> def weight(value):
> def set_weight(method):
> method.weight = value
On Thu, 18 Sep 2008 02:26:29 +0430, Lee Harr wrote:
> I have a class with certain methods from which I want to select one at
> random, with weighting.
>
> The way I have done it is this
[snip]
You are coupling the weights, the actions, and the object which chooses
an action all in the on
On Sep 17, 6:09 pm, "Aaron \"Castironpi\" Brady"
<[EMAIL PROTECTED]> wrote:
> On Sep 17, 4:56 pm, Lee Harr <[EMAIL PROTECTED]> wrote:
>
>
>
> > I have a class with certain methods from which I want to select
> > one at random, with weighting.
(snip)
>
> > The problem I have now is that if I subclas
On Sep 17, 4:56 pm, Lee Harr <[EMAIL PROTECTED]> wrote:
> I have a class with certain methods from which I want to select
> one at random, with weighting.
>
> The way I have done it is this
>
> import random
>
> def weight(value):
> def set_weight(method):
> method.weight = value
>
>> class Foo(Freezeable):
>> def __init__(self):
>> self.bar = 42
>> self.freeze() # ok, we set all variables, no more from here
>>
>>
>> x = Foo()
>> print x.bar
>> x.bar = -42
>> print x.bar
>> x.baz = "OMG! A typo!"
>>
>
>Pretty nice, but unfortunately the subclass has to remember to call freeze
On Jul 11, 9:24 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> Robert Bossy wrote:
> > class Foo(Freezeable):
> > def __init__(self):
> > self.bar = 42
> > self.freeze() # ok, we set all variables, no more from here
>
> > x = Foo()
> > print x.bar
> > x.bar = -42
> > print x.bar
> > x.baz = "OMG! A t
Robert Bossy wrote:
> class Foo(Freezeable):
> def __init__(self):
> self.bar = 42
> self.freeze() # ok, we set all variables, no more from here
>
>
> x = Foo()
> print x.bar
> x.bar = -42
> print x.bar
> x.baz = "OMG! A typo!"
>
Pretty nice, but unfortunately the subclass has to remember to c
On Jul 11, 6:38 pm, Robert Bossy
> I don't get it. Why use a metaclass? Wouldn't the following be the same,
> but easier to grasp:
>
> class Frozen(object):
> def __setattr__(self, name, value):
> if not hasattr(self, name):
> raise AttributeError, "cannot add attributes to %s"
Michele Simionato wrote:
This article could give you same idea (it is doing the opposite,
warning you
if an attribute is overridden):
http://stacktrace.it/articoli/2008/06/i-pericoli-della-programmazione-con-i-mixin1/
There is also a recipe that does exactly what you want by means of a
metaclass
On Jul 11, 5:29 pm, Neal Becker <[EMAIL PROTECTED]> wrote:
> After spending the morning debugging where I had misspelled the name of an
> attribute (thus adding a new attr instead of updating an existing one), I
> would like a way to decorate a class so that attributes cannot be (easily)
> added.
>
En Fri, 23 May 2008 16:25:19 -0300, Thomas Karolski <[EMAIL PROTECTED]>
escribió:
> Turns out the first msg I sent did not reach the list, so I'll just post
> what I've achieved by now:
[snip a couple of long metaclasses]
> Now the reason why I'm using decorators, is because I want to be ably t
Turns out the first msg I sent did not reach the list, so I'll just post
what I've achieved by now:
--
class DecoratorDummy(object): pass
class InheritedDecoratorType(type):
def __new__(cls, name, bases, dct):
# return if its a clas
On May 23, 11:42 am, Thomas Karolski <[EMAIL PROTECTED]>
wrote:
> > You will note that Decorator does not define __init__. In fact,
> > object.__init__ will be called, which does nothing. If you think that
> > all classes with DecoratorType as their metaclass will be a direct
> > subclass of Dec
Thanks for pointing out all those mistakes. I think I'm already starting
to grasp all of the python magic going on in there.
Parenthetical: I don't normally recommend this style, since it
obscures the fact that you're using a custom metaclass to the user.
That is something the user probably wou
On May 22, 10:28 pm, [EMAIL PROTECTED] wrote:
> Hi,
> I would like to create a Decorator metaclass, which automatically
> turns a class which inherits from the "Decorator" type into a
> decorator.
> A decorator in this case, is simply a class which has all of its
> decorator implementation inside a
Le Friday 23 May 2008 04:28:22 [EMAIL PROTECTED], vous avez
écrit :
> Hi,
> I would like to create a Decorator metaclass, which automatically
> turns a class which inherits from the "Decorator" type into a
> decorator.
> A decorator in this case, is simply a class which has all of its
> decorator
1 - 100 of 203 matches
Mail list logo
