Re: [Python-Dev] PEP 3144 review.
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 interesting to know what his use case is. Maybe it can be addressed in a different way that doesn't require denormalised network objects. my sometimes it would be useful was meant as a gentle nudge in the direction of keeping the .ip attribute. I think the point is that it would have to be useful a *lot* of the time, not just sometimes, to be worth having it on every IPNetwork object. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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, reducing the number of classes is a worthy goal, and Python has a bit of a history of preferring a small number of Swiss-army-knife classes over a multitude of simple classes. Even if Peter's use case turns out to be at all common, two things bother me a lot. First, IPv4Network(a) == IPv4Network(b) has an obvious preferred interpretation as pseudocode. Second, equality comparison for the abuse of a network class to represent host-with-network-info can be implemented cleanly[1] as x = IPv4Network(a) y = IPv4Network(b) (x.ip, x) == (y.ip, y) as you've pointed out. It is self-documenting in that makes it plain that some things that are not true networks are being compared. OTOH, x = IPv4Network(a) y = IPv4Network(b) (x.network, x.prefixlen) == (y.network, y.prefixlen) # alternatively # list(x) == list(y) looks like nothing so much as an incomplete implementation to me. It just makes me itch to provide the appropriate definitions of __hash__ and __equal__ for IPv4Network. Do you feel differently? Footnotes: [1] It's clean only if we assume you've accepted the abuse, of course. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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 clean all | tee build.make.log I end up with a x86_64 Python image. No matter what I use for archs its always the same. I would expect to see -arch arg to GCC but it is not there. export CFLAG=-arch i386 did not work either. Am I doing something wrong or is this broken on trunk? 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. I'll write some documentation on the build options on OSX, but don't know what's the best location to do so. I guess I should also add logic to configure that bails out when you specifiy --with-universal-archs without asking for a universal build. Ronald Barry ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] [OT] Denormalized fractions [was Re: PEP 3144 review.]
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 Farey fractions. Clearly the result you get from normalized fractions will be different from denormalized (compare mediant(1/2, 3/4) with mediant(5/10, 3/4)). This leads to Simpson's Paradox, which is of importance in medical research: http://en.wikipedia.org/wiki/Simpson's_paradox Brief summary: consider two medical studies comparing two different treatments for an illness, treatment A and B. According to the first study, treatment A is better; according to the second study, treatment A is also better. But combining the results of the two studies into a single comparison paradoxically shows that treatment B is better! The mediant is fascinating (to maths geeks at least) and important, and you need denormalized fractions. -- Steven D'Aprano ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 function call, ... Agreed. I have never completely wrapped my brain around optparse. Getopt I just remember. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Fuzziness in io module specs - PEP update proposition V2
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 running under 2.x and 3.x probably will have to be written so that it doesn't care) so it's not like changing this is going to make life harder for people wanting multiple-version support. Ok, it sounds reasonable to me :) Now somebody just has to write a patch (it shouldn't be too difficult, since the position restoring code exists in the 2.x file object). Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please consider changing --enable-unicode default to ucs4
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 expected it to work with all the existing, installed, extensions (same major version as the system install, just patched). And then had to build it again with UCS4, for it to actually work. Of course building twice isn't the end of the world, and I'm certainly used to having to twiddle build options on software to get it working, but, this *does* happen, and *is* a tiny bit irritating. 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 error the misconfiguration results in, as Zooko's links show. If Python can't infer the unicode setting from the width of the platforms wchar_t, then perhaps it should be mandatory to specify to configure whether you want UCS2 or UCS4? For someone clueless like me, it would be easier to deal with the problem upfront than (much) further down the line. Explicit being better than implicit and all that. -- mvh Björn ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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 build.config.log make clean all | tee build.make.log I end up with a x86_64 Python image. No matter what I use for archs its always the same. I would expect to see -arch arg to GCC but it is not there. export CFLAG=-arch i386 did not work either. Am I doing something wrong or is this broken on trunk? 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 to default to that on 10.6 and use 32-bit as default on 10.3/4/5 ?! I'll write some documentation on the build options on OSX, but don't know what's the best location to do so. Please put that information into Mac/README which already has documentation for how to build universal binaries on Mac. I guess I should also add logic to configure that bails out when you specifiy --with-universal-archs without asking for a universal build. That would be useful. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please consider changing --enable-unicode default to ucs4
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_FromUnicode error the misconfiguration results in, as Zooko's links show. Isn't this overrated? First, if you have a Python version that has the wrong version, just print out its sys.maxunicode and choose the right version according to that (if sys.maxunicode == 65535, you need to compile an UCS-4 version, otherwise an UCS-2 version). Second, once you have encountered this issue, you know what you need the subsequent times. There are only two possibilities after all. If Python can't infer the unicode setting from the width of the platforms wchar_t, then perhaps it should be mandatory to specify to configure whether you want UCS2 or UCS4? For someone clueless like me, it would be easier to deal with the problem upfront than (much) further down the line. I'm not sure why someone clueless (your word :-)) wants to compile his own Python, though. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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-framework --with-universal-archs=32-bit | tee build.config.log make clean all | tee build.make.log I end up with a x86_64 Python image. No matter what I use for archs its always the same. I would expect to see -arch arg to GCC but it is not there. export CFLAG=-arch i386 did not work either. Am I doing something wrong or is this broken on trunk? 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 to default to that on 10.6 and use 32-bit as default on 10.3/4/5 ?! Defaulting to a 32-bit build has several advantages. The first is that the defaults match the binary installer on the python.org website, and secondly there are still 3th-party libraries that don't work in 64-bit mode (mostly GUI libraries, until recently Tk and wxWidgets wrapped the Carbon libraries which are not available in 64-bit mode; AFAIK both have betas that wrap the Cocoa libraries instead). To mimick the system default you'd have to default to 32-bit on 10.4, 4-way universal on 10.5 and 3-way universal on 10.6, and that is without considering deployment targets. All of those are available as options, I'd prefer to keep it this way for now to keep things simple. I'll write some documentation on the build options on OSX, but don't know what's the best location to do so. Please put that information into Mac/README which already has documentation for how to build universal binaries on Mac. I know that, I wrote most of that file ;-). I guess I should also add logic to configure that bails out when you specifiy --with-universal-archs without asking for a universal build. That would be useful. I've committed a patch to the trunk and 2.6 that does this. Ronald -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2009) Python/Zope Consulting and Support ...http:// www.egenix.com/ mxODBC.Zope.Database.Adapter ... http:// zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http:// python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ smime.p7s Description: S/MIME cryptographic signature ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 are distinct yet lists can still contain ints. networks and addresses are distinct and yet networks contain addresses. re: denormalized networks: 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 re: new comparison methods 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? Cheers, /peter On Mon, Sep 28, 2009 at 1:43 PM, Guido van Rossum gu...@python.org wrote: On Mon, Sep 28, 2009 at 1:36 PM, R. David Murray rdmur...@bitdance.com wrote: On Mon, 28 Sep 2009 at 22:11, Martin v. Löwis wrote: Martin v. Löwis martin at 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 would I want to specify a network as 192.168.1.1/24 instead of 192.168.1.0/24? [...] So Python code has to make the computation, and it seems most natural that the IP library is the piece of code that is able to compute a network out of that input. The thing is, it doesn't create a network, it creates a hybrid network plus host which retains knowledge about the original host (that is, 192.168.1.1 rather than simply 192.168.1.0, if you enter 192.168.1.1/24). That's what the OP meant with networks-that-aren't-networks, and that's what people are objecting to. 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 its network address. But then it's not a network, it is an ipaddress-plus-mask. It is exactly that conflation that we are objecting to. There is no question about the use case of _specifying_ a network ip plus a netmask and deriving a network object from that. That is unquestionably required by any useful API. The argument is about whether the object returned is a Network object, or a hybrid object representing _both_ an IP address and a network. It is the latter, which ipaddr does, which many of us find problematic and likely to lead to hard to read programs that will probably produce maintenance errors. I observe that this line in the current PEP rationale: IP addresses and IP networks are distinct. is not in fact achieved by the reference implementation. Peter, however, clearly thinks it is, since it is listed as a design goal of ipaddr. This is a language disconnect I don't understand, which I think has been the source of a lot of the difficulties in this thread. I say the case has been argued extensively, let's wait for Peter to respond. 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 printing it to use hex by default. I see keeping around the IP address used to create a network object as a similar edge case. I would probably define the __eq__ method to implement equivalency (ignoring the form of the input), just as I would in the case of the (hypothetical) hex integers. If you wanted to do a comparison that includes the input IP address, you could use (a, a.ip) == (b, b.ip). -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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 to default to that on 10.6 and use 32-bit as default on 10.3/4/5 ?! Defaulting to a 32-bit build has several advantages. The first is that the defaults match the binary installer on the python.org website, What build options does that installer use ? (the web-page doesn't say) and secondly there are still 3th-party libraries that don't work in 64-bit mode (mostly GUI libraries, until recently Tk and wxWidgets wrapped the Carbon libraries which are not available in 64-bit mode; AFAIK both have betas that wrap the Cocoa libraries instead). To mimick the system default you'd have to default to 32-bit on 10.4, 4-way universal on 10.5 and 3-way universal on 10.6, and that is without considering deployment targets. All of those are available as options, I'd prefer to keep it this way for now to keep things simple. Hmm, so I guess the only way to support them all is by building extensions using 4-way universal on 10.5. No wonder they are called fat binaries ;-) I'll write some documentation on the build options on OSX, but don't know what's the best location to do so. Please put that information into Mac/README which already has documentation for how to build universal binaries on Mac. I know that, I wrote most of that file ;-). Which is why I was surprised you asked :-) I guess I should also add logic to configure that bails out when you specifiy --with-universal-archs without asking for a universal build. That would be useful. I've committed a patch to the trunk and 2.6 that does this. Thanks. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 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. Hey Antoine, Can we drop the pedantic discussion about what should or shouldn't be the job of a Network class, and just proceed to a pragmatic compromise? Peter has already posted that he is okay with __eq__ and friends ignoring the .ip attribute, which sounds good enough to me. His use case (which he mentioned to me off-list) is simply that if the denormalized .ip attribute weren't saved as part of the IPNetwork class, in many cases he'd have to keep track of it separately, which just feels clumsy. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please consider changing --enable-unicode default to ucs4
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 want to provide such binary Python packages for Linux for the pycryptopp project (http://allmydata.org/trac/pycryptopp ) and the zfec project (http://allmydata.org/trac/zfec ). I also want to make it possible for users to install the Tahoe-LAFS project (http://allmydata.org ) without having a compiler or Python header files. (You'd be surprised at how often Tahoe-LAFS users try to do this on Linux. Linux is no longer only for people who have the knowledge and patience to compile software themselves.) Tahoe-LAFS also depends on many packages that are maintained by other people and are not packaged or distributed by me -- pyOpenSSL, simplejson, etc.. There have been several hurdles in the way that we've overcome, and no doubt there will be more, but the current hurdle is that there are two formats for Python extension modules that are used on Linux -- UCS2 and UCS4. If a user gets a Python package containing a compiled extension module which was built for the wrong UCS2/4 setting, he will get mysterious (to him) undefined symbol errors at import time. On Mon, Sep 28, 2009 at 2:25 AM, M.-A. Lemburg m...@egenix.com wrote: The Python default is UCS2 for a good reason: it's a good trade-off between memory consumption, functionality and performance. I'm sure you are right about this. At some point I will try to measure the performance implications in the context of our application. I don't think it will be an issue for us, as so far no users have complained about any performance or functionality problems that were traceable to the choice of UCS2/4. As already mentioned, I also don't understand how the changing the Python default on Linux would help your users in any way - if you let distutils compile your extensions, it's automatically going to use the right Unicode setting for you (as well as your users). My users are using some Python packages built by me and some built by others. The binary packages they get from others could have the incompatible UCS2/4 setting. Also some of my users might be using a python configured with the opposite setting of the python interpreter that I use to build packages. Unfortunately, this automatic support doesn't help you when shipping e.g. setuptools eggs, but this is a tool problem, not one of Python: setuptools completely ignores the fact that there are two ways to build Python. This is the setuptools/distribute issue that I mentioned: http://bugs.python.org/setuptools/issue78 . If that issue were solved then if a user tried to install a specific package, for example with a command-line like easy_install http://allmydata.org/source/tahoe/deps/tahoe-dep-eggs/pyOpenSSL-0.8-py2.5-linux-i686.egg;, then instead of getting an undefined symbol error at import time, they would get an error message to the effect of This package is not compatible with your Python interpreter. at install time. That would be good because it would be less confusing to the users. However, if they were using the default setuptools/distribute dependency-satisfaction feature, e.g. because they are installing a package and that package is marked as install_requires=['pyOpenSSL'], then setuptools/distribute would do its fallback behavior in which it attempts to compile the package from source when it can't find a compatible binary package. This would probably confuse the users at least as much as the undefined symbol error currently does. In any case, improving the tools to handle incompatible packages nicely would not make more packages compatible. Let's do both! Improve tools to handle incompatible packages nicely, and encourage everyone who compiles python on Linux to use the same UCS2/4 setting. Thank you for your attention. Regards, Zooko ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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, or a particular NIC. Hey Antoine, Can we drop the pedantic discussion about what should or shouldn't be the job of a Network class, and just proceed to a pragmatic compromise? Peter has already posted that he is okay with __eq__ and friends ignoring the .ip attribute, which sounds good enough to me. His use case (which he mentioned to me off-list) is simply that if the denormalized .ip attribute weren't saved as part of the IPNetwork class, in many cases he'd have to keep track of it separately, which just feels clumsy. I apologize in advance for missing a message that answers my question; I've done my best to read all the related traffic in the various threads that discuss this, but I'm sure I missed something. I don't see what's particularly pragmatic, in terms of functionality, about confusing the responsibility of the Network class. Networks don't have addresses, in the sense that is being discussed here. Allowing them to have an IP presents a misleading model, and will encourage applications to be passing around networks where they should be passing around hosts. And yes, the discussion is pedantic, in that some people are certain to learn about the model of IP networking by reading the documentation of this module if it gets into the stdlib. I personally learned all about async networking from reading the asyncore, select, and socket modules in python 1.5.2, lo these many years past. The discussion seems to be centered around the inconvenience of adding a separate IPNetworkWithHost class that can encapsulate both of these things. Peter seems to think that this is hugely inconvenient, but classes are cheap. If we were talking about IPNetwork.from_string() instead of IPNetwork(), it seems to me that it would even be acceptable for it to return a IPNetwork subclass if the address were not canonical (i.e. without the bits already masked off and zeroed). Perhaps there should be such a method, or even just a free function, parse_mask(), as that would allow for dealing with other user-input use-cases that have been brought up in this thread. I don't understand why we can't just add that class and make everybody happy. IPNetwork could even have a .canonicalize() method which would return itself, and the subclass implementation in IPNetworkWithHost return the corresponding IPNetwork. (I wish I could come up with a better name, but I certainly agree that there are cases where a IPNetworkWithHost is what I would want.) 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 like the rest of Python, or for that matter any software, is completely perfect. In fact I think this mistake is significantly less bad than some of the others already present in Python. If Peter remains unconvinced, I do think that we should put it in the stdlib, move on, and get to fixing some of the other stuff we agree needs fixing rather than continuing to re-hash this. Primarily because, as far as I can tell, if hashing and equality are defined the way that everyone seems to be agreeing they be defined (ignoring the .ip attribute) then those of us who think .ip is a design error can use the library and safely ignore it completely. So, I promise not to contribute further to the problem; I won't post again in this thread against someone who is actually going to do some work here wants to solicit a clarification of my opinion or some more ideas :). ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 line in the sand is being drawn around the semantics of net1 == net2. Peter Moody writes: I don't actually see a disconnect. it seems analogous to stating lists and ints are distinct yet lists can still contain ints. networks and addresses are distinct and yet networks contain addresses. AIUI, the disconnect is that lists do not contain a distinguished element such that if that element differs, the lists differ. Ie, the disconnect is the very presence of the .ip attribute in IPv?Network. ISTM that all of the vehement opposition is related to this single feature. re: denormalized networks: 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 Please be careful to distinguish between denormalized descriptions of networks (strings like your example above) and denormalized network objects (ie, objects where net.ip != net.network). I'm happy with the former, with a slight preference for a separate method to do the parsing, as in Antoine's proposal. The latter makes me unhappy, but I'll deal with that simply by refusing to use that feature (see below). re: new comparison methods 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 mean, by default? Surely you don't mean an equality method with some sort of flag!? Personally I want net1 == net2 to have the same value as (net1.network, net1.prefixlen) == (net2.network, net2.prefixlen) when net1 and net2 are IPv?Networks, period. For me, this is the only sticking point; if it's not true, I'll never use this module, and I'd oppose adding it to stdlib. I don't care if the .ip attribute *exists* (and I don't care if you provide separate .denormalized_compare() methods) but I find the presence of .ip in IPv?Network objects counterintuitive. Enough so that if I need such an object, I will create a new class (with a name that expresses its purpose to me) to manage it in my app, if such a class isn't provided by ipaddr.py. That would be no great burden to me since AFAICS apps that need such behavior are quite specialized. In any case, it seems that many developers (you, GvR, and MvL, at least) aren't bothered by overloading the IPv?Network class as you do in ipaddr.py. (In fact, IIUC you don't even see using it for denormalized networks as overloading.) I see no point in getting in your way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 managed to completely misunderstand what you absolutely require), when AFAICT the only line in the sand is being drawn around the semantics of net1 == net2. Peter Moody writes: I don't actually see a disconnect. it seems analogous to stating lists and ints are distinct yet lists can still contain ints. networks and addresses are distinct and yet networks contain addresses. AIUI, the disconnect is that lists do not contain a distinguished element such that if that element differs, the lists differ. Ie, the disconnect is the very presence of the .ip attribute in IPv?Network. ISTM that all of the vehement opposition is related to this single feature. re: denormalized networks: 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 Please be careful to distinguish between denormalized descriptions of networks (strings like your example above) and denormalized network objects (ie, objects where net.ip != net.network). I'm happy with the former, with a slight preference for a separate method to do the parsing, as in Antoine's proposal. The latter makes me unhappy, but I'll deal with that simply by refusing to use that feature (see below). re: new comparison methods 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 mean, by default? Surely you don't mean an equality method with some sort of flag!? no, I mean setting it up so that if I want to compare two network objects and take into account their .ip attribute, that I use a .compare_with_extra_bits() method or something. __eq__, __ne__, __lt__, __le__, __gt__, __ge__ (any more?) would all only compare .network and .prefixlen (as you have in your example). Cheers, /peter Personally I want net1 == net2 to have the same value as (net1.network, net1.prefixlen) == (net2.network, net2.prefixlen) when net1 and net2 are IPv?Networks, period. For me, this is the only sticking point; if it's not true, I'll never use this module, and I'd oppose adding it to stdlib. I don't care if the .ip attribute *exists* (and I don't care if you provide separate .denormalized_compare() methods) but I find the presence of .ip in IPv?Network objects counterintuitive. Enough so that if I need such an object, I will create a new class (with a name that expresses its purpose to me) to manage it in my app, if such a class isn't provided by ipaddr.py. That would be no great burden to me since AFAICS apps that need such behavior are quite specialized. In any case, it seems that many developers (you, GvR, and MvL, at least) aren't bothered by overloading the IPv?Network class as you do in ipaddr.py. (In fact, IIUC you don't even see using it for denormalized networks as overloading.) I see no point in getting in your way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] please consider changing --enable-unicode default to ucs4
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 error the misconfiguration results in, as Zooko's links show. Isn't this overrated? First, if you have a Python version that has the wrong version, just print out its sys.maxunicode and choose the right version according to that (if sys.maxunicode == 65535, you need to compile an UCS-4 version, otherwise an UCS-2 version). To do so, you have to know that there is such a configuration option in the first place, and that the error message you get (missing symbols) has anything to do with it. This is quite puzzling to users. Once people know what the problem is, fixing it is indeed easy. I'm not sure why someone clueless (your word :-)) wants to compile his own Python, though. People install a lot of software that they don't understand. In fact, most people who ever install software don't know how it is written, and cannot enumerate the meaning of all configuration options that the software possesses. In Unix, there is a long tradition that installing software means building from source; if you have a configure script, you expect that it either works out of the box, or gives an error message if it finds that something is wrong with the environment. So it is quite normal that people who don't understand how the Python interpreter works (or that it has a Unicode type) install Python. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 you could do::
options, args = getopt.getopt(sys.argv[1:], a:b, [alpha=, beta])
options_dict = dict(options)
alpha = options_dict.get('-a', options_dict.get('--alpha', ''))
beta = '-b' in options_dict or '--beta' in options_dict
main(alpha, beta, args)
Obviously if one of the getopt supporters has a better way of doing
this then please speak up.
As Yuvgoog Greenle says, the canonical getopt way is to write
alpha = None
beta = False
options, args = getopt.getopt(sys.argv[1:],a:b,['alpha=','beta']):
for opt, val in options:
if arg in ('-a','--alpha'):
alpha = val
elif arg in ('-b','--beta'):
beta = True
main(alpha, beta, args)
Even though this is many more lines, I prefer it over
optparse/argparse: this code has only a single function call,
whereas the argparse version has three function calls to remember.
The actual processing uses standard Python data structures which
I don't need to look up in the documentation.
Now, Steven, can you show how best to do this in argparse?
This demonstrates my point: you were able to use getopt right away
(even though not in the traditional way), whereas you need to ask
for help on using argparse properly.
Actually, I had to read the docs for getopt. And I chose to not even
try argparse when the creator of the module is cc'ed on the email and
can obviously do a better example using his own code then I could.
-Brett
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] bug 3890
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 important enough to include without the test? -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 like the rest of Python, or for that matter any software,
is completely perfect. In fact I think this mistake is significantly less
bad than some of the others already present in Python. If Peter remains
unconvinced, I do think that we should put it in the stdlib, move on, and
get to fixing some of the other stuff we agree needs fixing rather than
continuing to re-hash this. Primarily because, as far as I can tell, if
hashing and equality are defined the way that everyone seems to be agreeing
they be defined (ignoring the .ip attribute) then those of us who think .ip
is a design error can use the library and safely ignore it completely.
I think Glyph is petty much on target here. I think I dislike the .ip
attribute more than he does, but I'm willing to let go of it now
that the equality issue has been addressed so that the class acts
like a Network object _except_ for the ip attribute.
I do want to show why I think the ip attribute is a bad idea, using
a concrete example, rather than the hand waving we've done up to this
point. This is a stripped down example of something that could be a
real application. I started writing this to show what the difference
between using the ipaddr classes versus the completely separate address
and network classes would look like, but ended up with something where
there would be very little difference in the final program.
Given this simple configuration file:
demo.ini
--
[gatewayrouter]
inside = e1/0 192.168.1.1/24
outside = e1/1 172.16.200.1/23
dmz = e1/2 192.168.2.1/24
[dmzhosts]
webserver = 172.16.200.2 192.168.2.30 22 80 442
mailserver = 172.16.200.3 182.168.2.31 22 25 587
--
Here is a (runable) program to generate the skeleton of a Cisco router
configuration file from that configuration (I've left out a bunch
of additinoal Cisco configuration I'd include if this were a real
application):
--
import ipaddr
import ConfigParser
config = ConfigParser.SafeConfigParser()
config.read('demo.ini')
output = open('gatewayrouter.config', 'w')
class InterfaceData(object):
def __init__(self, interfacespec):
self.interfacename, ipwithnetmask = interfacespec.split()
self.network = ipaddr.IPv4Network(ipwithnetmask)
self.ip = self.network.ip
self.netmask = self.network.netmask
class DMZHost(object):
def __init__(self, hostdata):
data = hostdata.split()
outsideip, insideip = data[0:2]
self.ports = data[2:]
self.outsideip = ipaddr.IPv4Address(outsideip)
self.insideip = ipaddr.IPv4Address(insideip)
interfaces = {}
for name in ('inside', 'outside', 'dmz'):
interfacedata = InterfaceData(config.get('gatewayrouter', name))
interfaces[name] = interfacedata
globals()[name] = interfacedata.network
dmzhosts = {}
for host, hostdata in config.items('dmzhosts'):
dmzhosts[host] = DMZHost(hostdata)
for idata in interfaces.values():
print output, 'interface {}'.format(idata.interfacename)
print output, 'ip address {} {}'.format(idata.ip, idata.netmask)
print output, 'ip extended access-list outside_in'
for host in dmzhosts.values():
for port in host.ports:
print output, 'permit ip any host {} eq {}'.format(
host.outsideip, port)
for icmp in ('echo', 'echo-reply', 'host-unreachable', 'time-exceeded'):
print output, 'permit icmp any host {} {}'.format(
interfaces['inside'].ip, icmp)
print output, 'permit icmp any {} {} {}'.format(
dmz.network, dmz.hostmask, icmp)
print output, 'ip extended access-list nat'
print output, 'permit ip {} {} any'.format(inside.network, inside.hostmask)
print output, 'permit ip {} {} any'.format(dmz.network, dmz.hostmask)
print output, ('ip nat inside source access-list nat '
'interface {} overload').format(interfaces['outside'].interfacename)
for host in dmzhosts.values():
print output, 'ip nat inside source static {} {}'.format(
host.insideip, host.outsideip)
--
There are several things to note about this code. The first is that I
wanted my own wrapper classes to deal with the data, IPv4Network/Address
by themselves weren't enough, nor would an IPWithNetmask class have been.
I also notice that I immediately pulled out the 'ip' address from the
IPv4Network object to a top level attribute in my wrapper, so for me
a ParseIPWithMask that returned separate IPAddress and an IPNetwork
classes would have been more natural. On the other hand, I also
Re: [Python-Dev] PEP 3144 review.
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['inside'].ip. I think that would have confused me when I came back to read the code later, though, since 'inside' is otherwise a network object. Er, that should have been 'outside' in both the code and the paragraph above, of course. Which would also have run but produced incorrect output...make of that what you will :) --David ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.7 Mac universal builds seem broken on trunk
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 32-bit. The Python default on 10.6 is 64-bit, so wouldn't it be better to default to that on 10.6 and use 32-bit as default on 10.3/4/5 ?! Defaulting to a 32-bit build has several advantages. The first is that the defaults match the binary installer on the python.org website, What build options does that installer use ? (the web-page doesn't say) The installer is build using the script in Mac/BuildScript, and uses --enable-framework --with-universalsk. This creates a 32-bit fat build that runs on 10.3.9 or later. Ok, so the installed has 32-bit x86 and ppc code, just like for the older releases. and secondly there are still 3th-party libraries that don't work in 64-bit mode (mostly GUI libraries, until recently Tk and wxWidgets wrapped the Carbon libraries which are not available in 64-bit mode; AFAIK both have betas that wrap the Cocoa libraries instead). To mimick the system default you'd have to default to 32-bit on 10.4, 4-way universal on 10.5 and 3-way universal on 10.6, and that is without considering deployment targets. All of those are available as options, I'd prefer to keep it this way for now to keep things simple. Hmm, so I guess the only way to support them all is by building extensions using 4-way universal on 10.5. No wonder they are called fat binaries ;-) I like the technology though, much more convenient than having parallel directory tries as on Linux. True, but it also makes it harder to get rid off parts you don't need and the often necessary separate combine step (using lipo) can get tedious at times, e.g. when trying to build OpenSSL or other software that uses different configuration data or optimizations depending on the underlying architecture. I'll write some documentation on the build options on OSX, but don't know what's the best location to do so. Please put that information into Mac/README which already has documentation for how to build universal binaries on Mac. I know that, I wrote most of that file ;-). Which is why I was surprised you asked :-) I hoped to find a document on docs.python.org that explains how to install Python, but sadly enough there isn't. Mac/README contains the right information, but isn't easily found if you're searching on the web or even if you're looking for documentation in the source tree. True. The download page used to have a bit of information on how to build Python, but that got trimmed away it seems. The Python docs only have this page: Unix: http://docs.python.org/using/unix.html Window: http://docs.python.org/using/windows.html#installing-python Mac: http://docs.python.org/using/mac.html#getting-and-installing-macpython Neither of those pages has the in-depth information of the README files and, frankly, I wouldn't be looking for an installation guide in a Using Python section either. Perhaps something for a sprint to change... -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 29 2009) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Announcing PEP 3136
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: http://www.python.org/dev/peps/pep-3136/ I think this is a good summary of various proposals that have been floated in the past, plus some new ones. As a PEP, it falls short because it doesn't pick a solution but merely offers a large menu of possible options. Also, there is nothing about implementation yet. However, I'm rejecting it on the basis that code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code, for example using 'return'. I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is: while_stmt ::= while expression : suite [else : suite] for_stmt ::= for target_list in expression_list : suite [else : suite] try1_stmt ::= try : suite (except [expression [as target]] : suite)+ [else : suite] [finally : suite] All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do. -- Hatem Nassrat ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). +1 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Announcing PEP 3136
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 statements. Georg Brandl has graciously added it to the PEP list as PEP 3136: http://www.python.org/dev/peps/pep-3136/ I think this is a good summary of various proposals that have been floated in the past, plus some new ones. As a PEP, it falls short because it doesn't pick a solution but merely offers a large menu of possible options. Also, there is nothing about implementation yet. However, I'm rejecting it on the basis that code so complicated to require this feature is very rare. In most cases there are existing work-arounds that produce clean code, for example using 'return'. I agree that this feature will only serve as a quick hack and in many cases it would be misused and ugly code will be the result. However, it seems that there are some shortcuts that have sneaked into python (I am a fairly new Python programmer, only since late 2.4, so don't shoot me). The specific one of which I speak about is: while_stmt ::= while expression : suite [else : suite] for_stmt ::= for target_list in expression_list : suite [else : suite] try1_stmt ::= try : suite (except [expression [as target]] : suite)+ [else : suite] [finally : suite] All these else's seem like shortcuts to me. I did find a use for them, once I found out they existed, but I get butterflies whenever I do. In English, butterflies are usually a good thing (they mean you'e in love). These else clauses (assuming you're talking about that) have been in the language pretty much forever. The combined except/finally clause is newer, it was added because Java allows it and it was actually a pretty common usage. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). You can override ArgumentParser.error() to raise an exception. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. It looks like this might not be so easy to do. I'd suggest adding a file-like object to the constructor, defaulting to sys.stderr; or maybe an ArgumentParser.print() method that can be overridden. Eric. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 interpreter). That one does worry me. I'd rather argparse (or any library function) didn't call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). This is behavior that argparse inherits from optparse, but I believe it's still what 99.9% of users want. If you're writing a command line interface, you don't want a stack trace when there's an error message (which is what you'd get if argparse just raised exceptions) you want an exit with an error code. That's what command line applications are supposed to do. 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 whatever you think it should do. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 lots of users, who will not want current code broken. So that criterion conflicts with the desire to do major redesign. Peter Moody wrote: re: assumed disconnect between the statement Addresses and Networks are distinct and the implementation. I don't actually see a disconnect. I can, at least somewhat. But I do not think philosophical agreement is either possible or needed for practical compromise. There will still remain the issue of how the doc is organized and worded (see below). re: denormalized networks: 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 re: new comparison methods 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? To my naive viewpoint, yes and mostly no, and if Guido say yes and no, that would also be good enough for me. 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. My suggestion for the doc, based on my understanding derived from reading this thread (and therefore subject to correction ;-) is something as follows: - NN. IPADDR NN.1 Adresses NN.2 Networks Conceptually, a network is a power of 2 range of addresses whose last k bits range from 0...0 to 1...1. A network object is similar to a Py3 range object. Networks are often (usually? always?) defined by an address plus an indication of the bits to either keep or ignore. As a convenience for certain uses, the defining address is included with the network instance as its .ip attribute (see NN.3 Address + network). However, standard comparisons ignore this attribute, as do the methods discussed in this section. ... NN.3 (or possibly NN.2.1) Address (or Host) + Network As mentioned above, Network instances include their defining address as a .ip attribute so that they can alternatively be used as Host+Network. The following functions and methods use this attribute. ... --- In other words, I suggest the the doc be organized more or less as it would be if there were a third class. I believe this would help both those who do not need or want this usage, as well as those who do. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 something pythonic? To my naive viewpoint, yes and mostly no, and if Guido say yes and no, that would also be good enough for me. Indeed I say yes and no. 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 to have few choices of data types, since they usually make the wrong choice (Ever tried to figure out whether to use an ArrayList or a LinkedList in Java?) So if there are two different but similar classes to represent a network, distinguished only by whether they retain the denormalized input address or not, users have a 50% chance of picking the wrong one, while if there is only one class, there is a 100% chance of picking the right one. (There is still the IPAddress class, but the differences between IPAddress and IPNetwork are much clearer.) -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 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 call sys.exit on my behalf - it should raise an exception. Is it actually true that argparse exits? (I can imagine that it might if --help was specified, for example. An exception may not be right here, but I still don't like the idea of a straight exit - I've used too many C libraries that think they know when I want to exit). This is behavior that argparse inherits from optparse, but I believe it's still what 99.9% of users want. If you're writing a command line interface, you don't want a stack trace when there's an error message (which is what you'd get if argparse just raised exceptions) you want an exit with an error code. That's what command line applications are supposed to do. 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 whatever you think it should do. 2. There is no chance the parser will print things I don't want it to print. That may also be bad - for example, Windows GUI-mode programs raise an error if they write to stdout/stderr. I could imagine using argparse for such a program, and wanting to do something with --help other than write to stdout and exit (a message box, for example). And yet, I'd want access to the text argparse would otherwise write to stdout. There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. In making the method public you might want to rename it to something other than print_message. If all the messages are errors, including error in the name would be good. If not, classifying the errors vs non-errors as an extra parameter might be good (in other words... inform the user and continue, or inform the user and exit). Separating the message from the classification is not good, because that leads to dialog boxes having only an OK button, and depending on the message, it can be really inappropriate to display an OK button... buttons named Sorry, Alas!, and Exit or Quit are often more appropriate, even when there is no user choice possible. Clearly if someone is writing a GUI, they are willing to write lots of lines of code to do things... a couple more well-documented lines to integrate argparse into their chosen GUI doesn't seem onerous. Especially if they can cut, paste, and hack from the above-suggested example code, like they do for the rest of their GUI code. Well, at least, cut, paste, and hack is how I write GUIs when I bother. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [OT] Denormalized fractions [was Re: PEP 3144 review.]
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/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 coming up with an API that makes simple things easy and other things possible. I'm not convinced that argparse represents a subsantial enough advancement in that art to justify replacing optparse with it in the stdlib, and thereby forcing everyone to learn a similar-but-different API. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 override exit() to do whatever you think it should do. [...] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Thanks, that's fine for me (as things stand, no need to publicly expose and document _print_message). BTW, the helpful and responsive way you reply to queries is much appreciated. I'm +1 on the PEP (although I see why people want getopt to stay, so I'm happy to leave that and only deprecate optparse). Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 like network plus the address of its interface. So some people think that using the name IPNetwork for this object is confusing. -- Greg ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 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 whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 one's brain than optparse. There's no question it is if you're doing more complicated stuff, like extending it or using subcommands. After I converted my code from optparse to argparse, I ended up with less stuff that was more regular and easier to understand. It convinced me that argparse is a win. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 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 whatever you think it should do. [snip] There is only a single method in argparse that prints things, _print_message(). So if you want it to do something else, you can simply override it in a subclass. I can make that method public if this is a common use case. Documenting both of these options would forestall people from thinking it is only useful for console applications. I'm totally fine with people thinking it is only useful for console applications. That's what it's intended for. That said, if there are people out there who want to use it for other applications, I'm happy to make things easier for them if I know concretely what they want. Hmm. Maybe that is partly why (sadly) so many GUI programs don't offer much in the way of command line options. Of course, many of their users in Windowsland wouldn't know how to tweak the shortcut to invoke them with options anyway, which might be another part. Fortunately, there are some good Windows programs that do offer rich GUIs and also rich command line options (e.g. IrfanView and ImgBurn) An example of using argparse with Tk (I think that is the only GUI that ships with Python) would also be good. I don't really use GUI libraries, so I wouldn't be able to come up with such an example. I'd also rather not make API changes based on speculative use cases, so before I spend time documenting these things, I'd really like to hear from someone who has already, say, used getopt or optparse in conjunction with a GUI library, and what feedback they have about that. I'm not a Tk user, just coming to Python from Perl, where I used Win32::GUI, but when I was looking for a functional and portable GUI development package, Perl didn't have one (still doesn't have one that supports Unicode and printing), and Python does... so here I come to Python and Qt. From my experience in Perl GUI Windowsland, the primary issue with command line parsing is displaying the message in a dialog instead of STDOUT. But the message and the user choices have to be known at the same time to design the dialog box. And, there is nothing so aggravating as to be shown an error message, and the only option is a button that says OK, when it clearly isn't OK. So the tone/type of the messages also needs to be known, even when there are no user choices. The --help option could display the help message, and offer OK. Many errors (particularly unrecoverable ones) should display the error message, and offer an Exit button, or just the close box. A few (although probably only highly customized user options) might want to give the user multiple recovery options. So, I guess I'm in the unfortunate position of seeing the need, but not having used these specific technologies enough to offer an example either. So far, I've only used optparse (just now hearing about argparse in this thread) for command line programs in Python, and I am still just experimenting with Qt, and don't have enough familiarity with it yet to think that what I'm doing is best practices. I think it would be sad to a new replacement for optparse that didn't GUI usage, though, at least in a limited form. The concepts I describe seem sufficient from experience in other environments, and I would think they would be sufficient in Python too, but I'm too new here to state that definitely. -- Glenn -- http://nevcal.com/ === A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 currently works with versions of Python 2.6 I see no reason to make such a change. This would just introduce needless differences between the version delivered with Python and the PyPI version and make it more difficult for the author to keep the two code bases in sync. Sorry, my phrasing was poor - I should have said as well as rather than instead of. For both existing argparse users and to ease conversion from optparse to argparse, %-formatting support obviously needs to remain. We already have a problem with existing APIs not supporting the new string formatting - let's not make it worse by adding *new* APIs that only support the *old* formatting technique. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] transitioning from % to {} formatting
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(%(asctime)s - %(name)s - %(levelname)s - %(message)s)
We'd like to support both this style as well as the following style:
logging.Formatter({asctime} - {name} - {levelname} - {message})
Perhaps we'd eventually deprecate the %-style formatting, but at least
in the intervening time, we'd have to support both. I see a few
possibilities:
* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.
It also means we have to come up with new names for every API that
uses format strings.
* Have Formatter try to guess whether it got %-style formatting or
{}-style formatting, and then delegate to the appropriate one. I don't
know how accurately we can guess. We also end up still relying on both
formatting styles under the hood.
* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.
Thoughts?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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. There's an art to coming up with an API that makes simple things easy and other things possible. I'm not convinced that argparse represents a subsantial enough advancement in that art to justify replacing optparse with it in the stdlib, and thereby forcing everyone to learn a similar-but-different API. As someone that has written multiple optparse based utility scripts, I would say that yes, argparse is a *huge* improvement. Several things that I implemented for my own use in a rather clumsy fashion (subcommands, aggregated parsers, non-interspersed arguments) have far more elegant support built directly into argparse. For the getopt-vs-opt/argparse discussion, I believe the major distinction is in the relative balance between procedural and declarative style of argument handling. 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 optparse is declarative to some degree, but forces you to drop back to a procedural style to handle arguments and subcommands. argparse takes things even further in a declarative direction by adding explicit support for positional arguments and subcommands. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 that would cause printing it to use hex by default. At the risk of bringing in false analogies: it seems that Python typically represents values of some type in their canonical form, rather than remembering the form in which they arrived in the program: - integer values forget how many preceding zeroes they have - string literals forget which of the characters had been escaped, and whether the string was single- or double-quoted - floating point values forget a lot more about their literal representation (including even the literal decimal value) 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? For a concrete example of an object which remembers details about its creation that it ignores when determining equality, we have decimal.Decimal: . from decimal import Decimal as d . x = d(3.0) . y = d(3.00) . x d(3.0) . y d(3.00) . repr(x) == repr(y) False . x.as_tuple() == y.as_tuple() False . x == y True (It was actually thinking of this example which led to me suggesting that the equivalence classes of IPNetwork just needed adjusting rather than the .ip attribute being removed completely) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 if-conditions are de-facto part of getopt's API. -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 users to have few choices of data types, since they usually make the wrong choice (Ever tried to figure out whether to use an ArrayList or a LinkedList in Java?) So if there are two different but similar classes to represent a network, distinguished only by whether they retain the denormalized input address or not, users have a 50% chance of picking the wrong one, while if there is only one class, there is a 100% chance of picking the right one. (There is still the IPAddress class, but the differences between IPAddress and IPNetwork are much clearer.) Note that Terry was just talking about the documentation there. That is, he was suggesting that the documentation first describe the normal IPNetwork methods which are unaffected by the .ip attribute and then, in a separate section, describe the methods that are specific to denormalised networks where net.ip != net.network. Such an arrangement makes sense to me. 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 write code using 'net.ip' that should have used 'net.network' instead. Such code will then work correctly most of the time (i.e. when only given normalised IPNetwork objects) but will fail when given a denormalised one. I believe that discomfort could be eliminated best by changing the name of the .ip attribute to .host_ip to make it clear that it is referring to the IP address of the host that was used to derive the network definition rather than referring to the network ID itself. Shortening .network to .net_ip would also help (this latter change would also eliminate the mental disconnect caused by an attribute called .network returning an IPAddress instance). Those two naming suggestions are far less fundamental than fixing the definition of the IPNetwork equivalent classes though - and it sounds like Peter is happy with the proposed change on that front. Regards, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 {}-style formatting on True
and %-style formatting on False, which defaults to False
version N + 1: Deprecate False value for formatting flag (all code
should start specifying flag=True)
version N + 2: Raise error on False value for formatting flag (all
code must specify flag=True)
version N + 3: Deprecate formatting flag
version N + 4: Remove formatting flag
?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 imposes. All those twisty if-conditions are de-facto part of getopt's API. People assess the mental cost differently though - for getopt, they tend to assign the cost to the script they're currently writing, while for optparse/argparse they assign the cost to those two libraries being difficult to learn :) 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 parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. (Note that getting a good help string for free is one of the biggest gains I currently find in using optparse over getopt. This is especially so once you start making use of option groups) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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. As the getopt argument parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. One thing that wouldn't be good in this transition is that add_getopt_arguments can only generate the part of the help string that says -a and --author exist as options -- it can't add the additional bit of text that says what they do because that's not provided to the getopt API. I suspect this makes the transition less convenient because with getopt you were probably already manually maintaining a usage message that had at least some of this information, and switching to add_getopt_arguments would mean throwing this information away. Steve -- Where did you get that preposterous hypothesis? Did Steve tell you that? --- The Hiphopopotamus ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 parsing gets twisty and arcane and maintaining the help string becomes a nightmare, move to argparse with the add_getopt_arguments method. 3. Over time, convert more arguments to proper argparse arguments with full documentation. 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. The two are so different that I think you're either going to jump all in or not. Maybe that's just me though as I really don't see much use for getopt any more (even for throwaway scripts). -Barry PGP.sig Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] test_thread tracebacks
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 (most recent call last): File /Users/skip/src/python/trunk/Lib/test/test_thread.py, line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Users/skip/src/python/trunk/Lib/test/test_thread.py, line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_stack_size Traceback (most recent call last): File /Users/skip/src/python/trunk/Lib/test/test_thread.py, line 51, in task self.done_mutex.release() thread.error: release unlocked lock Unhandled exception in thread started by bound method ThreadRunningTests.task of test.test_thread.ThreadRunningTests testMethod=test_starting_threads Traceback (most recent call last): File /Users/skip/src/python/trunk/Lib/test/test_thread.py, line 51, in task self.done_mutex.release() thread.error: release unlocked lock Oddly enough, this didn't cause the test to fail. Is this a known problem? Should I open a ticket? Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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 to shift gradually via hybrid APIs. The two are so different that I think you're either going to jump all in or not. Maybe that's just me though as I really don't see much use for getopt any more (even for throwaway scripts). Heh. I never liked getopt anyway. :-) -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_thread tracebacks
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 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 write code using 'net.ip' that should have used 'net.network' instead. Such code will then work correctly most of the time (i.e. when only given normalised IPNetwork objects) but will fail when given a denormalised one. I believe that discomfort could be eliminated best by changing the name of the .ip attribute to .host_ip to make it clear that it is referring to the IP address of the host that was used to derive the network definition rather than referring to the network ID itself. Shortening .network to .net_ip would also help (this latter change would also eliminate the mental disconnect caused by an attribute called .network returning an IPAddress instance). +1 --David (RDM) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_thread tracebacks
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: http://bugs.python.org/issue6186 -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 that discomfort pretty well: the current naming seems like an invitation to write code using 'net.ip' that should have used 'net.network' instead. Such code will then work correctly most of the time (i.e. when only given normalised IPNetwork objects) but will fail when given a denormalised one. I believe that discomfort could be eliminated best by changing the name of the .ip attribute to .host_ip to make it clear that it is referring to the IP address of the host that was used to derive the network definition rather than referring to the network ID itself. Shortening .network to .net_ip would also help (this latter change would also eliminate the mental disconnect caused by an attribute called .network returning an IPAddress instance). +1 +1 on that it's a bikeshed. +0 on renaming .ip to something longer. -0 on renaming .network. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] test_thread tracebacks
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 suite. This evening I noticed this on my Mac (OS X 10.5): It's not a new problem: http://bugs.python.org/issue6186 ... and minutes after I posted this, I saw another occurrence of it, this time with 2.6.3rc1 on 10.5 ppc, so, whatever the problem or severity, it is still around in 2.6, at least. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 isn't just a network, it's more like network plus the address of its interface. So some people think that using the name IPNetwork for this object is confusing. Especially since to my mind networks don't have interfaces. Hosts have interfaces. IPInterface, anyone? ... no, let's not go there, stick a fork in it, it's done. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 3144 review.
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 mean, by default? Surely you don't mean an equality method with some sort of flag!? no, I mean setting it up so that if I want to compare two network objects and take into account their .ip attribute, that I use a .compare_with_extra_bits() method or something. __eq__, __ne__, __lt__, __le__, __gt__, __ge__ (any more?) would all only compare .network and .prefixlen (as you have in your example). OK. My position is that I'd appreciate it if you would review some of the existing bikeshedding to see if there are any acceptable tweaks to make more people a little happier, but as of now I'm +1 on the design. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 should really provide some sort of transition plan.
-1.
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:
logging.Formatter()
Now, that's different. IIUC, you are not actually performing the
substitution here, but only at a later place.
So changing to the new formatting mechanism is an API change.
I agree that the new placeholder syntax needs to be supported.
* Add a new class, NewFormatter, which uses the {}-style formatting.
This is ugly because it makes the formatting we're trying to encourage
look like the alternative implementation instead of the standard one.
It's also ugly because the class has the word new in its name, which
no class should ever have. In a few years, it would still be around,
but not new anymore.
* Have Formatter convert all %-style formatting strings to {}-style
formatting strings (automatically). This still involves some guessing,
and involves some serious hacking to translate from one to the other
(maybe it wouldn't even always be possible?). But at least we'd only
be using {}-style formatting under the hood.
I don't see the point of having a converter. The tricky part, as you
say, is the guessing. Whether the implementation then converts the
string or has two alternative formatting algorithms is an implementation
detail. I would favor continued use of the actual % substitution
code.
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the method name of the
string type), i.e.
logging.Formatter(
format={asctime} - {name} - {levelname} - {message})
For the % formatting, I suggest dicttemplate (assuming that
you *have* to use dictionary %(key)s style currently).
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 2.6.3
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 a 64-bit version at that. A number of patches have either just been checked-in over the past couple of weeks or are getting some exposure before check-in. Given the timing and the (appropriate) infrequency of 2.6.x releases, I think it would be unfortunate to push 2.6.3 out the door without ensuring that it works well on 10.6. Therefore, I propose that 2.6.3 should have 10.6 compatibility as a release goal. Without trying to put Ronald on the spot (too much!), it would be a good idea to get his assessment where things stand wrt 2.6 on 10.6 before setting a final release date. I'm hoping that Python won't have any issues building and running on 10.6, but I don't have it yet so I can't personally test it out. How would you quantify works well? Do you have any thoughts on tests you'd run other than the standard test suite? If 2.6.3 is shown to pass its test suite on 10.5.x, is that good enough? Are the specific bug fixes necessary for 10.6? To follow-up, I've now run the usual standard OS X installer builds and regression tests using 2.6.3rc1 plus a few additional tests (IDLE and package installation) and have found no regressions from 2.6.2 and verified that some release-blocker problems have indeed been fixed. In particular, Issue6957 regarding extensions module building on OS X 10.6 is fixed as discussed in the issue. The tests involved the target python.org installer configuration: - deployment target = 10.3, 2-way i386/ppc, Tk 10.4, built on 10.5 - regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386 plus the following additional configurations: - deployment target = 10.3, 2-way i386/ppc, Tk 10.4, built on 10.4: - regrtest on 10.4 ppc, 10.5 ppc, 10.6 i386 - deployment target = 10.5, 4-way i386/x86_64/ppc/ppc64, Tk 10.4, built on 10.5: - regrtest on 10.5 ppc, 10.6 i386, 10.6 x86_64 plus, a quick check of the currently unsupported configuration, with no new regressions noted: - deployment target = 10.6, 2-way i386/x86_64, Tk 10.5, built on 10.6: - regrtest on 10.6 x86_64 As noted in various tracker issues, there are still a few unresolved issues with universal builds built on 10.6 (e.g. 32-bit vs 64-bit selection, IDLE with Tk 8.5) which is why this last installer build configuration is currently unsupported. In my opinion, the standard python.org OS X installer for 2.6.3 now works well on 10.4, 10.5, and 10.6 and is ready for release. -- Ned Deily, n...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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:
logging.Formatter()
Now, that's different. IIUC, you are not actually performing the
substitution here, but only at a later place.
So changing to the new formatting mechanism is an API change.
I agree that the new placeholder syntax needs to be supported.
Just to be clear, I don't think logging is the only place these kind
of things happen. Some others I found looking around:
BaseHTTPServer.BaseHTTPRequestHandler.error_message_format
http://docs.python.org/library/basehttpserver.html#BaseHTTPServer.BaseHTTPRequestHandler.error_message_format
BaseHTTPServer.BaseHTTPRequestHandler.log_message
http://docs.python.org/3.1/library/http.server.html#http.server.BaseHTTPRequestHandler.log_message
email.generator.DecodedGenerator
http://docs.python.org/library/email.generator.html#email.generator.DecodedGenerator
There may be more.
I would propose that the format argument gets an argument name,
according to the syntax it is written in. For PEP 3101 format,
I would call the argument format (like the method name of the
string type), i.e.
logging.Formatter(
format={asctime} - {name} - {levelname} - {message})
For the % formatting, I suggest dicttemplate (assuming that
you *have* to use dictionary %(key)s style currently).
The positional parameter would also mean dicttemplate, and
would be deprecated (eventually requiring a keyword-only
parameter).
This is a nice solution for the cases where we can be confident that
the parameter is currently only used positionally. However, at least
in Python 3.1, fmt is already documented as a keyword parameter:
http://docs.python.org/3.1/library/logging.html#logging.Formatter
I guess we could follow the same approach though, and have fmt= be the
%-style formatting, and use some other keyword argument for {}-style
formatting.
We've got a similar problem for the
BaseHTTPRequestHandler.error_message_format attribute. I guess we'd
want to introduce some other attribute which is the error message
format for the {}-style formatting?
Steve
--
Where did you get that preposterous hypothesis?
Did Steve tell you that?
--- The Hiphopopotamus
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 389: argparse - new command line parsing module
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
debug parse_args in an interpreter).
[...]
This is behavior that argparse inherits from optparse, but I believe
it's still what 99.9% of users want. If you're writing a command line
interface, you don't want a stack trace when there's an error message
(which is what you'd get if argparse just raised exceptions) you want
an exit with an error code. That's what command line applications are
supposed to do.
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 whatever you
think it should do.
2. There is no chance the parser will print things I don't want it to print.
[...]
There is only a single method in argparse that prints things,
_print_message(). So if you want it to do something else, you can
simply override it in a subclass. I can make that method public if
this is a common use case.
Instead of forcing the user to override the ArgumentParser class to
change how errors are handled, I suggest adding a separate method
ArgumentParser.parse_args_with_exceptions() that raises exceptions
instead of writing to stdout/stderr and never calls sys.exit(). Then
implement ArgumentParser.parse_args() as a wrapper around
parse_args_with_exceptions():
class ArgparseError(Exception):
argparse-specific exception type.
pass
class ArgumentError(ArgparseError):
# ...
class ArgumentParser(...):
# ...
def parse_args_with_exceptions(...):
# like the old parse_args(), except raises exceptions instead of
# writing to stdout/stderr or calling sys.exit()...
def parse_args(self, *args, **kwargs):
try:
self.parse_args_with_exceptions(*args, **kwargs)
except ArgparseError as e:
self.print_usage(_sys.stderr)
self.exit(status=2,
message=(_('%s: error: %s\n') % (self.prog, e,)))
# perhaps catch other exceptions that need special handling...
def error(self, message):
raise ArgparseError(message)
The exception classes should hold enough information to be useful to
non-command-line users, and obviously contain error messages that are
output to stderr by default. This would allow non-command-line users to
call parse_args_with_exceptions() and handle the exceptions however they
like.
Michael
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] transitioning from % to {} formatting
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 Smith wrote:
I've basically come to accept that %-formatting can never go away,
unfortunately. There are too many places where %-formatting is used,
for example in logging Formatters. %-formatting either has to exist
or it has to be emulated.
It'd possibly be helpful if there were builtin objects which forced
the format style to be either newstyle or oldstyle, independent of
whether % or format was called on it.
E.g.
x = newstyle_formatstr({} {} {})
x % (1,2,3) == x.format(1,2,3) == 1 2 3
and perhaps, for symmetry:
y = oldstyle_formatstr(%s %s %s)
y.format(1,2,3) == x % (1,2,3) == 1 2 3
This allows the format string style decision is to be made external
to the API actually calling the formatting function. Thus, it need not
matter as much whether the logging API uses % or .format() internally
-- that only affects the *default* behavior when a bare string is
passed in.
This could allow for a controlled switch towards the new format string
format, with a long deprecation period for users to migrate:
1) introduce the above feature, and recommend in docs that people only
ever use new-style format strings, wrapping the string in
newstyle_formatstr() when necessary for passing to an API which uses %
internally.
2) A long time later...deprecate str.__mod__; don't deprecate
newstyle_formatstr.__mod__.
3) A while after that (maybe), remove str.__mod__ and replace all
calls in Python to % (used as a formatting operator) with .format() so
that the default is to use newstyle format strings for all APIs from
then on.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
