Re: [Python-Dev] [Python-checkins] r64360 - python/trunk/Lib/lib2to3/refactor.py
>> 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 directory layout? It started off as a sandbox project, also with the intent of releasing it separately. At PyCon 2008, I restructured it introducing lib2to3, which I then copied into the trunk, and from there into the 3k branch. The official sources still remain in the sandbox: a) for historical reasons, because that's where the main 2to3 contributors commit to (who might not even have a trunk checkout, only a 2.5 installation and a 3.0 checkout) b) because the 2to3 sources contain a few files that don't really "belong" into the trunk (although a place for them could probably be found), such as find_pattern utility. c) to continue allowing stand-alone releases; IIUC, Collin Winter wants to change this package into a general Python rewriting library, which might be useful even in a 2.5 context. I don't think there can be much said about the layout of the repository: the top-level directory contains various projects (including python), and sandbox contains "stuff". Within the Python tree, there are really not that many exceptions to the rule "trunk is where all new features go", apart from the 3k branch, of course. One class of exceptions is libraries that need to stay backwards compatible, see PEP 291. The other class of exceptions is libraries whose official sources are outside trunk, namely (possibly incomplete): - lib2to3 - xml.etree, and Modules/_elementtree.c - bsddb (recently) - _multiprocessing ??? - Modules/zlib Those have special commit constraints, and the maintainer should be contacted if you don't know what the constraints are. A few other packages are also separately released but don't have such constraints: - ctypes - sqlite For these packages, the maintainers will pickup and changes themselves and merge them into whatever external repository they may use. Regards, Martin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
"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: There's no real urgency. The reason this came up is because I just implemented zlib, which automatically enabled the gzip unit tests. The gzip tests are failing because the current timestamp can't be written as a 32-bit value. >>> >>> Why is that? Is it because your epoch is different? If so, I would >>> much prefer the epoch to be 1970. (Maybe this is the resolution >>> you're seeking?) >> >> Yes! Except that I was hoping for something a little stronger, like >> "the epoch must be 1970" or "the epoch can be anything you want, but >> you're utterly retarded if you pick something other than 1970". But >> I'll definitely settle for "much prefer". :) > > I could go with the "utterly retarded" wording. :-) The POSIX (UNIX) rules for handling time are laid out clearly. Not everyone is happy with how leap seconds work but at least they can be dealt with by those who need to. Most people will use local time or UTC and other time scales are possible with a bit of effort. If you were to allow an epoch earlier than 1970 then ambiguity is more likely to sneak in. Another reason not to allow an epoch of 1900 is that Microsoft introduced a bug in its leap year algorithm in Excel. The better (less bad) way of using that epoch is to propagate that bug. According to the Pythonic way you should not have to look before you leap. ;-) +1 for strengthening the definition of epoch in the time module to 1970-01-01T00:00:00Z for all platforms. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Another run at beta one
-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 3.0. That's better than last week at least, but it would be great to get a few more. I know folks have been working hard at this, and I really appreciate it. I think we're looking fairly good on the release critical bugs. I'll clear 3089 and 3009 tonight, and check locally on 3088 over the day. If you're looking for a way to help out, see if you can turn any of the other 3.0 buildbots green. I will be hanging out on #python-dev all day, but ping my nick (barry) if you need my attention. Thanks, and let's get it done today! - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ 4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS gFmU86oZSFw= =SiNl -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Another run at beta one
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 Python 2.6 buildbots look pretty good. We have /one/ green > buildbot for Python 3.0. That's better than last week at least, but it > would be great to get a few more. I know folks have been working hard at > this, and I really appreciate it. > > I think we're looking fairly good on the release critical bugs. I'll clear > 3089 and 3009 tonight, and check locally on 3088 over the day. > > If you're looking for a way to help out, see if you can turn any of the > other 3.0 buildbots green. I will be hanging out on #python-dev all day, > but ping my nick (barry) if you need my attention. > > Thanks, and let's get it done today! > - -Barry > > -BEGIN PGP SIGNATURE- > Version: GnuPG v1.4.9 (Darwin) > > iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ > 4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM > BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS > gFmU86oZSFw= > =SiNl > -END PGP SIGNATURE- > ___ > Python-3000 mailing list > [EMAIL PROTECTED] > http://mail.python.org/mailman/listinfo/python-3000 > Unsubscribe: > http://mail.python.org/mailman/options/python-3000/jnoller%40gmail.com > 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 issue3111 - this happens to be failing the tests on a few of the linux boxes. I suspected it was due to a combination of chroot + lack of /dev/shm on some of the build bots, ergo a patch put in by Ben last night to skip the tests on machines lacking the device, but it doesn't seem to be skipping/the device exists. -jesse ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Another run at beta one
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 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 3.0. That's better than last week at least, but it >> would be great to get a few more. I know folks have been working hard at >> this, and I really appreciate it. >> >> I think we're looking fairly good on the release critical bugs. I'll clear >> 3089 and 3009 tonight, and check locally on 3088 over the day. >> >> If you're looking for a way to help out, see if you can turn any of the >> other 3.0 buildbots green. I will be hanging out on #python-dev all day, >> but ping my nick (barry) if you need my attention. >> >> Thanks, and let's get it done today! >> - -Barry >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1.4.9 (Darwin) >> >> iQCVAwUBSFj1bHEjvBPtnXfVAQLrvAP/ftfpN50HbeimRoK2WhX4RcuN9G81IfbJ >> 4+CXdjH7WLC/wwKvNp1Q6qc3vHWTqPgA7jF7yowU/a/3FretkzUPGNmtjoWvfQzM >> BL1ktG6fh298+KRJTSTXGeNSEzjwBg2GryyQJV5xmwsUMiwvrI4OE3w8O6eE5AkS >> gFmU86oZSFw= >> =SiNl >> -END PGP SIGNATURE- >> ___ >> Python-3000 mailing list >> [EMAIL PROTECTED] >> http://mail.python.org/mailman/listinfo/python-3000 >> Unsubscribe: >> http://mail.python.org/mailman/options/python-3000/jnoller%40gmail.com >> Update: Most of the trunk bots went green post r64375, so I merged the change over to py3k. The change aggressively skips the MP package tests if RLock instantiation throws an OSError. -jesse ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
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: > "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: > > There's no real urgency. The reason this came up is because I > just implemented zlib, which automatically enabled the gzip unit > tests. The gzip tests are failing because the current timestamp > can't be written as a 32-bit value. Why is that? Is it because your epoch is different? If so, I would much prefer the epoch to be 1970. (Maybe this is the resolution you're seeking?) >>> >>> Yes! Except that I was hoping for something a little stronger, like >>> "the epoch must be 1970" or "the epoch can be anything you want, but >>> you're utterly retarded if you pick something other than 1970". But >>> I'll definitely settle for "much prefer". :) >> > > I could go with the "utterly retarded" wording. :-) > > The POSIX (UNIX) rules for handling time are laid out clearly. Not > everyone is happy with how leap seconds work but at least they can be > dealt with by those who need to. Most people will use local time or > UTC and other time scales are possible with a bit of effort. If you > were to allow an epoch earlier than 1970 then ambiguity is more likely > to sneak in. > > Another reason not to allow an epoch of 1900 is that Microsoft > introduced a bug in its leap year algorithm in Excel. The better > (less bad) way of using that epoch is to propagate that bug. > > According to the Pythonic way you should not have to look before you > leap. ;-) > > +1 for strengthening the definition of epoch in the time module to > 1970-01-01T00:00:00Z for all platforms. > -- > Pete Forman-./\.- Disclaimer: This post is originated > WesternGeco -./\.- by myself and does not represent > [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or > http://petef.22web.net -./\.- WesternGeco. > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_multiprocessing: test_listener_client flakiness
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.Listener(family=family)
p = self.Process(target=self._test, args=(l.address,))
p.set_daemon(True)
p.start()
conn = l.accept()
self.assertEqual(conn.recv(), 'hello')
p.join()
l.close()
The wedging will be a result of that accept() call. Not knowing anything about
the module or the test suite, I can only assume that there's a race condition
introduced between when the subprocess attempts to connect to the listener,
versus when the l.accept() call is actually entered. (On the basis that a race
condition would explain why sometimes it wedges and sometimes it doesn't.)
Just FYI, the error in the buildbot log
(http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/810/step-test/0)
when this occurs is as follows:
test_multiprocessing
command timed out: 1200 seconds without output
SIGKILL failed to kill process
using fake rc=-1
program finished with exit code -1
remoteFailed: [Failure instance: Traceback from remote host -- Traceback (most
recent call last):
Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
]
(The fact it can't be killed cleanly is a bug in Twisted's
signalProcess('KILL') method, which doesn't work against Python processes that
have entered accept() calls on Windows (which present the 'wedged' behaviour
and have to be forcibly killed with OpenProcess/TerminateProcess).)
Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
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 in self.connection.families:
>l = self.connection.Listener(family=family)
>p = self.Process(target=self._test, args=(l.address,))
>p.set_daemon(True)
>p.start()
>conn = l.accept()
>self.assertEqual(conn.recv(), 'hello')
>p.join()
>l.close()
>
> The wedging will be a result of that accept() call. Not knowing anything
> about the module or the test suite, I can only assume that there's a race
> condition introduced between when the subprocess attempts to connect to the
> listener, versus when the l.accept() call is actually entered. (On the basis
> that a race condition would explain why sometimes it wedges and sometimes it
> doesn't.)
>
> Just FYI, the error in the buildbot log
> (http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/810/step-test/0)
> when this occurs is as follows:
>
> test_multiprocessing
>
> command timed out: 1200 seconds without output
> SIGKILL failed to kill process
> using fake rc=-1
> program finished with exit code -1
> remoteFailed: [Failure instance: Traceback from remote host -- Traceback
> (most recent call last):
> Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
> ]
>
> (The fact it can't be killed cleanly is a bug in Twisted's
> signalProcess('KILL') method, which doesn't work against Python processes
> that have entered accept() calls on Windows (which present the 'wedged'
> behaviour and have to be forcibly killed with OpenProcess/TerminateProcess).)
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 "".
Index: Lib/multiprocessing/connection.py
===
--- Lib/multiprocessing/connection.py (revision 64374)
+++ Lib/multiprocessing/connection.py (working copy)
@@ -49,7 +49,7 @@
Return an arbitrary free address for the given family
'''
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':
And the test started to pass for me.
Can you please check this in if it works; I don't have svn access for
the moment.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
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
>> to wedge more often than not:
>>
>>def test_listener_client(self):
>>for family in self.connection.families:
>>l = self.connection.Listener(family=family)
>>p = self.Process(target=self._test, args=(l.address,))
>>p.set_daemon(True)
>>p.start()
>>conn = l.accept()
>>self.assertEqual(conn.recv(), 'hello')
>>p.join()
>>l.close()
>>
>> The wedging will be a result of that accept() call. Not knowing anything
>> about the module or the test suite, I can only assume that there's a race
>> condition introduced between when the subprocess attempts to connect to the
>> listener, versus when the l.accept() call is actually entered. (On the
>> basis that a race condition would explain why sometimes it wedges and
>> sometimes it doesn't.)
>>
>> Just FYI, the error in the buildbot log
>> (http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/810/step-test/0)
>> when this occurs is as follows:
>>
>> test_multiprocessing
>>
>> command timed out: 1200 seconds without output
>> SIGKILL failed to kill process
>> using fake rc=-1
>> program finished with exit code -1
>> remoteFailed: [Failure instance: Traceback from remote host -- Traceback
>> (most recent call last):
>> Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
>> ]
>>
>> (The fact it can't be killed cleanly is a bug in Twisted's
>> signalProcess('KILL') method, which doesn't work against Python processes
>> that have entered accept() calls on Windows (which present the 'wedged'
>> behaviour and have to be forcibly killed with OpenProcess/TerminateProcess).)
>
> 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 "".
>
> Index: Lib/multiprocessing/connection.py
> ===
> --- Lib/multiprocessing/connection.py (revision 64374)
> +++ Lib/multiprocessing/connection.py (working copy)
> @@ -49,7 +49,7 @@
> Return an arbitrary free address for the given family
> '''
> 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':
>
> And the test started to pass for me.
> Can you please check this in if it works; I don't have svn access for
> the moment.
>
> --
> Amaury Forgeot d'Arc
I am testing the patch locally now.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener _client flakiness
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 security implications?
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
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 from the same machine). That's because when you try to connect to A:B you won't connect to a server listening on X:B - somewhat by design. Changing the test to listen on A:B and X:B might fix it, but so would changing it to connect to the same address it listens to. The best seems to listen with the empty address "". This will cause it to listen on all available interfaces, including public ones. It's rather unlikely that someone from the internet will connect to the port while the test suite is running and use it to do terrible things to you, but it's not /impossible/. I'd suggest changing the client to connect to "127.0.0.1" or "localhost", instead. Jean-Paul ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
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 >> "localhost", another process cannot connect to it using the machine's >> name (even from the same machine). > > That's because when you try to connect to A:B you won't connect to a > server listening on X:B - somewhat by design. Changing the test to > listen on A:B and X:B might fix it, but so would changing it to connect > to the same address it listens to. > >> The best seems to listen with the empty address "". > > This will cause it to listen on all available interfaces, including > public ones. It's rather unlikely that someone from the internet > will connect to the port while the test suite is running and use it > to do terrible things to you, but it's not /impossible/. > > I'd suggest changing the client to connect to "127.0.0.1" or "localhost", > instead. 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. Index: ../../Lib/multiprocessing/connection.py === --- ../../Lib/multiprocessing/connection.py (revision 64378) +++ ../../Lib/multiprocessing/connection.py (working copy) @@ -216,8 +216,6 @@ self._socket.bind(address) self._socket.listen(backlog) address = self._socket.getsockname() -if type(address) is tuple: -address = (socket.getfqdn(address[0]),) + address[1:] self._address = address self._family = family self._last_accepted = None -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Opcode frequency
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 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Epoch and Platform
"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 pretty much what I was saying. The POSIX rule for Seconds Since the Epoch explicitly excludes leap seconds. Astronomers and the like then know what further adjustments are required for the their needs. The rest of us get along with the assumption that there are 86400 seconds in every day. -- Pete Forman-./\.- Disclaimer: This post is originated WesternGeco -./\.- by myself and does not represent [EMAIL PROTECTED]-./\.- the opinion of Schlumberger or http://petef.22web.net -./\.- WesternGeco. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener _client flakiness
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 mode, why doesn't the server part also default to listening on "localhost" in TCP mode? Having different address detection algorithms on both ends sounds like a recipe for bugs like this. In any case, perhaps one should ask guidance to the original author before making important changes like this one. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
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 something but... if the client part defaults to connecting > to "localhost" in TCP mode, why doesn't the server part also default to > listening on "localhost" in TCP mode? Having different address detection > algorithms on both ends sounds like a recipe for bugs like this. > > In any case, perhaps one should ask guidance to the original author before > making important changes like this one. 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. -jesse ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
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):
>for family in self.connection.families:
>l = self.connection.Listener(family=family)
>p = self.Process(target=self._test, args=(l.address,))
>p.set_daemon(True)
>p.start()
>conn = l.accept()
>self.assertEqual(conn.recv(), 'hello')
>p.join()
>l.close()
>
> The wedging will be a result of that accept() call. Not knowing anything
> about the module or the test suite, I can only assume that there's a race
> condition introduced between when the subprocess attempts to connect to the
> listener, versus when the l.accept() call is actually entered. (On the basis
> that a race condition would explain why sometimes it wedges and sometimes it
> doesn't.)
>
> Just FYI, the error in the buildbot log
> (http://www.python.org/dev/buildbot/all/x86%20W2k8%20trunk/builds/810/step-test/0)
> when this occurs is as follows:
>
> test_multiprocessing
>
> command timed out: 1200 seconds without output
> SIGKILL failed to kill process
> using fake rc=-1
> program finished with exit code -1
> remoteFailed: [Failure instance: Traceback from remote host -- Traceback
> (most recent call last):
> Failure: buildbot.slave.commands.TimeoutError: SIGKILL failed to kill process
> ]
>
> (The fact it can't be killed cleanly is a bug in Twisted's
> signalProcess('KILL') method, which doesn't work against Python processes
> that have entered accept() calls on Windows (which present the 'wedged'
> behaviour and have to be forcibly killed with OpenProcess/TerminateProcess).)
>
>Trent.
> ___
> Python-Dev mailing list
> [email protected]
> http://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> http://mail.python.org/mailman/options/python-dev/jnoller%40gmail.com
>
Trent, I commented out the test causing the issue for now (the entire
suite is being revisited post beta-1)
See r64378
-jesse
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Opcode frequency
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 that CALL_FUNCTION_VAR_KW would
always (99%) be followed by STORE_FAST.
I'm not even sure we're talking about the same VM/compiler. What are
CALL_LIKELY_BUILTIN and LOOKUP_METHOD? :-)
> Might it make sense to add more PREDICT()ions based
> on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
This particular one sounds fine, yes.
Another approach is to create opcodes which better reflect actual usage.
For example part of the following patch (*) was to create opcodes fusing
JUMP_IF_{TRUE,FALSE} and POP_TOP. This is because in most cases, you want
to pop the comparison result regardless of its value (true or false), which
nowadays produces the following kind of code:
JUMP_IF_FALSE
POP_TOP
[... do stuff and then ...]
JUMP_FORWARD
branch_for_false:
POP_TOP
branch_for_false_after_pop_top:
[etc.]
With a JUMP_IF_FALSE which also pops the pop of the stack, this gives:
JUMP_IF_FALSE
[... do stuff and then ...]
branch_for_false:
[etc.]
Prediction doesn't help you in this case.
(*) http://bugs.python.org/issue2459
Regards
Antoine.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener _client flakiness
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", but why? Is there any point in trying to be clever here? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
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 connect to. > > So I take it that the .address attribute is different from "localhost", > but why? Is there any point in trying to be clever here? No, it is *not* different than localhost - it *is* localhost as that is the object.address of the server. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Opcode frequency
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 hard to believe that CALL_FUNCTION_VAR_KW would
always (99%) be followed by STORE_FAST.
I'm sorry, I should have given a reference to the original message:
http://codespeak.net/pipermail/pypy-dev/2008q2/004666.html
I'm not even sure we're talking about the same VM/compiler. What are
CALL_LIKELY_BUILTIN and LOOKUP_METHOD? :-)
He used the PyPy compiler, of course.
Might it make sense to add more PREDICT()ions based
on this, e.g. for BUILD_SLICE -> BINARY_SUBSCR?
This particular one sounds fine, yes.
Another approach is to create opcodes which better reflect actual usage.
For example part of the following patch (*) was to create opcodes fusing
JUMP_IF_{TRUE,FALSE} and POP_TOP. This is because in most cases, you want
to pop the comparison result regardless of its value (true or false), which
nowadays produces the following kind of code:
JUMP_IF_FALSE
POP_TOP
[... do stuff and then ...]
JUMP_FORWARD
branch_for_false:
POP_TOP
branch_for_false_after_pop_top:
[etc.]
With a JUMP_IF_FALSE which also pops the pop of the stack, this gives:
JUMP_IF_FALSE
[... do stuff and then ...]
branch_for_false:
[etc.]
Prediction doesn't help you in this case.
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.
Georg
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Opcode frequency
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) 3 JUMP_IF_FALSE4 (to 10) 6 POP_TOP 7 LOAD_FAST1 (y) >> 10 RETURN_VALUE ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Opcode frequency
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 tested workload? >> For example, I find it hard to believe that CALL_FUNCTION_VAR_KW would >> always (99%) be followed by STORE_FAST. > > I'm sorry, I should have given a reference to the original message: > http://codespeak.net/pipermail/pypy-dev/2008q2/004666.html > >> I'm not even sure we're talking about the same VM/compiler. What are >> CALL_LIKELY_BUILTIN and LOOKUP_METHOD? :-) > > He used the PyPy compiler, of course. Just for the reference, PyPy uses exactly CPython's opcodes. Then there are some completely optional optimizations which add opcodes (like CALL_LIKELY_BUILTIN and LOOKUP_METHOD) that can be enabled at compile time. Cheers, Carl Friedrich Bolz ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
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 passed
>>> into it to tell the client where to connect to.
>>
>> So I take it that the .address attribute is different from "localhost",
>> but why? Is there any point in trying to be clever here?
>
> No, it is *not* different than localhost - it *is* localhost as that
> is the object.address of the server.
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.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
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 .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",
but why? Is there any point in trying to be clever here?
No, it is *not* different than localhost - it *is* localhost as that
is the object.address of the server.
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.
Point of interest: I was involved in developing an application where we
gave up on trying to persuade getfqdn() to return reliable results on
Windows machines - regardless of which local network interface you use
to do the lookup, Windows 2k3 is likely to return an answer of
'computername.computerdomain' without bothering to consult the local DNS
server (annoyingly, it used to do this right on previous Windows versions).
So I'm inclined to consider any code which expects a useful answer out
of getfqdn() to be non-portable at best and outright broken at worst. We
worked around the problem by only doing forward DNS lookups and always
working with addresses in the IP domain.
Cheers,
Nick.
--
Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia
---
http://www.boredomandlaziness.org
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Opcode frequency
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 might be okay. What code generates it? Are there other possible successors to BUILD_SLICE? What code generates those? There were lots of other opcode pairings that were previously studied and rejected. You're going over well traveled ground. Also, opcode analysis is a somewhat hazardous undertaking. Dynamic analysis takes into account which codes tend to occur more often inside loops but it is *very* sensitive to who wrote the app and their coding style. These results always have to be taken with a grain of salt. Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] releasing betas tonight
-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 through right now, but when it clears I'll be on irc.freenode.net #python-dev. I'll start making the release as soon as I get on, and feel free to ask any questions. - -B -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFmca3EjvBPtnXfVAQICfAP8DHTOoQap9MnXJrUY0a3rurgRerMDNxSe 1dmOlhSVGmbQncPSZWP5x0xf1gC5QOCUAofGYfh2xY5ng6BbCQlzMX3Iogy1KvHQ Fb1HQ4EPUO5PGEQipgvHlkN38OFDqevoyvaRBIOGOppIVjL0v8P66eXNkkLq4BvT RztyojPrhxE= =jZ8g -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Another run at beta one
-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 issue3111 - this happens to be failing the tests on a few of the linux boxes. I suspected it was due to a combination of chroot + lack of /dev/shm on some of the build bots, ergo a patch put in by Ben last night to skip the tests on machines lacking the device, but it doesn't seem to be skipping/the device exists. We're going to have to deal with 3088 after the beta release. I'm not going to let it hold us up this time. I think we're going to have a tougher time than we think getting the 3.0 release stabilized for final though. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFmwDXEjvBPtnXfVAQIFjAP+LGwB1Z3eBLaF/ZEez5TgkpMWdhHZwmWA zefJnlORHRN4TiawGDNkGdbs+B3O0An8vuCkXTnM97sdKqXYIUZ+0C8qdU5g9OaA UlX2Wagl1UTC8HHMhmPVlo7AnIzcR0mUOlu7T9SgtjKeEbcrSB4vCT9Cqy7rH7r8 jsHzlmzjswI= =r2K6 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] RELEASED Python 2.6b1 and 3.0b1
-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. We continue to strive for a high degree of quality, and these releases are intended to freeze the feature set for Python 2.6 and 3.0. From now until the planned final releases in September 2008, we will be fixing known problems and stabilizing these new Python versions. You can help by downloading and testing them, providing feedback and hopefully helping to fix bugs. You can also use these releases to determine how changes in 2.6 and 3.0 might impact you. If you find things broken or incorrect, please submit bug reports at http://bugs.python.org For more information and downloadable distributions, see the Python 2.6 website: http://www.python.org/download/releases/2.6/ and the Python 3.0 web site: http://www.python.org/download/releases/3.0/ See PEP 361 for release schedule details: http://www.python.org/dev/peps/pep-0361/ Enjoy, - -Barry Barry Warsaw [EMAIL PROTECTED] Python 2.6/3.0 Release Manager (on behalf of the entire python-dev team) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFnIbnEjvBPtnXfVAQKCMgP+L9Vpk9vQgYw01KShtF9HyvCKE0guSy86 0Q/IRbkXGahXg910D4nVLY9NORaOSq/VP8Kx+fOU8egUDHvVF9MuKkY75ZHYoixR mieeV7BIpYHYKYhva48FVoF4p0+sUeNvfeOAP0nnV5Pi2icGqCpzizfSHZloXJjc Y8M4F5vVrOM= =Oo15 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a "with" statement?
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 that a > read-only version of the desired semantic for 'with' is easily hacked > with the *current* semantic of 'with'...: > > @contextlib.contextmanager > def readonly(anobj): > caller_globals = sys._getframe(2).f_globals > saved_globals = caller_globals.copy() > caller_globals.update((n, getattr(anobj, n)) for n in dir(anobj)) > yield > caller_globals.clear() > caller_globals.update(saved_globals) > > and then, of course, > > with readonly(someobj): ... > > (local variables take precedence, and in particular all assignments > define local variables, as usual -- but you can say e.g. 'zz' to mean > 'someobj.zz', if you're sufficiently keen on giving up the advantage > of having many well-separated namespaces;-). > > > Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
> 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. When I run it on my Windows Server 2008 box (same box the buildbots run on), it wedges every time. So, I suspect this isn't actually a race like I first thought, but something quirky with 2008. Will dig around for a bit longer and see what I can find... Trent. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python FAQ: Why doesn't Python have a "with" statement?
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 syntax, it's OK - not quite as flexible as LISP or Scheme or even Ruby, but better than most;-). I did design and implement "DSL"s in Python (mostly specialized class trees with suitable metaclasses, decorators &c) in many jobs in my recent past, I'll admit -- it never feels as free-flowing as Scheme did back when I used THAT, but, close enough to make my jobs successful!-) Alex ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing: test_listener_client flakiness
> 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't seem right. If that were the case, none of the hundreds of
network-oriented tests would work either. These all bind against ('localhost',
0) by default which seems to Do The Right Thing on all the platforms we have
buildbots for.
Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
> 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.py
===
--- connection.py (revision 64369)
+++ connection.py (working copy)
@@ -215,10 +215,7 @@
self._socket = socket.socket(getattr(socket, family))
self._socket.bind(address)
self._socket.listen(backlog)
-address = self._socket.getsockname()
-if type(address) is tuple:
-address = (socket.getfqdn(address[0]),) + address[1:]
-self._address = address
+self._address = self._socket.getsockname()
self._family = family
self._last_accepted = None
Trent.
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
