11.08.18 23:08, Santiago Basulto пише:
Hello folks! I'm using the `concurrent.futures.ProcessPoolExecutor` with
a couple of functions that have been decorated with a class decorator.
Both `concurrent.futures` and `multiprocessing` breaks because "the
object's can't be pickled". There's a really
Hello folks! I'm using the `concurrent.futures.ProcessPoolExecutor` with a
couple of functions that have been decorated with a class decorator. Both
`concurrent.futures` and `multiprocessing` breaks because "the object's
can't be pickled". There's a really simple fix for this, which is just,
instea
Jim Jewett wrote:
> Nick Coghlan wrote:
>
>> [ much good, including the @instance decorator ]
>
>> P.S. If all you want is somewhere to store mutable
>> state between invocations, you can always use the
>> function's own attribute space
>
> >>> def f(): print "Hi world from %s!" % f
>
>
Nick Coghlan wrote:
> [ much good, including the @instance decorator ]
> P.S. If all you want is somewhere to store mutable
> state between invocations, you can always use the
> function's own attribute space
>>> def f(): print "Hi world from %s!" % f
>>> f()
Hi world from !
Not r
On Friday 31 March 2006 11:52, Phillip J. Eby wrote:
> class bar:
> @class foo
> def __init___(...):
> ...
The more I think about it, the more I like the "@class foo" syntax. The
existing syntax for functions doesn't have anything between the decorators
a
At 04:47 AM 3/31/2006 -0800, Michael Chermside wrote:
>In the discussion over class decorators, Jim Jewett writes:
> > I have often started with a function, and ended up replacing it with a
> > callable object so that I could save state without resorting to
> > "defalt args" or worse.
> >
> > I wou
Michael Chermside wrote:
> In the discussion over class decorators, Jim Jewett writes:
>> I have often started with a function, and ended up replacing it with a
>> callable object so that I could save state without resorting to
>> "defalt args" or worse.
>>
>> I would prefer to decorate these exact
In the discussion over class decorators, Jim Jewett writes:
> I have often started with a function, and ended up replacing it with a
> callable object so that I could save state without resorting to
> "defalt args" or worse.
>
> I would prefer to decorate these exactly like the functions they repla
Phillip J. Eby wrote:
> I don't even recall seeing any examples of class decorators
> being used without arguments!
I have often started with a function, and ended up replacing it with a
callable object so that I could save state without resorting to
"defalt args" or worse.
I would prefer to dec
Fred L. Drake, Jr. wrote:
> > It's too bad this syntax is ambiguous:
> >
> > class Foo:
> > """Docstring here, blah blah blah
> > """
> > @implements(IFoo)
> >
> > As this achieves a desirable highlighting of the specialness, without
> > forcing the decorato
[EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote on
> 30/03/2006 11:38:30:
>
>> Jack Diederich wrote:
>>
>> > Classes have a unique property in that they are the easiest way to
> make
>> > little namespaces in python.
>>
>> For a while now, I've been wondering whether it would
>> be worth ha
Raymond Hettinger wrote:
> FWIW, I do not consider it an abuse to use a class to create a small
> namespace. Essentially that is what it is for -- it matters not whether
> the class has no methods.
Two problems with that:
* The word "class" in front of it is a misnomer if
you've no intentio
[EMAIL PROTECTED] wrote on
30/03/2006 11:38:30:
> Jack Diederich wrote:
>
> > Classes have a unique property in that they are the easiest way to
make
> > little namespaces in python.
>
> For a while now, I've been wondering whether it would
> be worth having a construct purely for creating lit
[Jack Diederich]
>> Classes have a unique property in that they are the easiest way to make
>> little namespaces in python.
[Greg Ewing]
> For a while now, I've been wondering whether it would
> be worth having a construct purely for creating little
> namespaces, instead of abusing a class for thi
Phillip J. Eby wrote:
> Are you actually *using* this IOClass thing, or is this just a
> hypothetical proposal?
I'm using it. It's not hypothetical.
Putting all the info I want in the decorator itself
wouldn't be very nice in my case, or at least that's
my opinion. One issue is that I'm also ab
Jack Diederich wrote:
> Classes have a unique property in that they are the easiest way to make
> little namespaces in python.
For a while now, I've been wondering whether it would
be worth having a construct purely for creating little
namespaces, instead of abusing a class for this.
I've been t
At 11:09 PM 3/29/2006 -0500, Jack Diederich wrote:
>I think we both want class decorators as a more fine grained substitute
>for __metaclass__ (fine grained as in declared per-class-instance instead
>of this-class-and-all-its-children). I can think of three ways class
>decorators are used:
>
>1) r
At 03:09 PM 3/30/2006 +1200, Greg Ewing wrote:
>Well, here's how my use case would look if I had
>class decorators:
>
>@IOClass
>class MyClass:
> ...
>
>Does that count? My decorator wouldn't need any
>arguments, because it looks inside the class for
>all the information it needs. [1]
[promted by Phillip Eby's post, but not in response so content snipped]
I think we both want class decorators as a more fine grained substitute
for __metaclass__ (fine grained as in declared per-class-instance instead
of this-class-and-all-its-children). I can think of three ways class
decorators
Phillip J. Eby wrote:
> the readability of @decorators on the outside of a class tends
> to suck as the number of decorators and arguments increases.
So do decorators outside a function.
> What's more, I haven't seen anybody posting any counterexamples to show
> that it doesn't suck for common
Jack Diederich wrote:
> Using metaclasses also required gross hacks like checking
> for a 'DO_NOT_REGISTER' member for subclasses that wanted to inherit from
> a class that had a Register metaclass but didn't want to be registered.
I've just done something like this myself in the last
few days, a
Phillip J. Eby wrote:
> My comment above was only about readable *placement* of the decorators, not
> the actual syntax.
The placement is part of the syntax...
--
Greg Ewing, Computer Science Dept, +--+
University of Canterbury, | Carpe post meridia
At 08:00 PM 3/29/2006 -0500, Jack Diederich wrote:
>A function decorator takes a function as an argument and returns something
>(probably a function and maybe even the very same function).
So would class decorators.
>This is exactly what class decorators should do or we should call them
>somethi
On Wed, Mar 29, 2006 at 07:23:03PM -0500, Phillip J. Eby wrote:
> At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote:
> >On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > > If we're using Zope 3 as an example, I personally find that:
> > >
> > > class Foo:
> > > """Docstring
At 11:07 AM 3/29/2006 -0800, Guido van Rossum wrote:
>On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > If we're using Zope 3 as an example, I personally find that:
> >
> > class Foo:
> > """Docstring here, blah blah blah
> > """
> > implements(IFoo)
> >
> >
At 10:42 AM 3/30/2006 +1200, Greg Ewing wrote:
>Fred L. Drake, Jr. wrote:
>
> > class Foo:
> > """Documentation is good."""
> >
> > @class implements(IFoo)
>
>That's an interesting idea. It could be applied to
>functions, too:
>
>def myfunc(myargs):
> """Documentation i
Fred L. Drake, Jr. wrote:
> class Foo:
> """Documentation is good."""
>
> @class implements(IFoo)
That's an interesting idea. It could be applied to
functions, too:
def myfunc(myargs):
"""Documentation is hoopy"
@def biguglydecorator(longconvolutedarglist)
Some
On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> If we're using Zope 3 as an example, I personally find that:
>
> class Foo:
> """Docstring here, blah blah blah
> """
> implements(IFoo)
>
> is easier to read than:
>
> @implements(IFoo)
> class Foo:
>
On Wed, Mar 29, 2006 at 01:11:06AM -0500, Fred L. Drake, Jr. wrote:
> On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote:
> > I think the existing usage for classes is perfectly readable. The
> > @-syntax works well for functions as well.
>
> On re-reading what I wrote, I don't think I
At 12:48 AM 3/29/2006 -0500, Fred L. Drake, Jr. wrote:
>Agreed, but... guess we can't have everything. On the other hand, something
>like:
>
> class Foo:
> """Documentation is good."""
>
> @class implements(IFoo)
>
>is not ambiguous. Hmm. It even says what it means. :-)
Int
On 3/29/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:>For Zope 3, we have decorators that work with the component architecture (I'm>sure Phillip is familiar with these). They're used with functions to>indicate that the function adapts a partic
On Wed, 2006-03-29 at 00:01 -0500, Phillip J. Eby wrote:
> For some reason, this doesn't bother me with functions. But then, I can't
> remember how often I've actually needed to use two decorators on the same
> function, or how many times a function decorator's arguments took multiple
> lines
On Wednesday 29 March 2006 00:48, Fred L. Drake, Jr. wrote:
> I think the existing usage for classes is perfectly readable. The
> @-syntax works well for functions as well.
On re-reading what I wrote, I don't think I actually clarified the point I was
trying to make originally.
My point wasn'
On Wednesday 29 March 2006 00:01, Phillip J. Eby wrote:
> If we're using Zope 3 as an example, I personally find that:
>
> class Foo:
> """Docstring here, blah blah blah
> """
> implements(IFoo)
>
> is easier to read than:
I think the existing usage for clas
At 11:35 PM 3/28/2006 -0500, Fred L. Drake, Jr. wrote:
>For Zope 3, we have decorators that work with the component architecture (I'm
>sure Phillip is familiar with these). They're used with functions to
>indicate that the function adapts a particular kind of object, or that it
>implements or prov
On Tuesday 28 March 2006 22:06, Phillip J. Eby wrote:
> And here it is: because the use cases for class decorators are
> different.
This is vague.
> I routinely use them with things that take numerous keyword
> arguments, but this isn't nearly as common of a scenario for function
> decorato
At 02:55 PM 3/29/2006 +1200, Greg Ewing wrote:
>Phillip J. Eby wrote:
>
> > http://mail.python.org/pipermail/python-dev/2004-March/043462.html
>
> > Or more precisely, the subsequent discussion and examples convinced me
> that
> > putting class decorators on top of the class was bad for readabilit
Phillip J. Eby wrote:
> http://mail.python.org/pipermail/python-dev/2004-March/043462.html
> Or more precisely, the subsequent discussion and examples convinced me that
> putting class decorators on top of the class was bad for readability, vs.
> putting them in the body just after the docstrin
At 11:04 AM 3/28/2006 -0800, Guido van Rossum wrote:
>That's fine. But there's also the C#/Java POV.
Can someone point me to examples of C# class "attributes" and Java
annotations that they'd like to use with this mechanism? I would indeed
like to see how those use cases compare with mine.
>
On 3/28/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote:
> >OK, I'm convinced (mostly by the awful hackery that Phillip so proudly
> >exposed :-).
>
> Just as a historical note, here's where you previously rejected the same
> hackery as an argumen
At 10:01 AM 3/28/2006 -0800, Guido van Rossum wrote:
>OK, I'm convinced (mostly by the awful hackery that Phillip so proudly
>exposed :-).
Just as a historical note, here's where you previously rejected the same
hackery as an argument for supporting class decorators:
http://mail.python.org/piper
On Tue, Mar 28, 2006 at 10:16:01AM -0800, Neal Norwitz wrote:
> On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> >
> > I propose that someone start writing a Py3k PEP for class decorators.
> > I don't think it's fair to the 2.5 release team to want to push this
> > into 2.5 though; how ab
On 3/28/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>
> I propose that someone start writing a Py3k PEP for class decorators.
> I don't think it's fair to the 2.5 release team to want to push this
> into 2.5 though; how about 2.6?
Wasn't there already a (pretty small) patch? I guess it would
On 3/28/06, Samuele Pedroni <[EMAIL PROTECTED]> wrote:
> Mike Krell wrote:
> >Greg Ewing canterbury.ac.nz> writes:
> >>I've just been playing around with metaclasses, and
> >>I think I've stumbled across a reason for having
> >>class decorators as an alternative to metaclasses
> >>for some purpose
Mike Krell wrote:
>Greg Ewing canterbury.ac.nz> writes:
>
>
>
>>I've just been playing around with metaclasses, and
>>I think I've stumbled across a reason for having
>>class decorators as an alternative to metaclasses
>>for some purposes.
>>
>>
>
>There has also been discussion on the Iron
Phillip J. Eby wrote:
> It registers a function as the __metaclass__ by poking it into the f_locals
> of the frame that's defining the class.
That is stunningly brilliant! I'd nominate it for
Hack of the Year if there were such an award.
It's far too magical for me to feel like actually
using i
At 08:02 PM 3/27/2006 -0800, Guido van Rossum wrote:
>Just curious (and lazy): what magic is the implementation using that
>makes this work without a custom metaclass?
It registers a function as the __metaclass__ by poking it into the f_locals
of the frame that's defining the class. This functio
On 3/27/06, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> PyProtocols and the zope.interface package both support inline class
> decorators called "class advisors". They don't require any special syntax,
> and aren't much more complex than regular decorators. By defining an
> advisor like this:
>
>
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
>Greg Ewing canterbury.ac.nz> writes:
>
> >
> > I've just been playing around with metaclasses, and
> > I think I've stumbled across a reason for having
> > class decorators as an alternative to metaclasses
> > for some purposes.
>
>There has also bee
Greg Ewing canterbury.ac.nz> writes:
>
> I've just been playing around with metaclasses, and
> I think I've stumbled across a reason for having
> class decorators as an alternative to metaclasses
> for some purposes.
There has also been discussion on the IronPython mailing list that class
decor
I've just been playing around with metaclasses, and
I think I've stumbled across a reason for having
class decorators as an alternative to metaclasses
for some purposes.
The metaclass I wrote was for the purpose of
adding a class to a registry, the reason for which
isn't important here. It worked,
On 11/5/05, Alex Martelli <[EMAIL PROTECTED]> wrote:
> On 11/4/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> > I have a few claims, some unrelated, and some built on top of each
> > other. I would like to hear your responses as to which are
> > convincing, which arne't, and why. I think that if thes
On 11/4/05, Eyal Lotem <[EMAIL PROTECTED]> wrote:
> I have a few claims, some unrelated, and some built on top of each
> other. I would like to hear your responses as to which are
> convincing, which arne't, and why. I think that if these claims are
> true, Python 3000 should change quite a bit.
>
I have a few claims, some unrelated, and some built on top of each
other. I would like to hear your responses as to which are
convincing, which arne't, and why. I think that if these claims are
true, Python 3000 should change quite a bit.
A. Metaclass code is black magic and few understand how it
54 matches
Mail list logo
