Guido van Rossum wrote:
I've never heard of someone who had a use case for
denormalized fractions, but I don't doubt that Peter has a use case
for denormalized IPNetwork objects. (Do you doubt that Peter has such
a use case? If so, we have a much more fundamental disagreement.)
It would be inte
On Mon, Sep 28, 2009 at 8:44 PM, "Martin v. Löwis" wrote:
>> Let's take ``getopt.getopt(sys.argv[1:], "a:b", ["alpha=", "beta"])``
>
> As Yuvgoog Greenle says, the canonical getopt way is to write
[snip getopt code]
> Even though this is many more lines, I prefer it over
> optparse/argparse: this
Michael Foord wrote:
You said that having an exception hierarchy was impossible because the
only information we have is the error number.
No, I said that having an exception hierarchy wouldn't
help you to sort out the different meanings of a single
error code.
If you have some *other* way of
> Let's take ``getopt.getopt(sys.argv[1:], "a:b", ["alpha=", "beta"])``
> as an example and simply assume that 'alpha' takes a string as an
> argument and that it's required and that 'beta' is a boolean flag. To
> pull everything out you could do::
>
> options, args = getopt.getopt(sys.argv[1:],
On Mon, Sep 28, 2009 at 7:17 PM, R. David Murray wrote:
> On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
>>
>> On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray
>> wrote:
>> I would say that there certainly are precedents in other areas for
>> keeping the information about the input form ar
James Y Knight wrote:
> On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote:
>> Distributions should really not be put in charge of upstream
>> coding design decisions.
>
> I don't think you can blame distros for this one
>
> From PEP 0261:
> It is also proposed that one day --enable-unicode
On Mon, 28 Sep 2009 at 13:43, Guido van Rossum wrote:
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray wrote:
I would say that there certainly are precedents in other areas for
keeping the information about the input form around. For example,
occasionally it would be handy if parsing a hex integ
>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 those changes in an
>attempt seek acce
Peter Moody 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 not going to do with ipaddr.
A possible compro
Greg Ewing wrote:
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the except
Michael Foord wrote:
Well, the file type knows what mode it is opened in so catching these
errors is really not difficult at all.
Yes, in this particular case it could do some checking of
its own before making the system call. But this still has
nothing to do with the exception hierarchy.
--
On Tue, Sep 29, 2009 at 07:44:50AM +1000, Cameron Simpson wrote:
> | ArgumentParser.add_getopt_arguments(options[, long_options])
>
> Yes please!
>
> I'm also very fond of the succinct getopt sequence-of-letters style;
> it works really well for the simple cases.
The syntax "a:b" is also
On 27Sep2009 21:24, Steven Bethard wrote:
| 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
On Mon, Sep 28, 2009 at 4:29 PM, "Martin v. Löwis" wrote:
> I guess a close case would be rational numbers: clearly, 3÷2 == 6÷4;
> would a Python library still remember (and repr) the original numerator
> and denominator?
>
No need for a hypothetical, rational numbers were added in Python 2.6:
P
> I would say that there certainly are precedents in other areas for
> keeping the information about the input form around. For example,
> occasionally it would be handy if parsing a hex integer returned an
> object that was compatible with other integers but somehow kept a hint
> that would cause
> You do find "address plus mask" when specifying an IP address for an
> interface. This is a shorthand for specifying the IP address plus the
> network, since the network can be derived from the IP plus the mask.
> But it is a _shorthand_
Just as he says.
Martin
for a live demo of how getopt is useful and flexible, I like how Audacity
uses it:
http://www.google.com/codesearch/p?hl=en&sa=N&cd=6&ct=rc#_hWFOhGz9lE/mezzo/scons/sconsign.py&q=getopt%20%22import%20getopt%22%20file:%5C.py$&l=264
To answer your question, it goes like this:
options, args = geto
On Mon, 28 Sep 2009 at 22:32, Antoine Pitrou wrote:
Le lundi 28 septembre 2009 ?? 22:11 +0200, "Martin v. L??wis" a ??crit :
That's not the question that was asked, though - the question asked
was "Under what circumstances would I want to specify...". I hope
most people agree that it is desirab
On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray wrote:
> On Mon, 28 Sep 2009 at 22:11, "Martin v. Löwis" wrote:
>>>
>>> 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
Steven Bethard gmail.com> writes:
>
> I could conceivably add an OptionParser class which::
> [...]
Actually, I think that would be a waste of time. It would be less time-consuming
to keep optparse.py than write a whole new compatibility bridge that you'll have
to debug and maintain anyway, with
On Mon, 28 Sep 2009 at 22:11, "Martin v. L??wis" wrote:
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
Le lundi 28 septembre 2009 à 22:11 +0200, "Martin v. Löwis" a écrit :
>
> That's not the question that was asked, though - the question asked
> was "Under what circumstances would I want to specify...". I hope
> most people agree that it is desirable to be able to specify a network
> not just by i
Martin v. Löwis wrote:
>> 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
Martin v. Löwis v.loewis.de> writes:
>
> Still, people proposing that 192.168.1.1/24 should be rejected (I still
> don't know whether anybody is actually proposing that) *have* to provide
> a proposal how this should be input instead.
It was proposed to have a dedicated function or class method
> Unfortunately, that would mean that we should provide two comparison
> operations, and have neither available as == (unless one is more clearly
> right than the other, which I'm skeptical about).
That's probably why some people have argued to have two separate classes for the
case of "networks"
> 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 w
On Mon, Sep 28, 2009 at 12:22 PM, Brett Cannon wrote:
> On Mon, Sep 28, 2009 at 08:49, Steven Bethard
> wrote:
>> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
>>> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
* Would you like argparse to grow an add_getopt_arguments meth
On Mon, Sep 28, 2009 at 08:49, Steven Bethard wrote:
> On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
>> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
>>> * Would you like argparse to grow an add_getopt_arguments method (as
>>> in my other post)?
>>
>> 0
>>
>>> * If argparse grew
>> It's fairly obvious to me why the library should support 192.168.1.1/24
>> as an input, and return a network.
>>
>> End-users are likely going to enter such things (e.g. 82.94.164.162/29),
>> as they will know one IP address in the network (namely, of one machine
>> that they are looking at), an
> The fundamental divide here is between two behaviors.
>
> ipaddr:
>
> >>> x = IPv4Network('192.168.1.1/24')
> >>> y = IPv4Network('192.168.1.0/24')
> >>> x == y
> False
> >>> x.ip
> IPv4Address('192.168.1.1')
>
> desired:
>
> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 11:17 AM, Antoine Pitrou wrote:
> Guido van Rossum python.org> writes:
>>
>> At the same time I don't think a complete reset of the proposed API is
>> necessary. I am rather more thinking of judicious API tweaks in order
>> to cover some new use cases, without requiring a
2009/9/28 Peter Moody
> [cc += david moss]
>
> On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum
> wrote:
> > On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou
> wrote:
> >> Peter Moody hda3.com> writes:
> >>>
> >>> I've never said otherwise. In fact, from an email last night, "If what
> >>> the
On Mon, Sep 28, 2009 at 9:37 AM, Steven Bethard
wrote:
> On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
> wrote:
>> m h wrote:
>>>
>>> Perhaps this is OT, but since command line parsing is part of
>>> configuration, I figure I'd throw it out there. My scripts often have
>>> configuration that th
On Tue, 29 Sep 2009 02:39:06 am Guido van Rossum wrote:
> I think Peter is pretty frustrated by the many attacks on "his"
> library. There are probably a number of different things going on
> simultaneous: Peter has been driven into the defense by attacks both
> reasonable and unreasonable, there
Guido van Rossum python.org> writes:
>
> At the same time I don't think a complete reset of the proposed API is
> necessary. I am rather more thinking of judicious API tweaks in order
> to cover some new use cases, without requiring a complete rewrite or
> destroying the usability of the proposa
On Sun, Sep 27, 2009 at 3:44 PM, Antoine Pitrou wrote:
> Le Sun, 27 Sep 2009 14:24:52 -0700, Guido van Rossum a écrit :
> [truncate()]
>>
>> What compatibility, though?
>
> Compatibility accross the 3.x line.
Well, in this case, maybe compatibility with 2.x is more important --
this isn't somethi
[cc += david moss]
On Mon, Sep 28, 2009 at 9:39 AM, Guido van Rossum wrote:
> On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou wrote:
>> 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 d
On 2009-09-28 10:37 AM, Steven Bethard wrote:
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
wrote:
m h wrote:
Perhaps this is OT, but since command line parsing is part of
configuration, I figure I'd throw it out there. My scripts often have
configuration that the command line can override
On Sun, Sep 27, 2009 at 5:32 PM, Antoine Pitrou wrote:
> 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
Ok updated patch so it meets the following conditions
>>> IPv4Network(192.168.1.1/24)
IPv4Network(192.168.1.0/24)
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
True
>>> hash(x) == hash(y)
True
The ip you instantiated the Network with is still accessible t
James Y Knight wrote:
> On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote:
>> Distributions should really not be put in charge of upstream
>> coding design decisions.
>
> I don't think you can blame distros for this one
>
> From PEP 0261:
> It is also proposed that one day --enable-unicode
On Mon, Sep 28, 2009 at 10:33 AM, Oleg Broytman wrote:
> On Mon, Sep 28, 2009 at 09:23:22AM -0600, m h wrote:
>
>> Does anyone else have interest in such functionality? Is it outside
>> the realm of this PEP?
>
> It is outside the scope of this particular PEP, but it is certainly an
> interesti
On Mon, Sep 28, 2009 at 07:28:39AM -0700, Steven Bethard wrote:
> Ok, sounds like there are a number of supporters for keeping getopt
> around and just deprecating optparse. For those who'd like to keep
> getopt around, I have a few questions:
>
> * Would you be opposed to a note in the getopt doc
On Mon, Sep 28, 2009 at 8:27 AM, Steven D'Aprano wrote:
> On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
>> * Would you like argparse to grow an add_getopt_arguments method (as
>> in my other post)?
>
> 0
>
>> * If argparse grew an add_getopt_arguments, would you still want to
>> keep getop
On Mon, Sep 28, 2009 at 8:56 AM, Guido van Rossum wrote:
> Hold it right there! That's wrong. You can't have two objects that
> compare equal but whose hashes differ. It will break dict lookup. The
> other way around is fine: two objects may differ and still have the
> same hash.
mm I never knew
On Mon, Sep 28, 2009 at 8:26 AM, Michael Foord
wrote:
> m h wrote:
>>
>> Perhaps this is OT, but since command line parsing is part of
>> configuration, I figure I'd throw it out there. My scripts often have
>> configuration that the command line can override and I loosely follow
>> the example h
On Sun, Sep 27, 2009 at 4:57 PM, 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 Mon, Sep 28, 2009 at 09:23:22AM -0600, m h wrote:
> Perhaps this is OT, but since command line parsing is part of
> configuration, I figure I'd throw it out there. My scripts often have
> configuration that the command line can override and I loosely follow
> the example hierarchy[0] listed in
On Tue, 29 Sep 2009 12:28:39 am Steven Bethard wrote:
> Ok, sounds like there are a number of supporters for keeping getopt
> around and just deprecating optparse. For those who'd like to keep
> getopt around, I have a few questions:
>
> * Would you be opposed to a note in the getopt documentation
m h wrote:
Perhaps this is OT, but since command line parsing is part of
configuration, I figure I'd throw it out there. My scripts often have
configuration that the command line can override and I loosely follow
the example hierarchy[0] listed in The Art of Unix Programming.
Some configuration
2009/9/28 Peter Moody :
>> That is, you've rejected the idea of having:
>>
> IPv4Network(192.168.1.1/24)
>> IPv4Network(192.168.1.0/24)
>
> yes, I and everyone have rejected that idea. this should either raise
> an error, or do what it does now, that is, return
> IPv4Network('192.168.1.1/24')
Perhaps this is OT, but since command line parsing is part of
configuration, I figure I'd throw it out there. My scripts often have
configuration that the command line can override and I loosely follow
the example hierarchy[0] listed in The Art of Unix Programming.
Some configuration I want in a
>
> * Would you be opposed to a note in the getopt documentation suggesting
> argparse as an alternative?
from the top of http://docs.python.org/library/getopt.html - "A more
convenient, flexible, and powerful alternative is the optparse module."I
think this statement should be emphasized better
On Sep 28, 2009, at 4:25 AM, M.-A. Lemburg wrote:
Distributions should really not be put in charge of upstream
coding design decisions.
I don't think you can blame distros for this one
From PEP 0261:
It is also proposed that one day --enable-unicode will just
default to the width o
On Mon, 28 Sep 2009 01:57:04 pm Martin v. Löwis wrote:
> >> 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 wa
M.-A. Lemburg wrote:
Antoine Pitrou wrote:
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.
You can add me to that cam
Antoine Pitrou wrote:
>
> 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.
You can add me to that camp as well:
+0 on
On Mon, Sep 28, 2009 at 9:35 AM, R. David Murray wrote:
> A little googling produced this hit:
>
>
> http://tools.ietf.org/wg/mip4/draft-ietf-mip4-nemo-v4-base/draft-ietf-mip4-nemo-v4-base-11-from-10.diff.txt
>
> which while not a standard itself clearly believes that non-contiguous
> netmasks are
Dj Gilcrease gmail.com> writes:
>
> >>> net1 = IPNetwork("10.1.2.3/24")
> >>> net2 = IPNetwork("10.1.2.0/24")
> >>> print hash(net1) == hash(net2)
> False
> >>> print net1 == net2
> True
Ouch :-)
It is very bad practice for equal objects to hash differently. Differing hashes
are supposed to impl
On Mon, Sep 28, 2009 at 3:42 PM, Dj Gilcrease wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the followin
On Mon, Sep 28, 2009 at 7:42 AM, Dj Gilcrease wrote:
> On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
> wrote:
>> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>>
>>> I should note that I've softened my position slightly from what I posted
>>> yesterday. I could live with the followin
Nick> +1 here as well (although we should definitely find a way to use
Nick> str.format strings instead of %-format ones... come to think of
Nick> it, does even the logging module support str.format style
Nick> formatting in Py3k?)
Assuming argparse currently works with versions o
On Mon, Sep 28, 2009 at 4:09 AM, Neal Becker wrote:
> If the plan is to migrate from optparse to argparse, this could be made a
> bit easier. If it weren't for the fact that some names are different in
> argparse than optparse, I believe many optparse usages could port with no
> change.
I could
On Mon, Sep 28, 2009 at 8:04 AM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, 28 Sep 2009 06:59:32 am Steven Bethard wrote:
> Why aren't getopt and optparse enough?
[snip]
As a newbie, I found optparse intimidating because it provided so many
features. I expect argparse will be the same, only more so.
(Disclaimer: I haven't used argparse, I'm merely making a pred
On Sun, 27 Sep 2009 at 10:06, David Moss wrote:
On 27 Sep 2009, at 07:56, "Martin v. L??wis" wrote:
I wouldn't ask for that: it should certainly be possible to supply
masks. However, I would want to reject masks that don't correspond to
a prefix, and have only the prefix length in the intern
On Mon, Sep 28, 2009 at 6:03 AM, Jon Ribbens
wrote:
> On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote:
>> On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
>> > -1 for deprecating getopt. getopt is super-simple and especially useful for
>> > c programmers learning
Mark Dickinson wrote:
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
I should note that I've softened my position slightly from what I posted
yesterday. I could live with the following compromise:
>>> x = IPv4Network('192.168.
On Mon, Sep 28, 2009 at 3:04 PM, Daniel Stutzbach
wrote:
> On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
>>
>> I should note that I've softened my position slightly from what I posted
>> yesterday. I could live with the following compromise:
>>
>> >>> x = IPv4Network('192.168.1.1/24')
>
On Mon, Sep 28, 2009 at 7:24 AM, Nick Coghlan wrote:
> I should note that I've softened my position slightly from what I posted
> yesterday. I could live with the following compromise:
>
>>>> x = IPv4Network('192.168.1.1/24')
>>>> y = IPv4Network('192.168.1.0/24')
> >>> x == y # Equal
Greg Ewing wrote:
> 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). Th
On Mon, Sep 28, 2009 at 5:34 AM, R. David Murray wrote:
> The fundamental divide here is between two behaviors.
>
> ipaddr:
>
> >>> x = IPv4Network('192.168.1.1/24')
> >>> y = IPv4Network('192.168.1.0/24')
> >>> x == y
> False
> >>> x.ip
> IPv4Address('192.168.1.1')
>
> desired:
On Mon, Sep 28, 2009 at 09:38:20AM +0100, Floris Bruynooghe wrote:
> On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
> > -1 for deprecating getopt. getopt is super-simple and especially useful for
> > c programmers learning python.
> >
> > +1 for argparse.+1 for eventual deprecati
On 03:57 am, mar...@v.loewis.de wrote:
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 wh
Antoine Pitrou wrote:
> Le Mon, 28 Sep 2009 06:41:17 +1000, Nick Coghlan a écrit :
>> Michael's response cut to the heart of the issue though - a richer IO
>> exception hierarchy can make life interesting for compatibility purposes
>> (especially when creating "file-like" interfaces to non-file obj
R. David Murray wrote:
> On Mon, 28 Sep 2009 at 07:34, R. David Murray wrote:
>> The fundamental divide here is between two behaviors.
>>
>> ipaddr:
>>
>>> > > x = IPv4Network('192.168.1.1/24')
>>> > > y = IPv4Network('192.168.1.0/24')
>>> > > x == y
>> False
>>> > > x.ip
>>
Steven Bethard wrote:
> I feel like I'm repeating the PEP, but here it is again anyway. There
> will be messages in the docs and pending deprecation warnings (which
> don't show up by default but can be requested) starting in Python 2.7
> and 3.2. Regular deprecation warnings wouldn't show up until
Doug Hellmann wrote:
>
> 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 argpar
Peter Moody wrote:
>> That is, you've rejected the idea of having:
>>
> IPv4Network(192.168.1.1/24)
>> IPv4Network(192.168.1.0/24)
>
> yes, I and everyone have rejected that idea. this should either raise
> an error, or do what it does now, that is, return
> IPv4Network('192.168.1.1/24')
Um,
On Mon, 28 Sep 2009 at 07:34, R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
> > > x = IPv4Network('192.168.1.1/24')
> > > y = IPv4Network('192.168.1.0/24')
> > > x == y
False
> > > x.ip
IPv4Address('192.168.1.1')
desired:
> > >
R. David Murray wrote:
The fundamental divide here is between two behaviors.
ipaddr:
>>> x = IPv4Network('192.168.1.1/24')
>>> y = IPv4Network('192.168.1.0/24')
>>> x == y
False
>>> x.ip
IPv4Address('192.168.1.1')
desired:
>>> x = IPv4Network('192.168.1.1/24')
On Mon, 28 Sep 2009 at 05:57, "Martin v. L?wis" wrote:
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.
Coul
Neal Becker wrote:
If the plan is to migrate from optparse to argparse, this could be made a
bit easier. If it weren't for the fact that some names are different in
argparse than optparse, I believe many optparse usages could port with no
change.
The new names in argparse fit with the fac
If the plan is to migrate from optparse to argparse, this could be made a
bit easier. If it weren't for the fact that some names are different in
argparse than optparse, I believe many optparse usages could port with no
change.
___
Python-Dev mailing
Greg Ewing wrote:
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
+-InvalidFileNameError (filepath max lengths, or "? / : " characters
in a windows file name...)
This might be a bit too precise. Unix just has EINVAL, which
covers any kind of invalid parameter, not just file names.
Allright thanks, an InvalidParameter (or similar) exception should do it
On Mon, Sep 28, 2009 at 06:59:45AM +0300, Yuvgoog Greenle wrote:
> -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 havin
M.-A. Lemburg wrote:
> Also note that Python will complain loudly when you try to load
> a UCS2 extension in a UCS4 build and vice-versa. We've made sure
> that any extension using the Python Unicode C API has to be built
> for the same UCS version of Python. This is done by using different
> names
Zooko O'Whielacronx wrote:
> Folks:
>
> I'm sorry, I think I didn't make my concern clear. My users, and lots
> of other users, are having a problem with incompatibility between
> Python binary extension modules. One way to improve the situation
> would be if the Python devs would use their "bul
Antoine Pitrou a écrit :
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 ca
90 matches
Mail list logo
