Greg Ewing schrieb:
> Paul Prescod wrote:
>> It seems that the emerging
>> consensus (bar a security question from Guido) is that ctypes it the way
>> forward for calling C code in Python 3000. I'd like to clarify what this
>> might mean:
>
> What's the state of play concerning ctypes support
>
[Guido]
> I expect that Jython doesn't implement this; it doesn't handle ^C either
> AFAIK.
threads are at most platform agnostic (old unices, embedded systems, etc.
are not likely to have thread support)
so keeping this in mind, and having interrupt_main part of the standard
thread API, which a
On Thu, 10 Aug 2006 23:01:45 -0400
Luis P Caamano <[EMAIL PROTECTED]> wrote:
#> Yes, I also wonder about how non-CPython implementations would handle
#> this but I'd just like to say that this feature, making a thread raise
#> a specific exception from another thread asynchronously is a very
#> us
At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>Or to put it another way: If you create a tool, and you assume that tool
>will only be used in certain specific ways, but you fail to enforce that
>limitation, then your assumption will be dead wrong. The idea that there
>will only be a
Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> I believe that if asynchronous exception raising ever gets officially
> approved, there absolutely *needs* to be a way to block it for a piece
> of code that should execute atomically.
There is already a way of making Python source execution atomic w
On 8/11/06, tomer filiba <[EMAIL PROTECTED]> wrote:
> why is thread.raise_exc(id, excobj) a bad API?
It breaks seemingly innocent code in subtle ways. Worse, the breakage
will always be a race condition, so it'll be especially hard to
reproduce and debug.
class Foo:
...
def close(self):
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>
> At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
> >Or to put it another way: If you create a tool, and you assume that tool
> >will only be used in certain specific ways, but you fail to enforce that
> >limitation, then your assumption
On 8/11/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> > But it should not be done lightly and never when the code is not
> > specifically expecting it.
>
> If you don't want random exceptions being raised in your threads, then
> don't use this method
"Jason Orendorff" <[EMAIL PROTECTED]> wrote:
>
> On 8/11/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> > Slawomir Nowaczyk <[EMAIL PROTECTED]> wrote:
> > > But it should not be done lightly and never when the code is not
> > > specifically expecting it.
> >
> > If you don't want random exceptio
Josiah Carlson <[EMAIL PROTECTED]> writes:
> There is already a way of making Python source execution atomic with
> respect to other Python code [1].
It's not realistic to expect sys.setcheckinterval be implementable on
other runtimes.
Also, it doesn't provide a way to unblock asynchronous excep
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson <[EMAIL PROTECTED]> writes:
>
> > There is already a way of making Python source execution atomic with
> > respect to other Python code [1].
>
> It's not realistic to expect sys.setcheckinterval be implementable on
> othe
Josiah Carlson <[EMAIL PROTECTED]> writes:
>> It's not realistic to expect sys.setcheckinterval be implementable on
>> other runtimes.
>
> The 'raise an exception in an alternate thread' functionality is a
> CPython specific functionality. If you believe that it could be
> implemented in all othe
At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote:
>I think you misunderstood Talin. While it was a pain for him to work
>his way through implementing all of the loading/etc. protocols, I
>believe his point was that if we allow any and all arbitrary metadata to
>be placed on arguments to and from
Threading is already difficult enough to do 'right' (see the dozens of
threads discussing why this is really the case), and designing software
that can survive the raising of an exception at any point makes
threading even more difficult.
I believe that you are attempting to design an interface to
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote:
> >I think you misunderstood Talin. While it was a pain for him to work
> >his way through implementing all of the loading/etc. protocols, I
> >believe his point was that if we allow any and all arbit
At 01:46 PM 8/11/2006 -0700, Josiah Carlson wrote:
>"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> > At 09:04 AM 8/11/2006 -0700, Josiah Carlson wrote:
> > >I think you misunderstood Talin. While it was a pain for him to work
> > >his way through implementing all of the loading/etc. protocols, I
>
Phillip J. Eby wrote:
> At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>> Or to put it another way: If you create a tool, and you assume that tool
>> will only be used in certain specific ways, but you fail to enforce that
>> limitation, then your assumption will be dead wrong. The i
Josiah Carlson wrote:
> "Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
>> At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>>> Or to put it another way: If you create a tool, and you assume that tool
>>> will only be used in certain specific ways, but you fail to enforce that
>>> limitati
When we have keyword-only arguments, do we allow 'keyword dictionary'
argument? If that's the case, where would we want to place
keyword-only arguments?
Are we going to allow any of followings?
1. def foo(a, b, *, key1=None, key2=None, **map)
2. def foo(a, b, *, **map, key1=None, key2=None)
3.
I'll combine my replies to Josian and Talin:
On 8/11/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
Let us say that I have two metadata interpters. One that believes that
the metadata is types and wants to verify type on function call. The
other believes that the metadata is documentation. Bot
i mailed this to several people separately, but then i thought it could benefitthe entire group:http://sebulba.wikispaces.com/recipe+thread2it's an implementation of the proposed "
thread.raise_exc", through an extensionto the threading.Thread class. you can test it for yourself; if it proves usefu
Slawomir Nowaczyk wrote:
> But it should not be done lightly and never when the code is not
> specifically expecting it.
What if, together with a way of blocking asynchronous
exceptions, threads started out by default with them
blocked? Then a thread would have to explicitly consent
to being inte
At 3:16 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>Phillip J. Eby wrote:
> > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
> >> Or to put it another way: If you create a tool, and you assume that tool
> >> will only be used in certain specific ways, but you fail to enforc
That's how I feel too Josiah. In some ways, it's the same as writing
device drivers in a pre-emptable kernel. You can get interrupted and
pre-empted by the hardware at any freaking time in any piece of code
and your memory might go away so you better pin it and deal with the
interrupts. Forget a
Phillip J. Eby wrote:
> At 3:16 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>> Phillip J. Eby wrote:
>> > At 06:10 AM 8/11/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>> >> Or to put it another way: If you create a tool, and you assume that
>> tool
>> >> will only be used in certain spec
On 8/11/06, Talin <[EMAIL PROTECTED]> wrote:
> The story also has to do with people who assume things about the
> behavior of other software developers - specifically, my assumption that
> other people, working in isolation from one another, would come up with
> the same or similar solutions to a g
At 03:39 PM 8/12/2006 -0700, Talin <[EMAIL PROTECTED]> wrote:
>Say I want to annotate a specific argument with two pieces of
>information, a type and a docstring. I have two metadata interpreters,
>one which uses the type information to restrict the kinds of arguments
>that can be passed in, and an
At 07:49 PM 8/12/2006 -0400, "Collin Winter" <[EMAIL PROTECTED]> wrote:
>What Josiah is hinting at -- and what Talin describes more explicitly
>-- is the problem of how exactly "chaining" annotation interpreters
>will work.
I'd prefer we not use the word "interpreters" to describe operations that
Josiah Carlson <[EMAIL PROTECTED]> writes:
> Threading is already difficult enough to do 'right' (see the dozens
> of threads discussing why this is really the case), and designing
> software that can survive the raising of an exception at any point
> makes threading even more difficult.
That's w
> I don't see the point of this. A decorator should be responsible for
> manipulating the signature of its return value. Meanwhile, the semantics
> for combining annotations should be defined by an overloaded function like
> "combineAnnotations(a1,a2)" that returns a new annotation. There is no
Phillip J. Eby wrote:
> Not at all. A and B need only use overloadable functions, and the
> problem is trivially resolved by adding overloads. The author of C can
> add an overload to "A" that will handle objects with 'next' attributes,
> or add one to "B" that handles tuples, or both.
I'm s
On Fri, 11 Aug 2006 21:51:25 -0400
Luis P Caamano <[EMAIL PROTECTED]> wrote:
#> That's how I feel too Josiah. In some ways, it's the same as writing
#> device drivers in a pre-emptable kernel. You can get interrupted and
#> pre-empted by the hardware at any freaking time in any piece of code
#>
Slawomir Nowaczyk wrote:
> On Fri, 11 Aug 2006 21:51:25 -0400
> Luis P Caamano <[EMAIL PROTECTED]> wrote:
>
> #> That's how I feel too Josiah. In some ways, it's the same as writing
> #> device drivers in a pre-emptable kernel. You can get interrupted and
> #> pre-empted by the hardware at any f
33 matches
Mail list logo
