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
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,
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 replace.
I
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 exactly like the
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 would prefer to
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
and
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 function f at
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
f()
Hi
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
[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 this.
[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 little
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 intention of
[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 having a construct
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 decorator outside the class.
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
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 to
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'msure Phillip is familiar with these).They're used with functions toindicate that the function adapts a particular
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
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:
Docstring
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 is hoopy
@def
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)
is easier to read than:
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 here, blah blah
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
something
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
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
[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
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]
That's
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)
Mike Krell wrote:
Greg Ewing greg.ewing at 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
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 be
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 about 2.6?
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:
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 argument for
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.
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 docstring.
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 readability, vs.
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
decorators.
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
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 classes is
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't
Greg Ewing greg.ewing at 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
At 07:20 PM 3/27/2006 +, Mike Krell wrote:
Greg Ewing greg.ewing at 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
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:
from
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 function
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'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
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 these claims
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
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.
A.
49 matches
Mail list logo
