I'm resending a message I sent in June, since it seems the same thread
has come up again, and I don't believe anybody actually responded
(positively or negatively) to the suggestion back then.
http://mail.python.org/pipermail/python-dev/2009-June/090176.html
On Jun 21, 2009, at 5:40 PM, Eric
Steven Bethard wrote:
> On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
>> 2009/9/28 Yuvgoog Greenle :
>>> 1. There is no chance of the script killing itself. In argparse and optparse
>>> exit() is called on every parsing error (btw because of this it sucks to
>>> debug parse_args in an interpr
On Tue, Sep 29, 2009 at 8:15 PM, "Martin v. Löwis" wrote:
> Steven Bethard wrote:
>> Consider an example from the logging
>> docs:
>>
>> logging.Formatter("%(asctime)s - %(name)s - %(levelname)s - %(message)s")
>>
>> We'd like to support both this style as well as the following style:
>>
>> loggin
In article <9d506035-7c2d-4929-a134-e88eeb7b7...@python.org>,
Barry Warsaw wrote:
> On Sep 9, 2009, at 1:29 PM, Ned Deily wrote:
> > The recent release of OS X 10.6 (Snow Leopard) has triggered a fair
> > amount of 2.6 bug tracker activity, since 10.6 now includes 2.6
> > (2.6.1)
> > and a 64-b
Steven Bethard wrote:
> There's a lot of code already out there (in the standard library and
> other places) that uses %-style formatting, when in Python 3.0 we
> should be encouraging {}-style formatting.
I don't agree that we should do that. I see nothing wrong with using
% substitution.
> We
Peter Moody writes:
> > > this is interesting. I would be open to doing this and making __lt__,
> > > __gt__, __eq__ and friends do the non-ip comparing by default. would
> > > this be sufficient or does the fact that the network has the .ip
> > > attribute break something pythonic?
> >
Greg Ewing writes:
> Peter Moody wrote:
>
> > I've mentioned at least once (and others have mentioned as well) that
> > it's very common, when describing the ip address/prefix of a NIC to
> > write, "192.168.1.100/24"
>
> Yes, but if you want to *retain* all of that information,
> the obj
In article ,
Ned Deily wrote:
> In article <760dc0c1-64ab-491e-8c7f-725724904...@python.org>,
> Barry Warsaw wrote:
> > On Sep 29, 2009, at 9:43 PM, s...@pobox.com wrote:
> > > It's been awhile since I rebuilt Python and ran the test suite. This
> > > evening I noticed this on my Mac (OS X 10.
On Tue, Sep 29, 2009 at 7:12 PM, R. David Murray wrote:
> On Wed, 30 Sep 2009 at 11:07, Nick Coghlan wrote:
>>
>> At the risk of bikeshedding a bit, I'm still somewhat uncomfortable with
>> the "net.network" and "net.ip" attribute names. RDMs example application
>> elicited the reason for that dis
In article <760dc0c1-64ab-491e-8c7f-725724904...@python.org>,
Barry Warsaw wrote:
> On Sep 29, 2009, at 9:43 PM, s...@pobox.com wrote:
> > It's been awhile since I rebuilt Python and ran the test suite. This
> > evening I noticed this on my Mac (OS X 10.5):
It's not a new problem:
http://bugs.
On Wed, 30 Sep 2009 at 11:07, Nick Coghlan wrote:
At the risk of bikeshedding a bit, I'm still somewhat uncomfortable with
the "net.network" and "net.ip" attribute names. RDMs example application
elicited the reason for that discomfort pretty well: the current naming
seems like an invitation to w
On Sep 29, 2009, at 9:43 PM, s...@pobox.com wrote:
It's been awhile since I rebuilt Python and ran the test suite. This
evening I noticed this on my Mac (OS X 10.5):
What version of Python?
-Barry
PGP.sig
Description: This is a digitally signed message part
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw wrote:
> Maybe. I haven't been following this entire thread, but I don't see much
> point in making it easy to go from getopt to argparse.
I'm with you on this; specific getopt uses are more likely to be
switched to opt/argparse than to shift gradual
It's been awhile since I rebuilt Python and ran the test suite. This
evening I noticed this on my Mac (OS X 10.5):
test_thread
Unhandled exception in thread started by >
Traceback (most recent call last):
File "/Users/skip/src/python/trunk/Lib/test/test_thread.py", line 51, in
On Sep 29, 2009, at 9:18 PM, Nick Coghlan wrote:
Keeping getopt around *and* including a "add_getopt_arguments"
method in
argparse is probably the best of both worlds, in that it allows for
relatively straightforward evolution of an application:
1. Start with getopt
2. As the getopt argument
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan wrote:
> Keeping getopt around *and* including a "add_getopt_arguments" method in
> argparse is probably the best of both worlds, in that it allows for
> relatively straightforward evolution of an application:
>
> 1. Start with getopt
> 2. As the getop
Greg Ewing wrote:
> Paul Moore wrote:
>> I'd rather argparse (or any library function)
>> didn't call sys.exit on my behalf - it should raise an exception.
>
> Actually, sys.exit() *does* raise an exception (i.e.
> SystemExit) that you can catch if you want.
I was going to mention that. Between c
Barry Warsaw wrote:
> On Sep 29, 2009, at 8:25 PM, Nick Coghlan wrote:
>
>> getopt is very procedural - you define a minimal amount regarding the
>> options you accept, but then do the bulk of the command line processing
>> yourself
>
> Right, and we shouldn't underestimate the cognitive load thi
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson wrote:
> * Provide a flag to Formatter which controls whether new or old
> formatting is used. Emit a warning when it's not true.
So then the transition strategy is something like:
version N: Add formatting flag which uses {}-style formatting on
Guido van Rossum wrote:
> On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy wrote:
>> I do not think the cognitive load of .ip
>> on learning the module is any greater than having a third class, especially
>> if it is somewhat isolated in the doc as suggested below.
>
> Here I disagree. I want users t
On Sep 29, 2009, at 8:25 PM, Nick Coghlan wrote:
getopt is very procedural - you define a minimal amount regarding the
options you accept, but then do the bulk of the command line
processing
yourself
Right, and we shouldn't underestimate the cognitive load this
imposes. All those twisty
Martin v. Löwis 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 integer returned an
>> object that was compatible with other integers but somehow kept
Paul Moore wrote:
I'd rather argparse (or any library function)
didn't call sys.exit on my behalf - it should raise an exception.
Actually, sys.exit() *does* raise an exception (i.e.
SystemExit) that you can catch if you want.
--
Greg
___
Python-Dev
Greg Ewing wrote:
> s...@pobox.com wrote:
>> I have never completely wrapped my brain around optparse. Getopt I
>> just remember.
>
> Seems to me that optparse and argparse are fairly similar
> in their APIs, and that argparse isn't going to be significantly
> easier to fit in one's brain than op
There's a lot of code already out there (in the standard library and
other places) that uses %-style formatting, when in Python 3.0 we
should be encouraging {}-style formatting. We should really provide
some sort of transition plan. Consider an example from the logging
docs:
logging.Formatter("%(a
s...@pobox.com wrote:
> 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 argpars
On approximately 9/29/2009 4:38 PM, came the following characters from
the keyboard of Steven Bethard:
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman wrote:
On approximately 9/29/2009 1:57 PM, came the following characters from the
keyboard of Steven Bethard:
If you're not using argparse to
On Sep 29, 2009, at 6:51 PM, Greg Ewing wrote:
s...@pobox.com wrote:
I have never completely wrapped my brain around optparse. Getopt I
just remember.
Seems to me that optparse and argparse are fairly similar
in their APIs, and that argparse isn't going to be significantly
easier to fit in o
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman wrote:
> On approximately 9/29/2009 1:57 PM, came the following characters from the
> keyboard of Steven Bethard:
>> If you're not using argparse to write command line applications, then
>> I don't feel bad if you have to do a tiny bit of extra work
Peter Moody wrote:
I've mentioned at least once (and others have mentioned as well) that
it's very common, when describing the ip address/prefix of a NIC to
write, "192.168.1.100/24"
Yes, but if you want to *retain* all of that information,
the object you have isn't just a "network", it's more
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 functions.
2009/9/29 Steven Bethard :
> If you're not using argparse to write command line applications, then
> I don't feel bad if you have to do a tiny bit of extra work to take
> care of that use case. In this particular situation, all you have to
> do is subclass ArgumentParser and override exit() to do w
s...@pobox.com wrote:
I have never completely wrapped my brain around optparse. Getopt I
just remember.
Seems to me that optparse and argparse are fairly similar
in their APIs, and that argparse isn't going to be significantly
easier to fit in one's brain than optparse.
There's an art to comi
Steven D'Aprano wrote:
there's a mathematical operator called the mediant:
mediant(a/b, c/d) = (a+c)/(b+d)
That's a function of four arguments, not two!
--
Greg
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listin
On approximately 9/29/2009 1:57 PM, came the following characters from
the keyboard of Steven Bethard:
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
2009/9/28 Yuvgoog Greenle :
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing e
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy wrote:
>> this is interesting. I would be open to doing this and making __lt__,
>> __gt__, __eq__ and friends do the non-ip comparing by default. would
>> this be sufficient or does the fact that the network has the .ip
>> attribute break something pyth
This is my first post in this thread. I do not currently expect to
directly use ipaddr, but I am interested in Python having good modules
and a friendly development environment.
It strikes me that a module that meets the desiderata of broad community
support is going to have the 'baggage' of l
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 1. There is no chance of the script killing itself. In argparse and optparse
>> exit() is called on every parsing error (btw because of this it sucks to
>> debug parse_args in an interpreter).
>
> That one does wor
Paul Moore wrote:
2009/9/28 Yuvgoog Greenle :
1. There is no chance of the script killing itself. In argparse and optparse
exit() is called on every parsing error (btw because of this it sucks to
debug parse_args in an interpreter).
That one does worry me. I'd rather argparse (or any library f
On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat wrote:
> Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
>> On 6/30/07, Matt Chisholm wrote:
>> > I've created and submitted a new PEP proposing support for labels in
>> > Python's break and continue statements. Georg Brandl has graciously
>>
On Tue, Sep 29, 2009 at 2:31 PM, Paul Moore wrote:
> 2009/9/28 Yuvgoog Greenle :
>> 1. There is no chance of the script killing itself. In argparse and optparse
>> exit() is called on every parsing error (btw because of this it sucks to
>> debug parse_args in an interpreter).
>
> That one does wor
2009/9/28 Yuvgoog Greenle :
> 1. There is no chance of the script killing itself. In argparse and optparse
> exit() is called on every parsing error (btw because of this it sucks to
> debug parse_args in an interpreter).
That one does worry me. I'd rather argparse (or any library function)
didn't
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
> On 6/30/07, Matt Chisholm wrote:
> > I've created and submitted a new PEP proposing support for labels in
> > Python's break and continue statements. Georg Brandl has graciously
> > added it to the PEP list as PEP 3136:
> >
> > http://www.py
Ronald Oussoren wrote:
>
> On 29 Sep, 2009, at 18:17, M.-A. Lemburg wrote:
>
>> Ronald Oussoren wrote:
>>>
> Use:
>
> ./configure --enable-framework --enable-universalsdk=/
>
> The --with-universal-archs flag selects whichs architectures should be
> included when you bui
On Tue, 29 Sep 2009 at 15:24, R. David Murray wrote:
There's one place in this code where the inclusion of the 'ip' information
in the IPNetwork class could have been used. In the line that allows ICMP
traffic to the router's outside port, I could have written 'inside.ip'
instead of interfaces['
On Tue, 29 Sep 2009 at 14:19, Glyph Lefkowitz wrote:
In addition to the somebody-must-have-mentioned-this-already feeling that I
got, I hesitated to post this message because it doesn't actually seem that
important to me. While I'm firmly convinced that Network.ip is a design
mistake, it's not l
I'd like to include the patch for bug 3890 in Python 2.6.3. There is
a patch by Amaury that has gotten the blessing of Bill Janssen,
however the patch has no test.
Is there anybody who can come up with a test in the next few hours so
we can get this into 2.6.3rc1?
If not, is the fix impo
On Mon, Sep 28, 2009 at 20:44, "Martin v. Löwis" wrote:
>> 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
>> I've also encountered this trap multiple times. Obviously, the problem
>> is not rebuilding Python which is quick, but to figure out the correct
>> configure option to use (--enable-unicode=ucs4). Others have also
>> spent some time scratching their heads over the strange
>> PyUnicodeUCS4_FromUn
On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull
wrote:
> Let me first say that the module is overall quite nice; the
> implementation seems concise and very efficient, and the API is
> well-balanced. I'm sorry there's been such controversy (and for my
> part in it, as I managed to completel
Let me first say that the module is overall quite nice; the
implementation seems concise and very efficient, and the API is
well-balanced. I'm sorry there's been such controversy (and for my
part in it, as I managed to completely misunderstand what you
absolutely require), when AFAICT the only "li
On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum wrote:
> On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou
> wrote:
>
> You say it yourself : it describes "the ip address/prefix of a NIC".
> > It isn't the job of a Network class. A Network shouldn't describe a
> > host, or a particular NIC.
>
>
Dear MAL and python-dev:
I failed to explain the problem that users are having. I will try
again, and this time I will omit my ideas about how to improve things
and just focus on describing the problem.
Some users are having trouble using Python packages containing binary
extensions on Linux. I
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou wrote:
>
>> I've mentioned at least once (and others have mentioned as well) that
>> it's very common, when describing the ip address/prefix of a NIC to
>> write, "192.168.1.100/24"
>
> You say it yourself : it describes "the ip address/prefix of a N
On 29 Sep, 2009, at 18:17, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
Use:
./configure --enable-framework --enable-universalsdk=/
The --with-universal-archs flag selects whichs architectures
should be
included when you build a universal binary, defaulting to 32-bit.
The Python defa
Ronald Oussoren wrote:
>
>>> Use:
>>>
>>>./configure --enable-framework --enable-universalsdk=/
>>>
>>> The --with-universal-archs flag selects whichs architectures should be
>>> included when you build a universal binary, defaulting to 32-bit.
>>
>> The Python default on 10.6 is 64-bit, so wo
Responding to a few points here. David and I were discussing these
points off-list, I didn't mean to ignore.
re: assumed disconnect between the statement "Addresses and Networks
are distinct" and the implementation.
I don't actually see a disconnect. it seems analogous to stating
lists and int
> I've mentioned at least once (and others have mentioned as well) that
> it's very common, when describing the ip address/prefix of a NIC to
> write, "192.168.1.100/24"
You say it yourself : it describes "the ip address/prefix of a NIC".
It isn't the job of a Network class. A Network shouldn't d
On 29 Sep, 2009, at 17:28, M.-A. Lemburg wrote:
Ronald Oussoren wrote:
On 26 Sep, 2009, at 14:46, 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:
./configure --enable-
Hello,
> I've also encountered this trap multiple times. Obviously, the problem
> is not rebuilding Python which is quick, but to figure out the correct
> configure option to use (--enable-unicode=ucs4). Others have also
> spent some time scratching their heads over the strange
> PyUnicodeUCS4_Fro
Ronald Oussoren wrote:
>
> On 26 Sep, 2009, at 14:46, 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:
>>
>> ./configure --enable-framework --with-universal-arc
2009/9/28 James Y Knight :
>> People building their own Python version will usually also build
>> their own extensions, so I don't really believe that the above
>> scenario is very common.
>
> I'd just like to note that I've run into this trap multiple times. I built a
> custom python, and expected
Guido van Rossum python.org> writes:
>
> All in all I think we should change this before it's too late; it will
> affect a very small number of apps (perhaps none?), but I would rather
> have the right semantics in the future. Also, it's trivial to write
> code that doesn't care (in fact code run
Ronald> I'll write some documentation on the build options on OSX, but
Ronald> don't know what's the best location to do so.
The top-level README file of the distribution has a "Platform specific
notes" section. Seems like that would be the most logical place to stuff
such info.
Skip
__
Martin> alpha = None
Martin> beta = False
Martin> options, args = getopt.getopt(sys.argv[1:],"a:b",['alpha=','beta']):
Martin> for opt, val in options:
...
Martin> Even though this is many more lines, I prefer it over
Martin> optparse/argparse: this code has only a sing
On Tue, 29 Sep 2009 01:18:43 pm Guido van Rossum wrote:
> I've never heard of someone who had a use case for
> denormalized fractions
Off-topic, but for what it's worth, I have one -- there's a mathematical
operator called the mediant:
mediant(a/b, c/d) = (a+c)/(b+d)
It has a few uses, includin
On 26 Sep, 2009, at 14:46, 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:
./configure --enable-framework --with-universal-archs=32-bit | tee
build.config.log
make
Guido van Rossum writes:
> I don't doubt that Peter has a use case for denormalized IPNetwork
> objects.
If you know what it is, would you please describe it, or say "that's
proprietary"? Peter hasn't done either, despite repeated requests.
> I do note that if Peter's use case is at all comm
68 matches
Mail list logo
