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
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 common,
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
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, including
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 single
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
Guido van Rossum guido at 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
2009/9/28 James Y Knight f...@fuhm.net:
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
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-archs=32-bit | tee
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
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
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 ints
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 wouldn't it be better
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou solip...@pitrou.net 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
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.
On Tue, Sep 29, 2009 at 1:00 PM, Guido van Rossum gu...@python.org wrote:
On Tue, Sep 29, 2009 at 9:03 AM, Antoine Pitrou solip...@pitrou.net
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,
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
On Tue, Sep 29, 2009 at 11:30 AM, Stephen J. Turnbull
step...@xemacs.org 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
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_FromUnicode
On Mon, Sep 28, 2009 at 20:44, Martin v. Löwis mar...@v.loewis.de 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
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
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
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
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 build a universal binary, defaulting to
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
On 6/30/07, Matt Chisholm matt-python at theory.org 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:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
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
On Tue, Sep 29, 2009 at 2:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
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
On Tue, Sep 29, 2009 at 1:20 PM, Hatem Nassrat hnass...@gmail.com wrote:
Tue Jul 3 10:14:17 CEST 2007, Guido van Rossum wrote:
On 6/30/07, Matt Chisholm matt-python at theory.org wrote:
I've created and submitted a new PEP proposing support for labels in
Python's break and continue
Paul Moore wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
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
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
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
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
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy tjre...@udel.edu 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
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 p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
1. There is no chance of the script killing itself. In argparse and
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
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
2009/9/29 Steven Bethard steven.beth...@gmail.com:
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
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
On Tue, Sep 29, 2009 at 3:04 PM, Glenn Linderman v+pyt...@g.nevcal.com 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
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
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 v+pyt...@g.nevcal.com wrote:
On approximately 9/29/2009 1:57 PM, came the following characters from the
keyboard of Steven Bethard:
If you're
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 argparse
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:
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 optparse.
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
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 a hint
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
Guido van Rossum wrote:
On Tue, Sep 29, 2009 at 2:05 PM, Terry Reedy tjre...@udel.edu 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
On Tue, Sep 29, 2009 at 5:54 PM, Benjamin Peterson benja...@python.org 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
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 this
On Tue, Sep 29, 2009 at 6:18 PM, Nick Coghlan ncogh...@gmail.com 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.
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
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 bound method
ThreadRunningTests.task of test.test_thread.ThreadRunningTests
testMethod=test_stack_size
Traceback
On Tue, Sep 29, 2009 at 9:30 PM, Barry Warsaw ba...@python.org 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
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 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
In article 760dc0c1-64ab-491e-8c7f-725724904...@python.org,
Barry Warsaw ba...@python.org 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:
On Tue, Sep 29, 2009 at 7:12 PM, R. David Murray rdmur...@bitdance.com 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
In article nad-265a22.19324229092...@news.gmane.org,
Ned Deily n...@acm.org wrote:
In article 760dc0c1-64ab-491e-8c7f-725724904...@python.org,
Barry Warsaw ba...@python.org 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
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 object you have
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?
What do you
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
In article 9d506035-7c2d-4929-a134-e88eeb7b7...@python.org,
Barry Warsaw ba...@python.org 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
On Tue, Sep 29, 2009 at 8:15 PM, Martin v. Löwis mar...@v.loewis.de 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:
Steven Bethard wrote:
On Tue, Sep 29, 2009 at 1:31 PM, Paul Moore p.f.mo...@gmail.com wrote:
2009/9/28 Yuvgoog Greenle ubershme...@gmail.com:
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
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,
65 matches
Mail list logo
