>> Please never commit to python/trunk/Lib/lib2to3.
>> Instead, commit to sandbox/trunk/2to3, and merge
>> that using svnmerge.
>
> Could you explain that policy? Why isn't 2to3 maintained in the
> trunk but in the sandbox? Or maybe more general: Where can I find
> more information on the svn dire
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> On Tue, Jun 17, 2008 at 11:09 AM, Curt Hagenlocher
> <[EMAIL PROTECTED]> wrote:
>> On Tue, Jun 17, 2008 at 10:56 AM, Guido van Rossum
>> <[EMAIL PROTECTED]> wrote:
>>> On Tue, Jun 17, 2008 at 10:40 AM, Curt Hagenlocher
>>> <[EMAIL PROTECTED]> wrote
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Well, I'm going to try again tonight to release beta one for Python
2.6 and 3.0. I'm planning on starting the release at 6pm US/Eastern
or 2200 UTC.
Right now the Python 2.6 buildbots look pretty good. We have /one/
green buildbot for Python
On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Well, I'm going to try again tonight to release beta one for Python 2.6 and
> 3.0. I'm planning on starting the release at 6pm US/Eastern or 2200 UTC.
>
> Right now the Py
On Wed, Jun 18, 2008 at 7:54 AM, Jesse Noller <[EMAIL PROTECTED]> wrote:
> On Wed, Jun 18, 2008 at 7:45 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Well, I'm going to try again tonight to release beta one for Python 2.6 and
>> 3.0. I'm plan
Leap seconds? Leap seconds aren't supposed to exist when looking at
POSIX timestamps. They don't exist when I look at my watch either, and
that's what I expect from any time-keeping device except those for use
by astronomers.
On Wed, Jun 18, 2008 at 2:50 AM, Pete Forman
<[EMAIL PROTECTED]> wrote:
I gave my Windows buildbots a little bit of TLC last night. This little
chestnut in test_multiprocessing.py around line 1346 is causing my buildbots to
wedge more often than not:
def test_listener_client(self):
for family in self.connection.families:
l = self.connection.
Hello,
2008/6/18 Trent Nelson <[EMAIL PROTECTED]>:
> I gave my Windows buildbots a little bit of TLC last night. This little
> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
> to wedge more often than not:
>
>def test_listener_client(self):
>for family
On Wed, Jun 18, 2008 at 12:35 PM, Amaury Forgeot d'Arc
<[EMAIL PROTECTED]> wrote:
> Hello,
>
> 2008/6/18 Trent Nelson <[EMAIL PROTECTED]>:
>> I gave my Windows buildbots a little bit of TLC last night. This little
>> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
>>
Amaury Forgeot d'Arc gmail.com> writes:
> if family == 'AF_INET':
> -return ('localhost', 0)
> +return ('', 0)
> elif family == 'AF_UNIX':
> return tempfile.mktemp(prefix='listener-', dir=get_temp_dir())
> elif family == 'AF_PIPE':
Doesn't it have important
On Wed, 18 Jun 2008 18:35:26 +0200, Amaury Forgeot d'Arc <[EMAIL PROTECTED]>
wrote:
[snip]
I just found the cause of the problem ten minutes ago:
It seems that when a socket listens on the address "127.0.0.1" or
"localhost", another process cannot connect to it using the machine's
name (even fr
Hello,
2008/6/18 Jean-Paul Calderone <[EMAIL PROTECTED]>:
> On Wed, 18 Jun 2008 18:35:26 +0200, Amaury Forgeot d'Arc
> <[EMAIL PROTECTED]> wrote:
>>
>> [snip]
>>
>> I just found the cause of the problem ten minutes ago:
>> It seems that when a socket listens on the address "127.0.0.1" or
>> "local
Hi,
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
Georg
__
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> Leap seconds? Leap seconds aren't supposed to exist when looking
> at POSIX timestamps. They don't exist when I look at my watch
> either, and that's what I expect from any time-keeping device
> except those for use by astronomers.
That's pre
Amaury Forgeot d'Arc gmail.com> writes:
>
> OK, I am not a tcp expert.
> How about the following patch?
> It seems to me that it is wrong for the server to lie about the
> address it listens to.
Maybe I'm missing something but... if the client part defaults to connecting
to "localhost" in TCP mo
On Wed, Jun 18, 2008 at 1:51 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Amaury Forgeot d'Arc gmail.com> writes:
>>
>> OK, I am not a tcp expert.
>> How about the following patch?
>> It seems to me that it is wrong for the server to lie about the
>> address it listens to.
>
> Maybe I'm missing
On Wed, Jun 18, 2008 at 12:20 PM, Trent Nelson <[EMAIL PROTECTED]> wrote:
> I gave my Windows buildbots a little bit of TLC last night. This little
> chestnut in test_multiprocessing.py around line 1346 is causing my buildbots
> to wedge more often than not:
>
>def test_listener_client(self)
Hi,
> Maciej Fijalkowski did an opcode analysis for PyPy,
> it also shows the relative frequency of opcodes following a
> specifc one:
>
> http://codespeak.net/svn/user/fijal/opcodes.txt
Nice, but we have to be careful here: what is the tested workload?
For example, I find it hard to believe th
Jesse Noller gmail.com> writes:
>
> The server component *is* listening to localhost by default. The
> client in the code I pasted has the server's .address attribute passed
> into it to tell the client where to connect to.
So I take it that the .address attribute is different from "localhost",
On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
> Jesse Noller gmail.com> writes:
>>
>> The server component *is* listening to localhost by default. The
>> client in the code I pasted has the server's .address attribute passed
>> into it to tell the client where to conne
Antoine Pitrou schrieb:
Hi,
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Nice, but we have to be careful here: what is the tested workload?
For example, I find it h
Georg Brandl gmx.net> writes:
> Agreed; is there a way for a JUMP to end up without popping the top
> after jumping? It would have to do a DUP first then.
For example:
>>> def f(x, y):
... return x and y
...
>>> import dis
>>> dis.dis(f)
2 0 LOAD_FAST0 (x)
Georg Brandl wrote:
> Antoine Pitrou schrieb:
>>> Maciej Fijalkowski did an opcode analysis for PyPy,
>>> it also shows the relative frequency of opcodes following a
>>> specifc one:
>>>
>>> http://codespeak.net/svn/user/fijal/opcodes.txt
>>
>> Nice, but we have to be careful here: what is the test
2008/6/18 Jesse Noller <[EMAIL PROTECTED]>:
> On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
>> Jesse Noller gmail.com> writes:
>>>
>>> The server component *is* listening to localhost by default. The
>>> client in the code I pasted has the server's .address attribute p
Amaury Forgeot d'Arc wrote:
2008/6/18 Jesse Noller <[EMAIL PROTECTED]>:
On Wed, Jun 18, 2008 at 2:09 PM, Antoine Pitrou <[EMAIL PROTECTED]> wrote:
Jesse Noller gmail.com> writes:
The server component *is* listening to localhost by default. The
client in the code I pasted has the server's .add
Maciej Fijalkowski did an opcode analysis for PyPy,
it also shows the relative frequency of opcodes following a
specifc one:
http://codespeak.net/svn/user/fijal/opcodes.txt
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
This particular one m
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
There are enough green buildbots and I think all the showstoppers are
resolvable, so I'm going ahead and releasing beta 1 tonight. Please
refrain from any commits unless I ask you to check something in.
We've got a major thunderstorm blowing th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Jun 18, 2008, at 7:54 AM, Jesse Noller wrote:
Please let me know about 3088 - I've disabled the more unreliable
tests until I can give the entire suite some TLC. I'm still trying to
work around/identify the "Function not Implemented" error in iss
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On behalf of the Python development team and the Python community, I
am happy to announce the first beta releases of Python 2.6 and Python
3.0.
Please note that these are beta releases, and as such are not suitable
for production environments.
Very very, interesting. Thanks. :)
Somebody thinks that Python is unsuitable to implement a DSL: IMO your example
prove the contrary. :D
Cesare
In data 16 giugno 2008 alle ore 01:12:46, Alex Martelli <[EMAIL PROTECTED]> ha
scritto:
> +1 on updating the FAQ. Maybe we could even have it notice
> The server component *is* listening to localhost by default. The
> client in the code I pasted has the server's .address attribute passed
> into it to tell the client where to connect to.
Interestingly enough, I can't coerce test_multiprocessing.test_listener_client
to wedge on my XP laptop. W
On Wed, Jun 18, 2008 at 9:58 PM, Cesare Di Mauro <[EMAIL PROTECTED]> wrote:
> Very very, interesting. Thanks. :)
>
> Somebody thinks that Python is unsuitable to implement a DSL: IMO your
> example prove the contrary. :D
As long as you're willing to do the "DSL" within the strictures of
Python sy
> I just found the cause of the problem ten minutes ago:
> It seems that when a socket listens on the address "127.0.0.1" or
> "localhost", another process cannot connect to it using the machine's
> name (even from the same machine).
> The best seems to listen with the empty address "".
That doesn
> Well, on my win2k machine getfqdn('127.0.0.1') returns the actual name
> of the machine. This is the name that was stored in server.address.
> Hence my patch that simply remove the call to getfqdn.
+1 to ditching getfqdn, following patch fixes the issue on my buildbot server:
Index: connection.
34 matches
Mail list logo
