Bob Ippolito пишет:
> Well you simply can't do what you propose without writing code in the
> style of Twisted or with interpreter modifications or evil stack
> slicing such as with stackless or greenlet. If you aren't willing to
> choose any of those then you'll have to live without that
> functi
On 12/23/06, Evgeniy Khramtsov <[EMAIL PROTECTED]> wrote:
> Mike Klaas пишет:
>
> > I'm not sure how having python execute code at an arbitrary time would
> > _reduce_ race conditions and/or deadlocks. And if you want to make it
> > safe by executing code that shares no variables or resources, then
Josiah Carlson пишет:
>writing of a scheduler and the execution of scheduled tasks in a
>scheduler? If so, you can implement it today (I would suggest using the
>heapq module, and/or the pair heap I posted to this list a few weeks ago),
>or you can use a previously existing mainloop for handling
On Thursday 21 December 2006 15:23, Martin v. Löwis wrote:
> Now it seem that introducing them has the unfortunate side effect
> that people think they *have* to use them, and that doing so gives
> better code...
Speaking strictly for myself: I don't think I *have* to use them, but I do
prefe
Mike Klaas пишет:
> I'm not sure how having python execute code at an arbitrary time would
> _reduce_ race conditions and/or deadlocks. And if you want to make it
> safe by executing code that shares no variables or resources, then it
> is no less safe to use threads, due to the GIL.
>
Ok. And wha
Evgeniy Khramtsov <[EMAIL PROTECTED]> wrote:
>
> The question to python core developers:
> Is there any plans to implement non-blocking timer like a
> threading.Timer() but without thread?
> Some interpreted languages (like Tcl or Erlang) have such functionality,
> so I think it would be a grea
On 12/22/06, Evgeniy Khramtsov <[EMAIL PROTECTED]> wrote:
> The question to python core developers:
> Is there any plans to implement non-blocking timer like a
> threading.Timer() but without thread?
> Some interpreted languages (like Tcl or Erlang) have such functionality,
> so I think it would be
The question to python core developers:
Is there any plans to implement non-blocking timer like a
threading.Timer() but without thread?
Some interpreted languages (like Tcl or Erlang) have such functionality,
so I think it would be a great
feature in Python :)
The main goal is to prevent threads
On 12/23/06, Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> On Friday 22 December 2006 7:54 pm, Bob Ippolito wrote:
> > It's a whole lot more practical to just stop using mod_python and go
> > for one of the other ways of exposing Python code to the internet. I
> > bet you can get the same or better per
On Friday 22 December 2006 7:16 pm, Guido van Rossum wrote:
> I think you understand exactly what is happening. It is happening for
> good reasons. Rather than asking for a change in semantics, I
> recommend that you deal with it, either in your Python code, or in
> your extension. It's not likely
On Friday 22 December 2006 7:54 pm, Bob Ippolito wrote:
> It's a whole lot more practical to just stop using mod_python and go
> for one of the other ways of exposing Python code to the internet. I
> bet you can get the same or better performance out of another solution
> anyway, and you'd save dep
On 12/23/06, Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> On Friday 22 December 2006 5:02 pm, Josiah Carlson wrote:
> > Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> > > [[ This may be somewhat c.l.p.-ish but I feel that this crossed into
> > > CPython development enough to merit posting here ]]
> > >
> >
I think you understand exactly what is happening. It is happening for
good reasons. Rather than asking for a change in semantics, I
recommend that you deal with it, either in your Python code, or in
your extension. It's not likely to change.
--Guido
On 12/22/06, Jeremy Kloth <[EMAIL PROTECTED]> w
On Friday 22 December 2006 5:02 pm, Josiah Carlson wrote:
> Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> > [[ This may be somewhat c.l.p.-ish but I feel that this crossed into
> > CPython development enough to merit posting here ]]
> >
> > I have received a bug report for 4Suite that involves a
> > Py
I started to discuss this on the new python-ideas list because I thought it may
need a bit more completion before bringing it here. But It was suggested that
it really does belong here as it is something that would be nice to have in
python 2.6. So I'm reposting the introduction here.
The s
Jeremy Kloth <[EMAIL PROTECTED]> wrote:
> [[ This may be somewhat c.l.p.-ish but I feel that this crossed into CPython
> development enough to merit posting here ]]
>
> I have received a bug report for 4Suite that involves a PyObject_IsInstance
> check failing for what appears to be the correct
Brett> So, here are the platforms I figured we should drop:
...
Brett> * OS/2
I'm pretty sure Andrew MacIntyre is still maintaining the OS/2+EMX port:
http://members.pcug.org.au/~andymac/python.html
Skip
___
Python-Dev mailing list
Py
On 12/22/06, A.M. Kuchling <[EMAIL PROTECTED]> wrote:
> http://www.python.org/sf/411881 is a bug about removing use
> of 'except:' in stdlib code. In many cases the intent is to catch
> one particular exception such as ImportError or AttributeError,
> but catching all exceptions can disguise othte
I originally posted this list to python-3000 since I figured we could
be more aggressive with Py3K, but Guido said I should move it over
here and just be aggressive in 2.6.
So, here are the platforms I figured we should drop:
* AtheOS
* BeOS
* FreeBSD 2 (maybe more?)
* IRIX
* NeXT
* OS/2
* UnixWa
[[ This may be somewhat c.l.p.-ish but I feel that this crossed into CPython
development enough to merit posting here ]]
I have received a bug report for 4Suite that involves a PyObject_IsInstance
check failing for what appears to be the correct class, that is, the class
names match. With some
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Dec 22, 2006, at 8:05 AM, A.M. Kuchling wrote:
>A good rule of thumb is that you should only use 'except:' if the
>exception handler will be printing out or logging the traceback; at
>least the user will be aware that an error has occur
http://www.python.org/sf/411881 is a bug about removing use
of 'except:' in stdlib code. In many cases the intent is to catch
one particular exception such as ImportError or AttributeError,
but catching all exceptions can disguise other problems.
Should PEP 8 mention this issue? Here's some prop
22 matches
Mail list logo
