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
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 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
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 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
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 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
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
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
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
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
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, 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
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 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
> 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'
> 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
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
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
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
> 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
21 matches
Mail list logo
