> 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
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. IP
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 que
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 CID
> 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 t
> 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'
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 au
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
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 th
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 Go
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 e
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
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 kno
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:matt...@matthewwilkes.co.uk]
Sent: Monday, June 01, 2009 10:49 AM
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 behav
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 cons
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
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() fun
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
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: n
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 m
21 matches
Mail list logo
