On Mon, Mar 19, 2007 at 12:20:59PM +1200, Greg Ewing wrote:
> Damien Miller wrote:
>
> > That annoyed me too, so I submitted a patch[1] that was recently
> > committed.
>
> That looks good. Seems to me it should really be the
> default behaviour, but I suppose that would break
> code that was rel
There are several failures with both the trunk and 2.5 branch. I have
fixed one problem that allows the tests to run on Windows. That was
fixed by reverting 54407 on the trunk. It still needs to be reverted
on the 2.5 branch. You can go back in the buildbot logs to find out
more about the probl
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 docum
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 Foo
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 Wind
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.
>> http://mail.python.org/pipermail/python-dev/2
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 w
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 th
"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
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 a
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, avoiding
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'
-- 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 thou
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
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
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) W
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 worked
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
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, w
> 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 someth
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 alr
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 fo
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 a
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 the
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
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),
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
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 ela
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
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 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 t
31 matches
Mail list logo
