> One thing I'd like to see in the list are real names of committers,
> not tracker names. Of course, people looking for people to assign a bug
> to should not have to search for the tracker name, so I'd like to make
> another request (that Brett already made when we switched trackers):
>
> Cou
On 14 Sep 2009, at 17:44, Peter Moody wrote:
Folks, Guido,
I believe PEP 3144 is ready for your review. When you get a chance,
can you take a look/make a pronouncement?
>>> x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0' )
>>> x
IPv4Network('192.168.1.1/16')
You can decide on which bug t
Hello all,
I'm looking for advice on how to clean up an ugliness (one
that I'm at least partly responsible for) in the Python build setup.
Here's the problem: some of the exported functions (e.g. atanh,
log1p) in the Python/pymath.c file aren't needed by the Python core
at all; they're exported
On Sat, Sep 26, 2009 at 6:34 AM, Barry Scott wrote:
>
> On 14 Sep 2009, at 17:44, Peter Moody wrote:
>
>> Folks, Guido,
>>
>> I believe PEP 3144 is ready for your review. When you get a chance,
>> can you take a look/make a pronouncement?
>>
>
>
x=ipaddr.IPv4Network( '192.168.1.1/240.255.0.0
Martin v. Löwis wrote:
>> One thing I'd like to see in the list are real names of committers,
>> not tracker names. Of course, people looking for people to assign a bug
>> to should not have to search for the tracker name, so I'd like to make
>> another request (that Brett already made when we swi
Guido van Rossum wrote:
> I realize I'm late to this party, but this is just a naming issue, right?
Not really (AFAIU).
> For any network, there are two special addresses, one with the last
> bits all zeros, one with the last bits all ones. We can call them A
> and B, or network and broadcast, or
On Sun, Sep 27, 2009 at 00:21, Mark Dickinson wrote:
> Hello all,
>
> I'm looking for advice on how to clean up an ugliness (one
> that I'm at least partly responsible for) in the Python build setup.
>
> Here's the problem: some of the exported functions (e.g. atanh,
> log1p) in the Python/pymath
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan wrote:
> Peter Moody wrote:
>> what you want is strict=True, just checked in. I've been meaning to
>> send an update to the PEP explaining why this choice was made. I'm
>> hoping this will ameliorate your confusion.
>
> If the ip property remains and
Hello
Below is a corrected version of the PEP update, adding the start/end
indexes proposition and fixing functions signatures. Does anyone
disagree with these specifications ? Or can we consider it as a target
for the next versions of the io module ?
I would have no problem to implement this
On Sun, Sep 27, 2009 at 8:48 AM, Brett Cannon wrote:
> On Sun, Sep 27, 2009 at 00:21, Mark Dickinson wrote:
[...]
>> So I've now got a file Modules/math_support.c that contains
>> some functions needed by both mathmodule.c and
>> cmathmodule.c, as well as a couple of functions only
>> currently n
On 27 Sep 2009, at 03:12, Ned Deily wrote:
In article <90a90a3c-e037-4fca-95d2-a46a5c6dd...@barrys-emacs.org>,
Barry Scott wrote:
I'm working with http://svn.python.org/projects/python/trunk on Mac
OS
X 10.6.1
using Apples xcode gcc 4.2.1.
When I run the following commands:
./conf
Found in current io PEP :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()? Or is
that an implementation convenience that users should not rely on?
-> it seems that the only important matter is : file pointer posit
Dave M.
On 27 Sep 2009, at 07:56, "Martin v. Löwis" wrote:
As a side note, I would be in favor of dropping the concept of a
mask
from the library, and only support a prefix length.
-1
IPv6 doesn't support masks at all, and even for IPv4, I think there
are conventions (if not RFCs) agai
Pascal Chambon wrote:
-> it seems that the only important matter is : file pointer positions
and bytes/characters read should always be the ones that the user
expects, as if there were no buffering.
That sounds right to me.
Q from me : What happens in read/write text files, when overwriting
Peter Moody hda3.com> writes:
>
> To be explicit though, unless I'm drastically misreading what you're
> asking for, I consider the design you're proposing to be broken from a
> usability perspective (striving for academic/pedantic correctness over
> accepted practice).
It is certainly not acade
Pascal Chambon wrote:
Found in current io PEP :
Q: Do we want to mandate in the specification that switching between
reading and writing on a read-write object implies a .flush()? Or is
that an implementation convenience that users should not rely on?
-> it seems that the only important matter
Hello,
> So here is the proposed semantic, which matches established conventions:
>
> *IOBase.truncate(n: int = None) -> int*
[...]
I still don't think there is a sufficient benefit in breaking
compatibility. If you want the file pointer to remain the same, you can
save it first and restore i
Le Sun, 27 Sep 2009 10:20:23 +0200, Pascal Chambon a écrit :
> Q: Do we want to mandate in the specification that switching between
> reading and writing on a read-write object implies a .flush()?
It doesn't and shouldn't be mandated in the specification, IMO. An
implementation should be free to
Pascal Chambon wrote:
Hello
Below is a corrected version of the PEP update, adding the start/end
indexes proposition and fixing functions signatures. Does anyone
disagree with these specifications ? Or can we consider it as a target
for the next versions of the io module ?
I would have no pro
Antoine Pitrou writes:
> There was a proposal to have a separate parse_address_and_mask
> method which would return a (Address, Network) tuple, I still don't
> know why you don't seem to consider it seriously, rather than
> trying to make the Network class a kind of all-in-one type
> conflati
Pascal Chambon wrote:
> Found in current io PEP :
> Q: Do we want to mandate in the specification that switching between
> reading and writing on a read-write object implies a .flush()? Or is
> that an implementation convenience that users should not rely on?
> -> it seems that the only important
MRAB mrabarnett.plus.com> writes:
>
> If the characters are always the same number of bytes) then overwriting
> could be possible; that would, however, make the behaviour more
> complicated (sometimes you can, sometimes you can't), so it's probably
> just simpler to forbid read+write text streams
On Sep 27, 2009, at 4:20 AM, Pascal Chambon wrote:
Thus, at the moment IOErrors rather have the semantic of "particular
case of OSError", and it's kind of confusing to have them remain in
their own separate tree... Furthermore, OSErrors are often used
where IOErrors would perfectly fit, eg.
> I personally do not have a problem with that, except that you
> apparently can't grasp his way of thinking, and he apparently can't
> grasp yours.
If I was the only one disagreeing it wouldn't be that annoying (except
for me :-)).
> I'm -1 on PEP 3144 primarily because of this
> communications
On Sun, Sep 27, 2009 at 12:41 AM, "Martin v. Löwis" wrote:
> Guido van Rossum wrote:
>> I realize I'm late to this party, but this is just a naming issue, right?
>
> Not really (AFAIU).
>
>> For any network, there are two special addresses, one with the last
>> bits all zeros, one with the last bi
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> To be explicit though, unless I'm drastically misreading what you're
>> asking for, I consider the design you're proposing to be broken from a
>> usability perspective (striving for academic/pedantic corr
Peter Moody hda3.com> writes:
>
> The reason (aside from the name) that I'm not going to include this in
> ipaddr is that it would require the user to deal with two objects when
> one would suffice.
You make it sound like it's a burden, but "dealing" with two objects is not
something extraordina
On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
> > There was a proposal to have a separate parse_address_and_mask
> > method which would return a (Address, Network) tuple, I still don't
> > know why you don't seem to consider it seriously, rather than
> > trying to make the Network class a kin
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano wrote:
> On Mon, 28 Sep 2009 02:47:27 am Peter Moody wrote:
>
>> > There was a proposal to have a separate parse_address_and_mask
>> > method which would return a (Address, Network) tuple, I still don't
>> > know why you don't seem to consider it s
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> The reason (aside from the name) that I'm not going to include this in
>> ipaddr is that it would require the user to deal with two objects when
>> one would suffice.
>
> You make it sound like it's a bu
Peter Moody hda3.com> writes:
>
> > (or would you argue that Address objects should have an optional
distinguishing
> > port number, for "convenience" reasons?)
>
> I'm not sure what you're talking about, I've never argued to add layer
> 4 information to ipaddr.
It was an analogy, just like yo
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> > (or would you argue that Address objects should have an optional
> distinguishing
>> > port number, for "convenience" reasons?)
>>
>> I'm not sure what you're talking about, I've never argued to add la
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what you're claiming is
that my use case is invalid.
that's what I claim is broken.
He's claiming your solution to address your use case is confusing, not
that the use case is invalid.
I'm not
>> For the broadcast address, it's different, since you might also use
>> it in programming (i.e. when sending broadcasts).
>
> So there is no need to look up the broadcast address in the
> configuration? Don't you have to look up the rest of the network
> configuration too? (Or otherwise how do y
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight wrote:
>
> On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
>
>> administrators) would use it, but it's doable. what you're claiming is
>> that my use case is invalid.
>>
>> that's what I claim is broken.
>
> He's claiming your solution to address yo
Peter Moody hda3.com> writes:
>
> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight fuhm.net> wrote:
> >
> > On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
> >
> >> administrators) would use it, but it's doable. what you're claiming is
> >> that my use case is invalid.
> >>
> >> that's what I cl
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight fuhm.net> wrote:
>> >
>> > On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
>> >
>> >> administrators) would use it, but it's doable. what you're claiming
Peter Moody hda3.com> writes:
>
> >> > def parse_net_and_addr(s):
> >> > return (IPNetwork(s), IPAddress(s.split('/')[0]))
> >>
> >> I've only heard talk of new classes and new methods, not new
> >> constructor functions.
> >
> > Well, "method" in that context meant "class method" since the resu
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> >> > def parse_net_and_addr(s):
>> >> > return (IPNetwork(s), IPAddress(s.split('/')[0]))
>> >>
>> >> I've only heard talk of new classes and new methods, not new
>> >> constructor functions.
>> >
>> > W
Below is a new PEP based on discussions from the stdlib-sig, which
proposes to add the argparse module to the standard library in Python
2.7 and 3.2.
Looking forward to your feedback!
Steve
http://www.python.org/dev/peps/pep-0389/
-
Antoine Pitrou wrote:
> This deserves its own PEP IMO, although I'm not sure it would be accepted
> (ISTR the idea of a detailed IO exception hierarchy was already refused
> in the past).
Not as such - a big exception hierarchy rewrite was rejected, but
nothing specifically limited to the IO exc
On Sun, Sep 27, 2009 at 4:33 AM, Antoine Pitrou wrote:
>> So here is the proposed semantic, which matches established conventions:
>>
>> *IOBase.truncate(n: int = None) -> int*
> [...]
>
> I still don't think there is a sufficient benefit in breaking
> compatibility. If you want the file pointer t
Nick Coghlan wrote:
Antoine Pitrou wrote:
This deserves its own PEP IMO, although I'm not sure it would be accepted
(ISTR the idea of a detailed IO exception hierarchy was already refused
in the past).
Not as such - a big exception hierarchy rewrite was rejected, but
nothing specifica
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impressed as well).
I think
Brett Cannon wrote:
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along with the rest of the audience which was obviously
impres
Peter Moody wrote:
> Steven D'Aprano wrote:
>
> Could you explain what benefit there is for allowing the user to create
> network objects that don't represent networks? Is there a use-case
> where these networks-that-aren't-networks are something other than a
> typo? Under what circumstanc
Peter Moody hda3.com> writes:
>
> this is "less useful (strictly removing functionality)" and is an
> example of what I explicitly said I was not going to do with ipaddr.
(please note the conditional wording here) Assuming that a significant number of
people agree that there is a design problem,
Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit :
>
> Not as such - a big exception hierarchy rewrite was rejected, but
> nothing specifically limited to the IO exceptions.
>
> Michael's response cut to the heart of the issue though - a richer IO
> exception hierarchy can make life inter
Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit :
[truncate()]
>
> What compatibility, though?
Compatibility accross the 3.x line.
> f.truncate() behaves different in 2.x than
> in 3.x, and in 2.x it seems to match the POSIX semantics (i.e. the seek
> position is unchanged even thou
On Sun, Sep 27, 2009 at 3:32 PM, Antoine Pitrou wrote:
> Peter Moody hda3.com> writes:
>>
>> this is "less useful (strictly removing functionality)" and is an
>> example of what I explicitly said I was not going to do with ipaddr.
>
> (please note the conditional wording here) Assuming that a sig
On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
> >> I *understand* what you're saying, I *understand* that
> >> 192.168.1.1/24 isn't a network,
> >
> > But you still want to treat it as one.
> >
> > Could you explain what benefit there is for allowing the user to
> > create network objects t
On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote:
> I am going to state upfront that I am +1 for this and I encouraged
> Steven to submit this PEP on the stdlib-SIG. I still remember watching
> Steven's lightning talk at PyCon 2009 on argparse and being impressed by
> it (along with the rest
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano wrote:
> On Mon, 28 Sep 2009 03:53:27 am Peter Moody wrote:
>
>> >> I *understand* what you're saying, I *understand* that
>> >> 192.168.1.1/24 isn't a network,
>> >
>> > But you still want to treat it as one.
>> >
>> > Could you explain what bene
Peter Moody hda3.com> writes:
>
> I've never said otherwise. In fact, from an email last night, "If what
> the community requires is the library you've described, then ipaddr is
> not that library." The changes *you* require make ipaddr significantly
> less useful to me. I'm not prepared to make
On Sun, Sep 27, 2009 at 8:31 PM, Fernando Perez wrote:
> On Sun, 27 Sep 2009 14:57:34 -0700, Brett Cannon wrote:
>
> > I am going to state upfront that I am +1 for this and I encouraged
> > Steven to submit this PEP on the stdlib-SIG. I still remember watching
> > Steven's lightning talk at PyCon
Hello,
I am neutral on the idea of adding argparse. However, I'm -1 on deprecating
optparse. It is very widely used (tons of scripts use it), and ok for many uses;
deprecating it is totally unhelpful and gratuitous.
Regards
Antoine.
___
Python-Dev m
Nick Coghlan wrote:
The use case for "given a netmask and an arbitrary host on that network,
give me the appropriate IPNetwork object" has been well established by
this discussion (although still isn't particularly well described even
in the latest PEP update). This is what "strict=False" covers
On Sun, 27 Sep 2009 at 13:59, Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
Peter Moody hda3.com> writes:
def parse_net_and_addr(s):
?return (IPNetwork(s), IPAddress(s.split('/')[0]))
I've only heard talk of new classes and new methods, not new
constructor func
Michael Foord wrote:
Some of the error messages are truly awful though as things stand,
especially for someone new to Python. Try to read from a file handle
opened in read mode for example: IOError: [Errno 9] Bad file descriptor
Subdividing the IOError exception won't help with
that, because
Peter Moody wrote:
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou wrote:
>
Assuming the Network type loses the notion of a specific host (or host address,
or `ip`) attached to it, yes.
this is "less useful (strictly removing functionality)" and is an
example of what I explicitly said I was
On Sep 27, 2009, at 6:00 PM, Michael Foord wrote:
Brett Cannon wrote:
I am going to state upfront that I am +1 for this and I encouraged
Steven to submit this PEP on the stdlib-SIG. I still remember
watching
Steven's lightning talk at PyCon 2009 on argparse and being impressed
by it (along
On Sun, Sep 27, 2009 at 9:26 PM, Greg Ewing wrote:
> Would you be kind enough to explain exactly what use
> case you have for retaining this information?
>
> Apologies if you've done so before -- I've been
> trying to follow this discussion, but that point
> doesn't seem to have come through clear
Looking though the tests you have setup for ipaddr it is clear that
you want the following to be True
ip1 = ipaddr.IPv4Network('1.1.1.0/24')
ip2 = ipaddr.IPv4Network('1.1.1.1/24')
ip1 == ip2
based on this test
self.assertEquals(ip1.compare_networks(ip2), 0)
but your ><= operators all compare ag
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou wrote:
> I am neutral on the idea of adding argparse. However, I'm -1 on deprecating
> optparse. It is very widely used (tons of scripts use it), and ok for many
> uses;
> deprecating it is totally unhelpful and gratuitous.
Could you elaborate? If
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> If you think getopt and optparse should stick around in 3.X, why is
>> that? If you think there are things that getopt and optparse do better
>> than argparse, could you please give some examples?
>
> Transit
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> The first release where any real deprecation message would show up is
>> Python 3.4, more than 3 years away. If you think 3 years isn't long
>> enough for people to be over the Python 3 transition, let's stic
>> Finally, to Stephen's point about seeing the other side of the
>> argument, I wrote this offlist a week ago:
>>
>> I *understand* what you're saying, I *understand* that
>> 192.168.1.1/24 isn't a network,
>
> But you still want to treat it as one.
>
> Could you explain what benefit there is
-1 for deprecating getopt. getopt is super-simple and especially useful for
c programmers learning python.
+1 for argparse.+1 for eventual deprecation of optparse - optparse and
argparse have a very similar syntax and having both is just
confusing. tsboapooowtdi
On Mon, Sep 28, 2009 at 6:46 AM,
> If you think getopt and optparse should stick around in 3.X, why is
> that? If you think there are things that getopt and optparse do better
> than argparse, could you please give some examples?
I personally consider getopt superior to both optparse and argparse.
Those are terribly verbose in sp
2009/9/27 Steven Bethard :
> If you think getopt and optparse should stick around in 3.X, why is
> that? If you think there are things that getopt and optparse do better
> than argparse, could you please give some examples?
Transitioning to Python 3 is already a pain. bytes/str/unicode things
are
2009/9/27 Steven Bethard :
> On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson
> wrote:
>> 2009/9/27 Steven Bethard :
>>> If you think getopt and optparse should stick around in 3.X, why is
>>> that? If you think there are things that getopt and optparse do better
>>> than argparse, could you pl
On Sun, Sep 27, 2009 at 9:09 PM, "Martin v. Löwis" wrote:
>> If you think getopt and optparse should stick around in 3.X, why is
>> that? If you think there are things that getopt and optparse do better
>> than argparse, could you please give some examples?
>
> I personally consider getopt superio
On Sun, Sep 27, 2009 at 8:49 PM, Benjamin Peterson wrote:
> 2009/9/27 Steven Bethard :
>> On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson
>> wrote:
>>> 2009/9/27 Steven Bethard :
The first release where any real deprecation message would show up is
Python 3.4, more than 3 years away
Martin v. Löwis v.loewis.de> writes:
>
> > Could you explain what benefit there is for allowing the user to create
> > network objects that don't represent networks? Is there a use-case
> > where these networks-that-aren't-networks are something other than a
> > typo? Under what circumstances
74 matches
Mail list logo
