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 equality is still broken as Steven
describes, then no, it won't
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) against using them in a way that does
not correspond to a prefix
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):
Could we
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 this
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 ba...@barrys-emacs.org 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(
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 switched
On Sun, Sep 27, 2009 at 00:21, Mark Dickinson dicki...@gmail.com 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
On Sat, Sep 26, 2009 at 11:08 PM, Nick Coghlan ncogh...@gmail.com 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
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 br...@python.org wrote:
On Sun, Sep 27, 2009 at 00:21, Mark Dickinson dicki...@gmail.com 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
On 27 Sep 2009, at 03:12, Ned Deily wrote:
In article 90a90a3c-e037-4fca-95d2-a46a5c6dd...@barrys-emacs.org,
Barry Scott ba...@barrys-emacs.org 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
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
Dave M.
On 27 Sep 2009, at 07:56, Martin v. Löwis mar...@v.loewis.de 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
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 peter at 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
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 it
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
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
conflating
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 python at 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
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 mar...@v.loewis.de 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
On Sun, Sep 27, 2009 at 4:23 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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
Peter Moody peter at 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
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 kind of
On Sun, Sep 27, 2009 at 10:30 AM, Steven D'Aprano st...@pearwood.info 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
On Sun, Sep 27, 2009 at 10:22 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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
Peter Moody peter at 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 your
On Sun, Sep 27, 2009 at 11:17 AM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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
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
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 you know
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight f...@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 claim is broken.
He's claiming your solution to address
Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at 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 claim is
On Sun, Sep 27, 2009 at 1:15 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at hda3.com writes:
On Sun, Sep 27, 2009 at 12:40 PM, James Y Knight foom at fuhm.net wrote:
On Sep 27, 2009, at 3:18 PM, Peter Moody wrote:
administrators) would use it, but it's doable. what
Peter Moody peter at 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 results aren't
On Sun, Sep 27, 2009 at 1:49 PM, Antoine Pitrou solip...@pitrou.net wrote:
Peter Moody peter at 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,
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
On Sun, Sep 27, 2009 at 4:33 AM, Antoine Pitrou solip...@pitrou.net 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
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
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
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
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 circumstances
Peter Moody peter at 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
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
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 of
On Sun, Sep 27, 2009 at 5:13 PM, Steven D'Aprano st...@pearwood.info 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
Peter Moody peter at 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 fperez@gmail.comwrote:
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
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
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 solip...@pitrou.net wrote:
Peter Moody peter at 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
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 solip...@pitrou.net 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
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 greg.ew...@canterbury.ac.nz 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
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
On Sun, Sep 27, 2009 at 5:51 PM, Antoine Pitrou solip...@pitrou.net 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
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
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
On Sun, Sep 27, 2009 at 8:41 PM, Benjamin Peterson benja...@python.org wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
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
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 for allowing
-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
2009/9/27 Steven Bethard steven.beth...@gmail.com:
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.
2009/9/27 Steven Bethard steven.beth...@gmail.com:
On Sun, Sep 27, 2009 at 8:08 PM, Benjamin Peterson benja...@python.org
wrote:
2009/9/27 Steven Bethard steven.beth...@gmail.com:
If you think getopt and optparse should stick around in 3.X, why is
that? If you think there are things that
On Sun, Sep 27, 2009 at 9:09 PM, Martin v. Löwis mar...@v.loewis.de 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
70 matches
Mail list logo
