On 18/03/07, Tony Meyer [EMAIL PROTECTED] wrote:
on someone else's patch. It seems relevant to me that the original
poster (Tony Meyer) hasn't felt strongly enough to respond on his own
behalf to comments on his patch. No disrespect to Tony, but I'd argue
that the implication is that the
Grrk. I have done this myself, and been involved in one of the VERY
few commercial projects that attempted to do it properly (IBM CEL,
the other recent one being VMS). I am afraid that there are a lot
of misapprehensions here.
Several people have said things like:
The thing to model this on,
On 3/18/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
Let me take the opportunity to make this clear, then. I have the utmost
respect for Martin and his contributions for Python. I have been following
commits for quite a while and I know that Martin, in particular, is often
the one who
Nick Maclaren [EMAIL PROTECTED] wrote:
Sockets, terminals etc. are stateful devices, and killing a process
can leave them in a very unclean state. It is one of the most
common causes of unkillable processes (the process can't go until
its files do, and the socket is jammed).
Can you
At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote:
This is an experiment for me as well; if you all would prefer me to
stay out of it, I will.
With respect to the specific change, it seems to me that there is an
emerging consensus for adding keyword arguments to support the new
behaviors, so
Jon Ribbens [EMAIL PROTECTED] wrote:
Can you elaborate on this? You can get zombie entries in the process
table if nobody's called 'wait()' on them, and you can (extremely
rarely) get unkillable process in 'disk-wait' state (usually due to
hardware failure or a kernel bug, I suspect), but
Phillip J. Eby wrote:
At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote:
This is an experiment for me as well; if you all would prefer me to
stay out of it, I will.
With respect to the specific change, it seems to me that there is an
emerging consensus for adding keyword arguments to
At 12:43 PM 3/19/2007 -0400, Steve Holden wrote:
Phillip J. Eby wrote:
At 12:53 PM 3/18/2007 -0700, Guido van Rossum wrote:
This is an experiment for me as well; if you all would prefer me to
stay out of it, I will.
With respect to the specific change, it seems to me that there is an
Phillip J. Eby schrieb:
Actually, he asked first if we *want* him to make one, and my answer to
that is above: I don't think it's necessary. Like Martin, I believe we are
within sight of a consensus. And I think that's better for Python and
Python-Dev than dragging Guido into it.
I
At 06:28 PM 3/19/2007 +0100, Martin v. Löwis wrote:
Phillip J. Eby schrieb:
Actually, he asked first if we *want* him to make one, and my answer to
that is above: I don't think it's necessary. Like Martin, I believe we
are
within sight of a consensus. And I think that's better for
I'd like to have opinions on two issues:
Patch #1682205: suggests to remove code that catches a TypeError and raises one
with a different message if it occurs during iterable unpacking. This can mask
completely unrelated TypeErrors, while the message in the case that the new
error describes is
Specifically, however, I would prefer to see it without the warning and
future change, as I don't think it provides any real benefit. Either
way, some people will have to use a keyword to get what they want, so
making a change seems unnecessary.
However, if we have to change something
On 3/19/07, Georg Brandl [EMAIL PROTECTED] wrote:
I'd like to have opinions on two issues:
Patch #1682205: suggests to remove code that catches a TypeError and raises
one
with a different message if it occurs during iterable unpacking. This can mask
completely unrelated TypeErrors, while
delurk
On Windows it's correct that splitext(.txt)[1] == splitext(foo.txt)[1]
and an implementation in which this is not true would be considered buggy.
On *ix it's correct that splitext(.txt)[1] != splitext(foo.txt)[1] and
the current behaviour is considered buggy. Since programmer expectations
I'm considering applying to be a student in this year's SoC, and the
AST code generation in particular looks interesting to me (listed
here: http://wiki.python.org/moin/CodingProjectIdeas/PythonCore).
I was wondering a few things:
1) Who would most likely mentor this project?
2) I've never
On 3/19/07, Jay Parlar [EMAIL PROTECTED] wrote:
I'm considering applying to be a student in this year's SoC, and the
AST code generation in particular looks interesting to me (listed
here: http://wiki.python.org/moin/CodingProjectIdeas/PythonCore).
I was wondering a few things:
1) Who would
Nick Maclaren wrote:
Think of updating a complex object in a multi-file database, for
example. Interrupting half-way through leaves the database in a
mess, but blocking interrupts while (possibly remote) file updates
complete is asking for a hang.
Currently, threads can't be interrupted at
Nick Maclaren wrote:
You don't always SEE the stuck process - sometimes
the 'kill -9' causes the pid to become invisible to ps etc., and
just occasionally it can continue to use CPU until the system is
rebooted.
If that happens, there's a bug in the kernel. A process
killed with -9 shouldn't
-- Forwarded message --
From: Mustafa [EMAIL PROTECTED]
Date: Mar 19, 2007 11:41 AM
Subject: have u seen an idea even billGates shouldn't hear Mr.Guido ?
please read because it's important.
To: [EMAIL PROTECTED]
hello,
i like python and find you to be a cool programmer.
i
Sorry for the top post, but I couldn't find the right place to interject...
Are you going to try it ?
Michael
Guido van Rossum wrote:
-- Forwarded message --
From: Mustafa [EMAIL PROTECTED]
Date: Mar 19, 2007 11:41 AM
Subject: have u seen an idea even billGates shouldn't
Dear all,
I'm working on a select implementation for jython (in combination with
non-blocking sockets), and a set of unit tests for same.
I decided to run all of the non-blocking unit tests, both server and
client side, in the same thread; seems to be a reasonable thing to do.
After all,
Michael Foord wrote:
Are you going to try it ?
Guido van Rossum wrote:
-- Forwarded message --
may be there should be a virusAI that you set on the
internet.
Are you sure it hasn't already been tried? Maybe
all these viruses running around in the Windows
world aren't just
Alan Kennedy [EMAIL PROTECTED] wrote:
I'm working on a select implementation for jython (in combination with
non-blocking sockets), and a set of unit tests for same.
Great!
[snip]
But when I run the code on cpython, the code reports that both calls
would block, i.e. that neither side of the
Jay Parlar wrote:
I'm considering applying to be a student in this year's SoC, and the
AST code generation in particular looks interesting to me (listed
here: http://wiki.python.org/moin/CodingProjectIdeas/PythonCore).
I was wondering a few things:
1) Who would most likely mentor this
On 3/19/07, Michael Spencer [EMAIL PROTECTED] wrote:
Jay Parlar wrote:
I'm considering applying to be a student in this year's SoC, and the
AST code generation in particular looks interesting to me (listed
here: http://wiki.python.org/moin/CodingProjectIdeas/PythonCore).
I was wondering
Brett Cannon wrote:
On 3/19/07, Michael Spencer [EMAIL PROTECTED] wrote:
...
FWIW, I've already implemented bytecode generation from AST,
http://svn.brownspencer.com/pycompiler/branches/new_ast/
as I reported to this list previously.
Hi Alan.
Are you running on Windows or Unix? I just tested 2.4 - 2.6 on Linux
and all report:
Server socket: accept would not block
Client socket: write would not block
Which seems to be what you would expect unless I read it wrong.
I vaguely remember some issue about an empty hostname on
Write back and tell him that this is already happened, and this *is* the
future he's describing - in other words, the AI's have already
re-created the 21st century in a giant virtual simulation, and we're
living inside it.
Then ask if he wants to take the blue pill or the red pill.
Michael
On 19 Mar, 02:46 pm, [EMAIL PROTECTED] wrote:
As you see I'm trying to discourage you from working on such a
document; but I won't stop you and if there's general demand for it
and agreement I'll gladly review it when it's ready. (It's a bit
annoying to have to read long posts alluding to a
29 matches
Mail list logo
