Re: [Python-Dev] [Python-3000] RELEASED Python 2.6b1 and 3.0b1
On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote: > -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. Any ETA for Windows builds? The web pages still point to the alphas. (I'd like to see the Windows builds more closely integrated with the releases now we're in beta stage...) 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] [Python-3000] RELEASED Python 2.6b1 and 3.0b1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jun 19, 2008, at 4:43 AM, Paul Moore wrote: On 19/06/2008, Barry Warsaw <[EMAIL PROTECTED]> wrote: -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. Any ETA for Windows builds? The web pages still point to the alphas. (I'd like to see the Windows builds more closely integrated with the releases now we're in beta stage...) Martin usually fills these in pretty quickly. I think the current situation works fine for the betas but we'll make sure the final release (and candidates) are better coordinated. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSFpIpnEjvBPtnXfVAQJyWQP9FSH8Ipg93UDM3nmH3UtN+i61YGsQPd0O ypHlnz4yHpxeRkJm1zkppHHI0hKMou6JOeUf05QCnPzrAdsG/mkuv5aoBrBt3dDd UncHLoQOvXEhGrrPzexmHKv3ehxUXPQOzkiWBWVv9e69GYH4e4HcqV6s2Ya2733T zC/EyOgkyMg= =5wM5 -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?
On Wed, Jun 18, 2008 at 10:55:32PM -0700, Alex Martelli wrote:
-> 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!-)
It's pretty easy to put a simple syntax remapper around Python, too;
this is what twill does. So, for example, this:
--
setlocal username
setlocal password
go http://www.slashdot.org/
formvalue 1 unickname $username
formvalue 1 upasswd $password
submit
code 200 # make sure form submission is correct!
--
translates very directly to
---
setlocal('username', '...')
setlocal('password', '...')
go('http://www.slashdot.org/')
formvalue('1', 'unickname', username)
formvalue('1', 'upasswd', password)
submit()
code('200')
---
which is DSL-ish enough for me...
More generally, I've never understood why some people insist that
certain features make Ruby better for DSLs -- are code blocks really
that important to DSLs? Or is it just the lack of parens??
--titus
--
C. Titus Brown, [EMAIL PROTECTED]
___
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
Thanks Trent, I'll apply the diff and run the tests in a tight loop
after re-enabling the client listener tests. I appreciate you tracking
this down
On Thu, Jun 19, 2008 at 2:07 AM, Trent Nelson <[EMAIL PROTECTED]> wrote:
>> 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
Re: [Python-Dev] test_multiprocessing:test_listener_client flakiness
This is a common problem. Binding to '127.0.0.1' will bind to *only*
that address; binding to "" will bind to *all* addresses the machine
is known by. If the client uses a different way of getting the
address than the literal '127.0.0.1' (like a call to getfqdn(), which
has pretty indeterminate results), you should use the "" form when
calling bind.
If you know you want to talk to '127.0.0.1', just use the tuple
('127.0.0.1', ) as the address.
Bill
> > 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/janssen%40parc.com
___
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 Thu, Jun 19, 2008 at 4:54 AM, C. Titus Brown <[EMAIL PROTECTED]> wrote: > > More generally, I've never understood why some people insist that > certain features make Ruby better for DSLs -- are code blocks really > that important to DSLs? Or is it just the lack of parens?? Code blocks let Ruby-based DSLs "do" flow control, while the lack of parens make ordinary method names look like keywords. These things are a mixed bag -- on the one hand, they can certainly make the resulting DSL a lot easier to read. On the other, they seem to encourage a lot of over-the-top cleverness in terms of creating "fluent interfaces". I fail to see much value in being able to write code that says "7.seconds.ago". -- Curt Hagenlocher [EMAIL PROTECTED] ___ 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?
At 04:54 AM 6/19/2008 -0700, C. Titus Brown wrote:
More generally, I've never understood why some people insist that
certain features make Ruby better for DSLs -- are code blocks really
that important to DSLs? Or is it just the lack of parens??
Comparison to JavaScript suggests that it's the blocks that make the
difference. Even the fact that you have to spell your blocks with
"function(){...}" doesn't stop you from making a usable DSL, it's
just not always as pretty as you'd like.
The lack of parens and simpler syntax for blocks in Ruby just makes
it easier to make *nice-looking* DSLs.
___
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
On Thu, Jun 19, 2008 at 1:03 AM, Raymond Hettinger <[EMAIL PROTECTED]> wrote: >> 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/fijall%40gmail.com > I think I should mention the code it comes from - it's pypy's translation toolchain and no, it's not trying to provide any data on "standard" python usage. For example CALL_LIKELY_BUILTIN comes from isinstance calls, which is not something completely natural to be called that often. It of course depends on coding style, this is our coding style (ie pypy team). ___ 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-checkins] r64407 - python/trunk/Doc/library/multiprocessing.rst
On Thu, Jun 19, 2008 at 03:04:11PM -0500, Benjamin Peterson wrote: > I don't think the whole introduction had to go. I think it helped give > some idea of how multiprocessing works before jumping straight to the > API reference. I don't think overview material like that should be buried inside the documentation for one particular module; it should go in a chapter introduction. My plan is to move multiprocessing from the 'Optional OS Services' chapter to the 'Interprocess Communication' chapter, and then expand the introduction of the chapter to discuss the GIL and related issues. Presumably it was put in the 'Optional OS Services' chapter because that's where the threading and thread modules are. --amk ___ 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-checkins] r64407 - python/trunk/Doc/library/multiprocessing.rst
On Thu, Jun 19, 2008 at 3:30 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > My plan is to move multiprocessing from the 'Optional OS Services' > chapter to the 'Interprocess Communication' chapter, and then expand > the introduction of the chapter to discuss the GIL and related issues. > Presumably it was put in the 'Optional OS Services' chapter because > that's where the threading and thread modules are. Ok. Fair enough. Thanks for explaining. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1." ___ 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-checkins] r64407 - python/trunk/Doc/library/multiprocessing.rst
Where would that chapter end up (source-wise) I think a few of us might have additional things to add ;) On Thu, Jun 19, 2008 at 4:30 PM, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Thu, Jun 19, 2008 at 03:04:11PM -0500, Benjamin Peterson wrote: >> I don't think the whole introduction had to go. I think it helped give >> some idea of how multiprocessing works before jumping straight to the >> API reference. > > I don't think overview material like that should be buried inside the > documentation for one particular module; it should go in a chapter > introduction. > > My plan is to move multiprocessing from the 'Optional OS Services' > chapter to the 'Interprocess Communication' chapter, and then expand > the introduction of the chapter to discuss the GIL and related issues. > Presumably it was put in the 'Optional OS Services' chapter because > that's where the threading and thread modules are. > > --amk > ___ > 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 > ___ 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] C API for gc.enable() and gc.disable()
On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti > <[EMAIL PROTECTED]> wrote: >> Would anyone mind if I did add a public C API for gc.disable() and >> gc.enable()? I would like to use it as an optimization for the pickle >> module (I found out that I get a good 2x speedup just by disabling the >> GC while loading large pickles). Of course, I could simply import the >> gc module and call the functions there, but that seems overkill to me. >> I included the patch below for review. > > I'd rather see it fixed. It behaves quadratically if you load enough > to trigger full collection a few times. > Do you have any idea how this behavior could be fixed? I am not a GC expert, but I could try to fix this. -- Alexandre ___ 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] C API for gc.enable() and gc.disable()
On Thu, Jun 19, 2008 at 3:23 PM, Alexandre Vassalotti <[EMAIL PROTECTED]> wrote: > On Sun, Jun 1, 2008 at 12:28 AM, Adam Olsen <[EMAIL PROTECTED]> wrote: >> On Sat, May 31, 2008 at 10:11 PM, Alexandre Vassalotti >> <[EMAIL PROTECTED]> wrote: >>> Would anyone mind if I did add a public C API for gc.disable() and >>> gc.enable()? I would like to use it as an optimization for the pickle >>> module (I found out that I get a good 2x speedup just by disabling the >>> GC while loading large pickles). Of course, I could simply import the >>> gc module and call the functions there, but that seems overkill to me. >>> I included the patch below for review. >> >> I'd rather see it fixed. It behaves quadratically if you load enough >> to trigger full collection a few times. >> > > Do you have any idea how this behavior could be fixed? I am not a GC > expert, but I could try to fix this. Not sure. For long-running programs we actually want a quadratic cost, but spread out over a long period of time. It's the bursts of allocation that shouldn't be quadratic. So maybe balance it by the total number of allocations that have happened. If the total number of allocations is less than 10 times the allocations that weren't promptly deleted, assume it's a burst. If it's more than 10 times, assume it's over a long period. -- Adam Olsen, aka Rhamphoryncus ___ 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] Status of Issue 2331 - Backport parameter annotations
Hi, I am curious if there is any news on this issue. My understanding is that since this is a new feature, nothing will be committed until after 2.6 comes out, but it would be *really nice* if I could use annotations in 2.x. [warning - mini rant] Reason is, I am using 3.0a for now for this project, but I am sorry to say that using parentheses for raising exceptions drives me up the wall, and I don't like using them for the former print statement either. I suspect this is partly due to the fact that I'm using 2.5 for work, so I don't have the option to mentally "switch over" to the Python 3 way. /rant Does anyone have an annotations patch floating around against the trunk / 2.6b, or failing that, does anyone have opinions on what my chances are / things to look out for if I fiddle around with the annotations patch from the py3k branch? (My understanding is that this is revision 53170). Cheers, David ___ 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] Status of Issue 2331 - Backport parameter annotations
On Thu, Jun 19, 2008 at 3:59 PM, David Pokorny <[EMAIL PROTECTED]> wrote: > I am curious if there is any news on this issue. My understanding is > that since this is a new feature, nothing will be committed until > after 2.6 comes out, but it would be *really nice* if I could use > annotations in 2.x. > > [warning - mini rant] > Reason is, I am using 3.0a for now for this project, but I am sorry to > say that using parentheses for raising exceptions drives me up the > wall, and I don't like using them for the former print statement > either. I suspect this is partly due to the fact that I'm using 2.5 > for work, so I don't have the option to mentally "switch over" to the > Python 3 way. > /rant > > Does anyone have an annotations patch floating around against the > trunk / 2.6b, or failing that, does anyone have opinions on what my > chances are / things to look out for if I fiddle around with the > annotations patch from the py3k branch? (My understanding is that this > is revision 53170). I give this approximately 0% chance of happening. It's a really complex change to the syntax and code generator. Your motivation is also suspect: 2.6 is supposed to be a stepping stone towards 3.0, not a safe haven for people who don't like certain 3.0 features. Just get used to print(). Parentheses for exceptions has been allowed since approximately Python 2.0, so you have even less of an excuse there. -- --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
Re: [Python-Dev] C API for gc.enable() and gc.disable()
Alexandre Vassalotti wrote: Do you have any idea how this behavior could be fixed? I am not a GC expert, but I could try to fix this. Perhaps after making a GC pass you could look at the number of objects reclaimed during that pass, and if it's less than some fraction of the objects in existence, increase the threshold for performing GC by some factor. You would also want to do the opposite, so that a GC pass which reclaims a large proportion of objects would reduce the threshold back down again. -- Greg ___ 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] Status of Issue 2331 - Backport parameter annotations
On Jun 19, 4:16 pm, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: > complex change to the syntax and code generator. Your motivation is > also suspect: 2.6 is supposed to be a stepping stone towards 3.0, not > a safe haven for people who don't like certain 3.0 features. Just get Guilty as charged :) I tried out 3.0, decided I didn't like certain features I found annoying, and now I want to get the features (well only one feature right now) I like into 2.x so I can go back...I have some energy to do this, and I'm willing to learn, and I asked this list because I hoped someone would take pity on me and lend some help. What is my sentence, exile to outer PHP-iberia? At any rate, I am still interested if anyone has a working patch for this against the trunk, or any pointers for adapting 53170, words of experience when changing the grammar, additions to PEP 306, etc... any help would be greatly appreciated! Cheers, David ___ 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] Status of Issue 2331 - Backport parameter annotations
David Pokorny wrote:
[warning - mini rant]
Reason is, I am using 3.0a for now for this project, but I am sorry to
say that using parentheses for raising exceptions drives me up the
wall,
[warning - a bit of a counter-rant ;-]
Does it bother you that you need ()s to make instances elsewhere?
That you have to type int('123') instead of int, '123'?
The exception exception is an anomaly that would be gone in 2.6 (or
possibly not until 2.7), if it had not been put off, with other
removals, to 3.0.
[/rant]
> and I don't like using them for the former print statement either.
That I sympathize with, but I prefer file = xxx to >>xxx and otherwise
consider it an acceptible price for consistency with input() and getting
rid of lot of things I do not like, from old-style classes to the
exception anomaly ;-)
I suspect this is partly due to the fact that I'm using 2.5
for work, so I don't have the option to mentally "switch over" to the
Python 3 way.
Whereas I do, which, I admit, makes it easier.
/rant
___
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] sum() in math module not duplicated?
In the comments before the implementation of sum() in mathmodule.c, note 4 says: Note 4: A similar implementation is in Modules/cmathmodule.c. Be sure to update both when making changes. I can't find a sum implementation or similar code in cmathmodule.c. Did someone intend to port the sum function to cmath, or was it copied and then taken out? I'm wondering if this note should simply be removed. --amk ___ 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] sum() in math module not duplicated?
We're still working on the implementation details for math.sum(). When it's finished, the cmath equilvalent will be added. Raymond - Original Message - From: "A.M. Kuchling" <[EMAIL PROTECTED]> To: Sent: Thursday, June 19, 2008 7:16 PM Subject: [Python-Dev] sum() in math module not duplicated? In the comments before the implementation of sum() in mathmodule.c, note 4 says: Note 4: A similar implementation is in Modules/cmathmodule.c. Be sure to update both when making changes. I can't find a sum implementation or similar code in cmathmodule.c. Did someone intend to port the sum function to cmath, or was it copied and then taken out? I'm wondering if this note should simply be removed. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/python%40rcn.com ___ 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] Status of Issue 2331 - Backport parameter annotations
At any rate, I am still interested if anyone has a working patch for this against the trunk, or any pointers for adapting 53170, words of experience when changing the grammar, additions to PEP 306, etc... any help would be greatly appreciated! David, I can help. I don't have a patch against the trunk but my first revisions of the patch for annotations did handle things like tuple parameters which are relevant to 2.6. -Tony ___ 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
> This is a common problem. Binding to '127.0.0.1' will bind to *only*
> that address;
Indeed.
> binding to "" will bind to *all* addresses the machine
> is known by.
Agreed again. I believe what we're dealing with here though is a lack of
clarity regarding what role the 'address' attribute exposed by
multiprocess.connection.Listener should play. The way test_listener_client()
is written, it effectively treats 'address' as an end-point that can be
connected to directly (irrespective of the underlying family (i.e. AF_INET,
AF_UNIX, AF_PIPE)).
I believe the problems we've run into stem from the fact that the API doesn't
provide any guarantees as to what 'address' represents. The test suite assumes
it always reflects a connectable end-point, which I think is more than
reasonable. Unfortunately, nothing stops us from breaking this invariant by
constructing the object as Listener(family='AF_INET', address=('0.0.0.0', 0)).
How do I connect to an AF_INET Listener (i.e. SocketListener) instance whose
'address' attribute reports '0.0.0.0' as the host? I can't.
So, for now, I think we should enforce this invariant by raising an exception
in Listener.__init__() if self._socket.getsockbyname()[0] returns '0.0.0.0'.
In effect, tightening up the API such that we can guarantee Listener.address
will always represent a connectable end-point. We can look at how to service
'listen on all available interfaces' semantics at a later date -- that adds far
less value IMO than being able to depend on the said guarantee.
Thoughts?
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
