Re: [Python-Dev] Indentation oddness...
On 2009-05-30 21:02, Greg Ewing wrote: Robert Kern wrote: The 'single' mode, which is used for the REPL, is a bit different than 'exec', which is used for modules. This difference lets you insert "blank" lines of whitespace into a function definition without exiting the definition. All that means is that the REPL needs to keep reading lines until it gets a completely blank one. I don't see why the compiler has to treat the source any differently once the REPL has decided how much text to feed it. Not true. The REPL will keep reading lines until compile(code,'','single') passes without a SyntaxError. You can put in blank lines when line continuation is implicit, like in the middle of a list. This is the reason that there is a 'single' mode in the first place, to determine when you've stopped typing. It's easier to add the grammar rule that a block does not end with a line of whitespace to the compiler than to implement all of the context-specific special cases for pure empty lines outside of the compiler. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco ___ 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] syntax warnings don't go through warnings.warn?
I'm just a little surprised by this - Is there a reason why syntax warnings are
special and untrappable via warnings.warn?
>>> import warnings
>>> def mywarn(*args): print 'xx', args
...
>>> warnings.warn = mywarn
>>> compile("def f():\na = 1\nglobal a\n", "", "exec")
:3: SyntaxWarning: name 'a' is assigned to before global declaration
at 012DB410, file "", line 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] syntax warnings don't go through warnings.warn?
On 1 Jun 2009, at 17:50, Dino Viehland wrote: I’m just a little surprised by this - Is there a reason why syntax warnings are special and untrappable via warnings.warn? Why should this work? From the docs... "Python programmers issue warnings by calling the warn() function defined in this module. (C programmers use PyErr_WarnEx; see Exception Handling for details)." Check out the warnings.catch_warnings context manager, but if you have any further questions please direct them to the normal Python mailing list, this is for development _of_ Python only. Matthew ___ 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] syntax warnings don't go through warnings.warn?
Matthew Wilkes wrote: On 1 Jun 2009, at 17:50, Dino Viehland wrote: I’m just a little surprised by this - Is there a reason why syntax warnings are special and untrappable via warnings.warn? Why should this work? From the docs... "Python programmers issue warnings by calling the warn() function defined in this module. (C programmers use PyErr_WarnEx; see Exception Handling for details)." Check out the warnings.catch_warnings context manager, but if you have any further questions please direct them to the normal Python mailing list, this is for development _of_ Python only. Dino is developing Python - he's one of the core developers of IronPython and I suspect he is asking whether this is intentional, and IronPython should implement the same behaviour, or whether it is a bug. Michael Matthew ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/fuzzyman%40voidspace.org.uk -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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] syntax warnings don't go through warnings.warn?
On 2009-06-01 11:50, Dino Viehland wrote:
I’m just a little surprised by this - Is there a reason why syntax
warnings are special and untrappable via warnings.warn?
>>> import warnings
>>> def mywarn(*args): print 'xx', args
...
>>> warnings.warn = mywarn
>>> compile("def f():\n a = 1\n global a\n", "", "exec")
:3: SyntaxWarning: name 'a' is assigned to before global declaration
at 012DB410, file "", line 1>
symtable.c uses PyErr_WarnExplicit() to provide file and line number
information. You need to stub warnings.warn_explicit().
>>> import warnings
>>> def mywarn_explicit(*args):
... print 'xx', args
...
>>> warnings.warn_explicit = mywarn_explicit
>>> compile("def f():\n a = 1\n global a\n", "", "exec")
xx ("name 'a' is assigned to before global declaration", 'exceptions.SyntaxWarning'>, '', 3, None, None)
at 0x39e9f8, file "", line 1>
--
Robert Kern
"I have come to believe that the whole world is an enigma, a harmless enigma
that is made terrible by our own mad attempt to interpret it as though it had
an underlying truth."
-- Umberto Eco
___
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] syntax warnings don't go through warnings.warn?
I work on IronPython so I am asking a question about development of Python. In particular my goal is to make sure that IronPython is behaving the same as CPython. If the normal discussion list is more appropriate for these questions I'd be happy to take it there. But before I do that please consider nt.tempnam - a built-in function. This goes through the normal warning mechanism but the parser doesn't. I would assume that this would go through PyErr_WarnEx (sorry, I can't actually look at the CPython code) given that tempnam is implemented in C. Why wouldn't the parser also go through PyErr_WarnEx? And warnings.catch_warnings doesn't work w/ parse warnings either so I'm not sure what the point of bringing that up is. -Original Message- From: Matthew Wilkes [mailto:[email protected]] Sent: Monday, June 01, 2009 10:29 AM To: Dino Viehland Cc: Python-Dev Subject: Re: [Python-Dev] syntax warnings don't go through warnings.warn? On 1 Jun 2009, at 17:50, Dino Viehland wrote: > I'm just a little surprised by this - Is there a reason why syntax > warnings are special and untrappable via warnings.warn? Why should this work? From the docs... "Python programmers issue warnings by calling the warn() function defined in this module. (C programmers use PyErr_WarnEx; see Exception Handling for details)." Check out the warnings.catch_warnings context manager, but if you have any further questions please direct them to the normal Python mailing list, this is for development _of_ Python only. Matthew ___ 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] syntax warnings don't go through warnings.warn?
On 1 Jun 2009, at 18:42, Michael Foord wrote: Dino is developing Python - he's one of the core developers of IronPython Ah, sorry, I'm bad with names, don't always pick up on who is who! and I suspect he is asking whether this is intentional, and IronPython should implement the same behaviour, or whether it is a bug. The docs do seem to be clear though, warnings.warn creates a warning, but there are multiple other ways to do it, it's a convenience method. Matt ___ 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] syntax warnings don't go through warnings.warn?
Ahh, ok, now I think I see... there is clearly some other mechanism that this warning is going through that we're not handling correctly. I'll try and track it down. Thanks! -Original Message- From: Matthew Wilkes [mailto:[email protected]] Sent: Monday, June 01, 2009 10:49 AM To: Michael Foord Cc: Dino Viehland; Python-Dev Subject: Re: [Python-Dev] syntax warnings don't go through warnings.warn? On 1 Jun 2009, at 18:42, Michael Foord wrote: > Dino is developing Python - he's one of the core developers of > IronPython Ah, sorry, I'm bad with names, don't always pick up on who is who! > and I suspect he is asking whether this is intentional, and > IronPython should implement the same behaviour, or whether it is a > bug. The docs do seem to be clear though, warnings.warn creates a warning, but there are multiple other ways to do it, it's a convenience method. Matt ___ 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] Issues with Py3.1's new ipaddr
In http://bugs.python.org/issue3959 , Clay McClure is raising some objections to the new ipaddr.py module. JP Calderone shares his concerns. I think they were the only commenters not directly affiliated with one of the competing projects. The issues they've raised seem serious, but I don't know enough about the subject to make a meaningful comment. Am hoping python-dev participants can provide some informed judgments. At issue is whether the module has some deep conceptual flaws that would warrant pulling it out of the 3.1 release. Also at issue is whether the addition was too rushed (see David Moss's comment on the tracker and later comments by Antoine Pitrou). Does anyone here know if Clay's concern about subnets vs netmasks in accurate and whether it affects the usability of the module? 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
Re: [Python-Dev] Issues with Py3.1's new ipaddr
I haven't read the bug, but given the extensive real-life use that ipaddr.py has seen at Google before inclusion into the stdlib, I think "deep conceptual flaws" must be an overstatement. There may be real differences of opinion about the politically correct way to view subnets and netmasks, but I don't doubt that the module as it stands is usable enough to keep it in the stdlib. Nothing's perfect. I think we should just stick to "sorry, too late, try again for 3.2". We've done that with plenty of more important flaws that were discovered on the verge of a release, and I don't recall ever regretting it. We can always add more features to the module in 3.2. --Guido On Mon, Jun 1, 2009 at 11:32 AM, Raymond Hettinger wrote: > In http://bugs.python.org/issue3959 , Clay McClure is raising some > objections to the new ipaddr.py module. JP Calderone shares his concerns. > I think they were the only commenters not directly affiliated with one of > the competing projects. The issues they've raised seem serious, but I don't > know enough about the subject to make a meaningful comment. > > Am hoping python-dev participants can provide some informed judgments. At > issue is whether the module has some deep conceptual flaws that would > warrant pulling it out of the 3.1 release. Also at issue is whether the > addition was too rushed (see David Moss's comment on the tracker and later > comments by Antoine Pitrou). > > Does anyone here know if Clay's concern about subnets vs netmasks in > accurate and whether it affects the usability of the module? -- --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] Issues with Py3.1's new ipaddr
On Mon, 1 Jun 2009 at 11:32, Raymond Hettinger wrote: Does anyone here know if Clay's concern about subnets vs netmasks in accurate and whether it affects the usability of the module? I can't speak to usability of the module, not having looked at it yet, but as far as I know from 10+ years of experience programming Cisco and other routers, a host address can always also be considered as a subnet consisting of one address. The netmask is 255.255.255.255, and is called a "host mask". That said, address+hostmask is not always the way you _think_ about an individual address; it depends on the context. FWIW I hate dealing with non-subnet-aligned IP address ranges whenever they come up. But it is true that they do come up. --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] Issues with Py3.1's new ipaddr
Raymond Hettinger wrote: > Also at issue is whether the > addition was too rushed (see David Moss's comment on the tracker and > later comments by Antoine Pitrou). That comment was from January 2009; it had two aspects a) is ipaddr getting special treatment just because it was contributed by Google? and b) shouldn't alternatives be considered? For a), the answer was always a clear "no". That the code comes from Google didn't affect inclusion at all. For b), there have been several attempts to approach alternatives since. For example, both netaddr people and ipaddr people tried to merge the projects, unsuccessfully. Both Duncan McGreggor and David Moss eventually spoke in favor of including ipaddr. So I think this particular issue was resolved. As for Clay McLure's issue: I feel it's primarily a matter of taste. I see nothing morally wrong in using the same class for hosts and networks, i.e. representing a host as a network of size 1. I can understand why people dislike that, but I don't see why it would stop people from doing with the library what they want to do. A number of other features might be missing from the library, for example, as Clay complains, there is no support for ranges of addresses (or, more generally, arbitrary sets). While I understand that there are good applications for such a data structure, I also think it can be added when contributed (and I would think "range of addresses" is still too narrow, for some applications I would envision - such as computing consistency of BGP tables and whois databases). 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] Issues with Py3.1's new ipaddr
On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" wrote:
> As for Clay McLure's issue: I feel it's primarily a matter of taste.
> I see nothing morally wrong in using the same class for hosts and
> networks, i.e. representing a host as a network of size 1. I can
> understand why people dislike that, but I don't see why it would stop
> people from doing with the library what they want to do.
>
To the extent that Clay is having issues, it's because ipaddr.py is poorly
documented, has potentially confusing comments, and he became confused.
Lesser issues are that ipaddr.py doesn't work the way he wants and that ip
addressing is inherently subtle.
Looking at the code in detail shows that ipaddr.IP/IPv4/IPv6 objects always
represent *networks*. He wants one particular address out of that network,
and that requires using __getitem__ or using IP.ip_ext. Neither is
particularly intuitive.
>>> import ipaddr
>>> ip = ipaddr.IPv4('10.33.11.17')
>>> ip
IPv4('10.33.11.17/32')
>>> ip[0]
'10.33.11.17'
>>> ip.ip_ext
'10.33.11.17'
>>>
This feels much more like poor documentation than wide-ranging conceptual
flaws.
I could put this in the tracker, but I'm not sure if that's appropriate.
-jake
___
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] Issues with Py3.1's new ipaddr
On Mon, Jun 1, 2009 at 6:54 PM, Jake McGuire wrote: > On Mon, Jun 1, 2009 at 12:16 PM, "Martin v. Löwis" wrote: > >> As for Clay McLure's issue: I feel it's primarily a matter of taste. >> I see nothing morally wrong in using the same class for hosts and >> networks, i.e. representing a host as a network of size 1. I can >> understand why people dislike that, but I don't see why it would stop >> people from doing with the library what they want to do. >> > > To the extent that Clay is having issues, it's because ipaddr.py is poorly > documented, has potentially confusing comments, and he became confused. > Lesser issues are that ipaddr.py doesn't work the way he wants and that ip > addressing is inherently subtle. > Sorry for the spam, I wrote my last message before reading the entire discussion surrounding the two libraries and trying to imagine using both ipaddr and netaddr. Clay is basically correct. The ipaddr.py API is missing important features, and it would probably be a mistake to add it to the python standard library if that means we'd have to maintain compatibility for the indefinite future. Like all largeish python projects, we wrote a library to do IP address manipulation. In our case, it's a whopping 64 lines long. While I wasn't aware of ipaddr.py or netaddr at the time, the API we created is much closer to netaddr's. Migrating our code to ipaddr would require significant work and is unlikely to happen. In fact, if I was starting a new project from scratch with similar requirements, I'd probably write my own library instead of using ipaddr. -jake ___ 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] Issues with Py3.1's new ipaddr
On Mon, Jun 1, 2009 at 11:32 AM, Guido van Rossum wrote: > I haven't read the bug, but given the extensive real-life use that > ipaddr.py has seen at Google before inclusion into the stdlib, I think > "deep conceptual flaws" must be an overstatement. When the users of the library are also the authors of the library, it is not surprising that the library enjoys "extensive real-life use." The real test of a library is not how well it succeeds at one installation, but how well it meets the needs of the larger user base. Having read the code and the author's comments, it seems to me that networking concepts not employed at Google have been neglected. While some of these features are easily added to ipaddr, their omission exposes a narrow view of the problem domain that has resulted in more fundamental problems in the library, such as the conflation of addresses and networks. > I think we should just stick to "sorry, too late, try again for 3.2". > We've done that with plenty of more important flaws that were > discovered on the verge of a release, and I don't recall ever > regretting it. We can always add more features to the module in 3.2. My concerns are not so much about adding features as they are about changing the API. Addressing the concerns that I and others have raised requires making backwards-incompatible changes. Doing that now, before ipaddr enjoys widespread deployment as part of the stdlib, seems prudent. Removing ipaddr from 3.1 appears to me less painful than fixing apps when ipaddr's API changes in 3.2. If this were a core feature that many developers were anxiously awaiting, I could understand the desire to release and iterate. But is there really a pressing need for an IP library in the stdlib? Until a satisfactory library is available for inclusion in the stdlib, the few developers that do require such functionality can easily enough download a library that meets their needs. Clay ___ 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] Issues with Py3.1's new ipaddr
> Clay is basically correct. The ipaddr.py API is missing important > features, and it would probably be a mistake to add it to the python > standard library if that means we'd have to maintain compatibility for > the indefinite future. >From a maintenance point of view, these two statements don't really relate. Yes, adding it to the standard library means that compatibility must be maintained (not for the indefinite future, but in a very strong sense). But no, that doesn't mean that it cannot have new features. Adding new features would not have to break compatibility, and, in many real-world cases of existing libraries, didn't. For the net-vs-host issue, I think a backwards-compatible solution is possible: just give the IP() function an option parameter that makes it reject a netmask during parsing. > Like all largeish python projects, we wrote a library to do IP address > manipulation. In our case, it's a whopping 64 lines long. [...] > In fact, if I was starting a new project from scratch with similar > requirements, I'd probably write my own library instead of using ipaddr. That was my feeling as well when ipaddr was first offered. It's just not an important library, and people will continue to roll their own for some time. OTOH, with ipaddr in the standard library, people will also start contributing extensions that make it support their use cases, so it should grow a wider application area than it currently supports. 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] Issues with Py3.1's new ipaddr
> If this were a core feature that many developers were anxiously > awaiting, I could understand the desire to release and iterate. But is > there really a pressing need for an IP library in the stdlib? You should have asked this question a few month ago. Now, release mechanics make it difficult to remove the library, except if a severe problem was uncovered - which you haven't been able to demonstrate. I don't believe that your issue "hosts and nets are represented with the same class" is severe: it is very well possible to use the IP function to represent individual hosts (including having a string representation that doesn't print a netmask). The only possibly-missing feature is support for rejecting host strings that include a mask on parsing; that can be added in a backwards-compatible way as an optional parameter to the IP function (as discussed on the tracker). 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote: > For the net-vs-host issue, I think a backwards-compatible solution > is possible: just give the IP() function an option parameter that > makes it reject a netmask during parsing. That doesn't solve much. IPv4 objects still always use CIDR notation when coerced to strings, meaning that IP addresses will always be rendered with a trailing "/32". Such notation is unacceptable in real-world applications that (correctly) distinguish between address and network. > That was my feeling as well when ipaddr was first offered. It's just > not an important library, and people will continue to roll their own > for some time. OTOH, with ipaddr in the standard library, people will > also start contributing extensions that make it support their use cases, > so it should grow a wider application area than it currently supports. That being the case, why not delay its inclusion until we can be sure that it in fact represents a good base upon which to build? Clay ___ 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] Issues with Py3.1's new ipaddr
On Tue, Jun 2, 2009 at 1:47 AM, "Martin v. Löwis" wrote: >> If this were a core feature that many developers were anxiously >> awaiting, I could understand the desire to release and iterate. But is >> there really a pressing need for an IP library in the stdlib? > > You should have asked this question a few month ago. Now, release > mechanics make it difficult to remove the library, except if a severe > problem was uncovered - which you haven't been able to demonstrate. This argument makes no sense. The feasibility of removing the library does not depend on the severity of the issues found within it. Either it is hard to remove the library, or it is easy. If it's hard to remove, it doesn't get any easier because I discover a fatal flaw. I've actually provided several examples of where the library fails when used in common scenarios, yet your solution involves incremental hacks that don't fix the underlying problems. You write as if you have a vested interest in releasing the library -- why? > I don't believe that your issue "hosts and nets are represented with the > same class" is severe: it is very well possible to use the IP function > to represent individual hosts (including having a string representation > that doesn't print a netmask). The only possibly-missing feature is > support for rejecting host strings that include a mask on parsing; that > can be added in a backwards-compatible way as an optional parameter to > the IP function (as discussed on the tracker). There are other missing features, but again, my concern is not about missing features: it's about a quirky API that conflates concepts in the problem domain, leading to subtle bugs and breaking the principle of least surprise. Clay ___ 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] Issues with Py3.1's new ipaddr
Clay McClure wrote:
> On Tue, Jun 2, 2009 at 1:38 AM, "Martin v. Löwis" wrote:
>
>> For the net-vs-host issue, I think a backwards-compatible solution
>> is possible: just give the IP() function an option parameter that
>> makes it reject a netmask during parsing.
>
> That doesn't solve much. IPv4 objects still always use CIDR notation
> when coerced to strings, meaning that IP addresses will always be
> rendered with a trailing "/32".
That's not true:
py> x = ipaddr.IP("30.40.50.60")
py> print(x.ip_ext_full)
30.40.50.60
> Such notation is unacceptable in
> real-world applications that (correctly) distinguish between address
> and network.
So use a different notation that is also supported by the library.
>> That was my feeling as well when ipaddr was first offered. It's just
>> not an important library, and people will continue to roll their own
>> for some time. OTOH, with ipaddr in the standard library, people will
>> also start contributing extensions that make it support their use cases,
>> so it should grow a wider application area than it currently supports.
>
> That being the case, why not delay its inclusion until we can be sure
> that it in fact represents a good base upon which to build?
Because we *are* sure that it in fact represents a good base upon which
to build.
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] Issues with Py3.1's new ipaddr
> This argument makes no sense. The feasibility of removing the library > does not depend on the severity of the issues found within it. Either > it is hard to remove the library, or it is easy. If it's hard to > remove, it doesn't get any easier because I discover a fatal flaw. We could remove it, but then what we have wouldn't really be a release candidate anymore, so the release would get delayed. > I've actually provided several examples of where the library fails > when used in common scenarios, yet your solution involves incremental > hacks that don't fix the underlying problems. You write as if you have > a vested interest in releasing the library -- why? I have a vested interest in releasing Python 3.1, and in sticking to decisions that have been made by other committers. I trust these fellow committers, so I defend their decisions. I personally have no plans for using this library, or any other IP address library (at least not in any application I plan to write soon). At the moment, I'm struggling more with IP address libraries in Perl. > There are other missing features, but again, my concern is not about > missing features: it's about a quirky API that conflates concepts in > the problem domain, leading to subtle bugs and breaking the principle > of least surprise. I believe the API appears more quirky to you than it actually is, probably because you don't have understood it fully (but I might be wrong with that, and there might be a different reason). 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
