Steven Bethard wrote:
That sounds reasonable to me. I'll fix update to be a staticmethod.
If people want other methods, I'll make sure they're staticmethods
too.[1]
Steve
[1] In all the cases I can think of, staticmethod is sufficient -- the
methods don't need to access any attributes
Aahz, writing as [EMAIL PROTECTED], wrote:
It's still January 28 here -- register now! I don't know if we'll be
able to extend the registration price beyond that.
Just in case anybody else might be wondering when the early bird
registration deadline is, I've asked the registration team to allow
Guido van Rossum wrote:
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound method object.
I thought the main reason for existence of unbound
[Guido]
Here's a patch that gets rid of unbound methods, as
discussed here before. A function's __get__ method
now returns the function unchanged when called without
an instance, instead of returning an unbound method object.
[Greg]
I thought the main reason for existence of unbound
Tim Peters wrote:
I expect that's because he stopped working on Zope code, so actually
thinks it's odd again to see a gazillion methods like:
class Registerer(my_base):
def register(*args, **kws):
my_base.register(*args, **kws)
I second that! My PyGUI code is *full* of __init__
methods
Evan Jones wrote:
Sorry, I really meant *parallel* execution of Python code: Multiple
threads simultaneously executing a Python program, potentially on
different CPUs.
There cannot be parallel threads on a single CPU - for threads to
be truly parallel, you *must* have two CPUs, at a minimum.
Martin v. Löwis writes:
Due to some
unfortunate historical reasons, there is code which enters free()
without holding the GIL - and that is what the allocator specifically
deals with. Except for this single case, all callers of the allocator
are required to hold the GIL.
Donovan Baarda
...
[Evan Jones]
What I was trying to ask with my last email was what are the trouble
areas? There are probably many that I am unaware of, due to my
unfamiliarity the Python internals.
Google on Python free threading. That's not meant to be curt, it's
just meant to recognize that the task is
On Jan 28, 2005, at 19:44, Martin v. Löwis wrote:
Python threads can run truly parallel, as long as one of them
invoke BEGIN_ALLOW_THREADS.
Except that they are really executing C code, not Python code.
I think nobody really remembers - ask Google for Python free
threading. Greg Stein did the
