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 pa
On Jan 28, 2005, at 20:27, Tim Peters wrote:
The hacks in PyObject_Free (== PyMem_Free)
are there solely so that question can be answered correctly in the
absence of holding the GIL. "That question" == "does pymalloc
control the pointer passed to me, or does the system malloc?".
Ah! *Now* I get
...
[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 tas
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 w
On Sat, 2005-01-29 at 00:24 +0100, "Martin v. Löwis" wrote:
> Evan Jones wrote:
[...]
> The allocator is thread-safe in the presence of the GIL - you are
> supposed to hold the GIL before entering the allocator. Due to some
> unfortunate historical reasons, there is code which enters free()
> witho
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.
Pyth
On Jan 28, 2005, at 18:24, Martin v. Löwis wrote:
5. Many modules may not be thread safe (?).
Modules often release the GIL through BEGIN_ALLOW_THREADS, if they know
that would be safe if another thread would enter the Python
interpreter.
Right, I guess that the modules already have to deal with b
Evan Jones wrote:
Due to the issue of thread safety in the Python memory allocator, I have
been wondering about thread safety in the rest of the Python
interpreter. I understand that the interpreter is not thread safe, but
I'm not sure that I have seen a discussion of the all areas where this
i
Jeff Rush wrote:
If they are put into __builtins__, the documentation won't need
updating. ;-)
In that case, I'd rather prefer to correct the documentation.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/l
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
Josiah Carlson wrote:
While it seems that super() is the 'modern paradigm' for this,
I have been using base.method(self, ...) for years now, and have been
quite happy with it.
I too would be very disappointed if base.method(self, ...)
became somehow deprecated. Cooperative super calls are a
differe
[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 unbo
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
method
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 t
Due to the issue of thread safety in the Python memory allocator, I
have been wondering about thread safety in the rest of the Python
interpreter. I understand that the interpreter is not thread safe, but
I'm not sure that I have seen a discussion of the all areas where this
is an issue. Here a
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 attr
16 matches
Mail list logo
