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
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
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
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
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
> 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
-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,
>> 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
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
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 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
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 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
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
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
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
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
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
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
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
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 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
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 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, 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
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
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
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,
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
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
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
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
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
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
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/
-
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
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: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:
>
> 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 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
>> 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 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
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
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 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
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 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
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 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
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
> 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 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.
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
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
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:
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
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
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
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
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:
-> 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
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
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
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
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
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 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
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
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
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
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
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 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
> 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
74 matches
Mail list logo
