Re: [Python-Dev] nonlocal keyword in 2.x?
2009/10/28 Antoine Pitrou solip...@pitrou.net: skip at pobox.com writes: So 2.7 support will for the most part be a case not of supporting Python versions, but Python *users*. Antoine That's still not a good reason to backport nonlocal. The same Antoine reasoning could be used to backport new features to the 2.6 Antoine branch after all. No, because 2.6 is in feature freeze (bug fixes only). 2.7 is the current version of 2.x where new features are allowed to be added. That was precisely my point. Then I don't understand what you are saying. Obviously we shouldn't backport to the 2.6 branch, it's in bugfix mode. This is about 2.7. I don't see what 2.6 has to do with it. There are development practices which mitigate the idea that backporting is always helpful to the user. And those are? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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] nonlocal keyword in 2.x?
Lennart Regebro wrote: 2009/10/28 Antoine Pitrou solip...@pitrou.net: skip at pobox.com writes: So 2.7 support will for the most part be a case not of supporting Python versions, but Python *users*. Antoine That's still not a good reason to backport nonlocal. The same Antoine reasoning could be used to backport new features to the 2.6 Antoine branch after all. No, because 2.6 is in feature freeze (bug fixes only). 2.7 is the current version of 2.x where new features are allowed to be added. That was precisely my point. Then I don't understand what you are saying. Obviously we shouldn't backport to the 2.6 branch, it's in bugfix mode. This is about 2.7. I don't see what 2.6 has to do with it. There are development practices which mitigate the idea that backporting is always helpful to the user. And those are? You said it above yourself: bugfix mode That's all Antoine's point was - backporting of new features to previous branches is not automatically a good idea. In the case of 3.2 - 2.7 backports, there are issues with the initial development time investment to do the backport, future double-keying of additional maintenance issues, consideration of possible poor interaction with legacy features in the 2.x series. It's a bunch of additional work that isn't going to happen without someone volunteering to do it. 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] MSDN subscribers: Using Visual Studio?
Steve Holden holdenweb at gmail.com writes: I just wondered, with the recent flood of new MSDN subscriptions loosed on the developer community, how many people have installed the required version of Visual Studio and built Python for Windows from source? Not being that familiar with the process myself I was hoping for some advice from the inexperienced who have overcome any hurdles there might be. I have a pristine virtual machine just waiting for the right pieces ... If it's just a matter of building and testing it you don't need any MSDN subscription, you just need Visual Studio Express which is free (as in free beer...). I don't know if it allows you to build an installer though. I won't reply to the other part of the message since I haven't asked for (nor received) any MSDN subscription :) 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
[Python-Dev] Buildbot category on the tracker
Hello, What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. 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] MSDN subscribers: Using Visual Studio?
On Thu, Oct 29, 2009 at 6:57 AM, Antoine Pitrou solip...@pitrou.net wrote: If it's just a matter of building and testing it you don't need any MSDN subscription, you just need Visual Studio Express which is free (as in free beer...). I don't know if it allows you to build an installer though. It does. If I recall correctly, in addition to Visual Studio Express, I also needed the Windows SDK (which is also free as in beer). -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ 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] MSDN subscribers: Using Visual Studio?
Daniel Stutzbach wrote: It does. If I recall correctly, in addition to Visual Studio Express, I also needed the Windows SDK (which is also free as in beer). The VS 2008 Express Edition is sufficient to build X86 binaries on Windows. The express edition doesn't support X64_86. though. Christian ___ 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] Buildbot category on the tracker
What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Do you have any specific reports that you would want to classify with this category? 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
[Python-Dev] ssl module
Hello, I would like to ask a few questions and suggestions regarding the ssl module (in Python 2.6). (I gather from [1] that there is some effort going on to enhance the ssl API, but I'm not sure if this is the right place to discuss it.) Like other Python users, I was a bit surprised by the lack of verification of httplib/urllib2 (hence I started to write a small library a while back, only published today [2]), but the following points are not HTTP-specific. 1. Hostname checking. From what I gather by reading the archives on this list, the issue of hostname checking seems controversial [3]. It seems widely admitted by browser communities nowadays to check that the hostname the CN field of the subject DN or the DNS entries of subjectAltName. I'd feel more comfortable if this was the default behaviour of the client in Python's SSL module, although having a mechanism to override this would be useful indeed. It's more or less a basic security requirement to check the identity of the server before doing anything else. 2. Cipher suite selection. It's useful to restrict the list of cipher suites that can be used, not just for speed (as mentioned in [1]), but also because some cipher suites may be considered insecure by some institutions. This would be a good feature to have indeed. 3. Full chain of certificates. The PyOpenSSL module is able to take a callback function that verifies each certificate in the chain (using depth). According to the documentation, the ssl module only exposes the first certificate in the chain (no CA). In some applications, it is useful to verify certain policies according to attributes further up in the chain. I'd like to suggest having an SSLSocket.getpeercerts(binary_form=False) (plural) that returns a list of certificates in the verification chain. Is there a place where the status of the ssl module is summarized, or a better place to discuss this? I could try to provide contributions or further details if appropriate. Best wishes, Bruno. [1] http://mail.python.org/pipermail/python-dev/2009-September/091636.html [2] http://code.google.com/p/python-httpclient [2] http://bugs.python.org/issue1589 ___ 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] (no subject)
Martin v. Löwis martin at v.loewis.de writes: What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Do you have any specific reports that you would want to classify with this category? I was thinking of http://bugs.python.org/issue4970 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] Buildbot category on the tracker
On 02:30 pm, solip...@pitrou.net wrote: Hello, What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Is your idea that this would be for tracking issues with the *bots* themselves? That is, not just for tracking cases where some test method fails on a particular bot, but for tracking cases where, say, a bot's host has run out of disk space and cannot run the tests at all? For the case where a test is failing because of some platform or environment issue, it seems more sensible to track the ticket as relating to that platform or environment, or track it in relation to the feature it affects. Of course, tickets could move between these classifications as investigation reveals new information about the problem. Jean-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] Buildbot category on the tracker
On Thu, Oct 29, 2009 at 7:04 PM, exar...@twistedmatrix.com wrote: On 02:30 pm, solip...@pitrou.net wrote: Hello, What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Is your idea that this would be for tracking issues with the *bots* themselves? That is, not just for tracking cases where some test method fails on a particular bot, but for tracking cases where, say, a bot's host has run out of disk space and cannot run the tests at all? For the case where a test is failing because of some platform or environment issue, it seems more sensible to track the ticket as relating to that platform or environment, or track it in relation to the feature it affects. Of course, tickets could move between these classifications as investigation reveals new information about the problem. Then again, I know for a fact certain tests fail ONLY on certain buildbots because of the way they're configured. For example, certain multiprocessing tests will fail if /dev/shm isn't accessible on Linux, and several of the buildbosts are in tight chroot jails and don't have that exposed. Is it a bug in that buildbot, a platform specific bug, etc? jesse ___ 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] ssl module
Bruno Harbulot bruno.harbu...@manchester.ac.uk wrote: Hello, I would like to ask a few questions and suggestions regarding the ssl module (in Python 2.6). (I gather from [1] that there is some effort going on to enhance the ssl API, but I'm not sure if this is the right place to discuss it.) Is there a place where the status of the ssl module is summarized, or a better place to discuss this? I could try to provide contributions or further details if appropriate. Yes, please look at the issues in the issue tracker already, and contribute there. We could particularly use more test cases to support patches that people have already submitted. Like other Python users, I was a bit surprised by the lack of verification of httplib/urllib2 (hence I started to write a small library a while back, only published today [2]), but the following points are not HTTP-specific. 1. Hostname checking. From what I gather by reading the archives on this list, the issue of hostname checking seems controversial [3]. It seems widely admitted by browser communities nowadays to check that the hostname the CN field of the subject DN or the DNS entries of subjectAltName. I'd feel more comfortable if this was the default behaviour of the client in Python's SSL module, although having a mechanism to override this would be useful indeed. It's more or less a basic security requirement to check the identity of the server before doing anything else. I don't think it should happen by default in the ssl module client code, but I agree it makes sense to do that in various application uses of SSL, such as the httplib support for https, since that behavior is (annoyingly) called for in the (experimental, not standard) RFC which defines HTTP over SSL, and, as you say, it's widely done in Web browsers when https is being used. If you check the issues, you'll see that I think there should be a helper function in the ssl module to do this checking. Would you like to contribute one? Please either attach it to an already open issue, or start a new feature request issue. 2. Cipher suite selection. It's useful to restrict the list of cipher suites that can be used, not just for speed (as mentioned in [1]), but also because some cipher suites may be considered insecure by some institutions. This would be a good feature to have indeed. Yes, I agree. 3. Full chain of certificates. The PyOpenSSL module is able to take a callback function that verifies each certificate in the chain (using depth). According to the documentation, the ssl module only exposes the first certificate in the chain (no CA). In some applications, it is useful to verify certain policies according to attributes further up in the chain. I'd like to suggest having an SSLSocket.getpeercerts(binary_form=False) (plural) that returns a list of certificates in the verification chain. Feel free to use PyOpenSSL for more complicated applications, like the one you mention, and to file more issues on the Python issue tracker about this. Though, we were striving to have something small and simple in the ssl module, not a feature-full binding to OpenSSL. Oh, and there's also a stdlib-sig, which (since the ssl module is part of the stdlib) might be an appropriate place to discuss it. Bill ___ 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] Buildbot category on the tracker
On Thu, 29 Oct 2009 at 19:41, Jesse Noller wrote: Then again, I know for a fact certain tests fail ONLY on certain buildbots because of the way they're configured. For example, certain multiprocessing tests will fail if /dev/shm isn't accessible on Linux, and several of the buildbosts are in tight chroot jails and don't have that exposed. Is it a bug in that buildbot, a platform specific bug, etc? I'd say that particular one is a bug in the tests. If /dev/shm is not available and is required, then the tests should be skipped with an appropriate message. It would also secondarily be an issue with the buildbot fleet, since multiprocessing would then not be getting thoroughly tested by those buildbots. IMO a buildbot category might be useful for bugs that show up in a buildbot but no one can (currently) reproduce, or problems with the buildbots themselves. I don't think we currently have any bugs filed that fall in the second category, but multiprocessing not getting completely tested because of lack of /dev/shm would fall into that category. Issue 4970 was in the first category until recently. But the real reason for having a buildbot category (or at least a keyword) would be to be able to tag all bugs that are currently making buildbots fail that are _not_ the result of a recent checkin. This would make the task of finding the bugs that need to be cleaned up to stabilize the buildbot fleet easier. I'm currently aware of issues 4970, 3892, and 6462 in this category, and there are a few more that we can/will file if we continue to pay attention to the failure reports now arriving on the irc channel. --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] Buildbot category on the tracker
On 29 Oct, 11:41 pm, jnol...@gmail.com wrote: On Thu, Oct 29, 2009 at 7:04 PM, exar...@twistedmatrix.com wrote: On 02:30 pm, solip...@pitrou.net wrote: Hello, What do you think of creating a buildbot category in the tracker? There are often problems on specific buildbots which would be nice to track, but there's nowhere to do so. Is your idea that this would be for tracking issues with the *bots* themselves? That is, not just for tracking cases where some test method fails on a particular bot, but for tracking cases where, say, a bot's host has run out of disk space and cannot run the tests at all? For the case where a test is failing because of some platform or environment issue, it seems more sensible to track the ticket as relating to that platform or environment, or track it in relation to the feature it affects. Of course, tickets could move between these classifications as investigation reveals new information about the problem. Then again, I know for a fact certain tests fail ONLY on certain buildbots because of the way they're configured. For example, certain multiprocessing tests will fail if /dev/shm isn't accessible on Linux, and several of the buildbosts are in tight chroot jails and don't have that exposed. Is it a bug in that buildbot, a platform specific bug, etc? It's a platform configuration that can exist. If you're rejecting that configuration and saying that CPython will not support it, then it's silly to have a buildbot set up that way, and presumably that should be changed. The point is that this isn't about buildbot. It's about CPython and what platforms it supports. Categorizing it by buildbot is not useful, because no one is going to be cruising along looking for multiprocessing issues to fix by browsing tickets by the buildbot category. If, on the other hand, (sticking with this example) /dev/shm-less systems are not a platform that CPython wants to support, then having a buildbot running on one is a bit silly. It will probably always fail, and all it does is contribute another column of red. Who does that help? Jean-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] Buildbot category on the tracker
On Thu, Oct 29, 2009 at 8:31 PM, R. David Murray rdmur...@bitdance.com wrote: I'd say that particular one is a bug in the tests. If /dev/shm is not available and is required, then the tests should be skipped with an appropriate message. It would also secondarily be an issue with the buildbot fleet, since multiprocessing would then not be getting thoroughly tested by those buildbots. Fwiw: The tests skip on those platforms; but multiprocessing can't function properly on platforms like that. ___ 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] Retrieve an arbitrary element from a set withoutremoving it
On Wed, 28 Oct 2009 04:47:59 am Raymond Hettinger wrote: A dict.get() can be meaningfully used in a loop (because the key can vary). A set.get() returns the same value over and over again (because there is no key). I don't believe anyone has requested those semantics. The suggested semantics for set.get() with no arguments, as I understand them, are: (1) it will only fail if the set is empty; (2) it should be efficient; (3) if you call it repeatedly on a set without modifying the set, you will cycle through each element in turn in some unspecified arbitrary order. To clarify point 3, given: x = set.get() y = set.get() then x and y will only be the same element if set has length one. However, given: x = set.get() set.add(el) set.remove(el) y = set.get() there are no guarantees about x and y being different. I believe that the patch supplied by Willi Richart implemented these behaviours. http://bugs.python.org/issue7212 -- 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] Retrieve an arbitrary element from a setwithoutremoving it
[Steven D'Aprano] The suggested semantics for set.get() with no arguments, as I understand them, are: (1) it will only fail if the set is empty; Just like next() except that next() gives you the option to supply a default and can be used on any iterator (perhaps iter(s) or itertools.cycle(s) etc). (2) it should be efficient; Is this about optimization? I wouldn't expect x=s.get() to beat for x in s: break. Attribute lookup and method calls usually are slower than equivalents using built-in syntax with specific opcodes. (3) if you call it repeatedly on a set without modifying the set, you will cycle through each element in turn in some unspecified arbitrary order. What's wrong with using next()? That is what it's for. What about this proposal is specific to sets, i.e. why don't you want the same thing for lists. tuples, strings, file objects, or any other iterable? Does this proposal pass the test of being self-descriptive? Can you write a code fragment that exercises the cycling behavior, show it to another programmer, and have them correctly deduce what the code does (i.e. that different values are returned, that it fails when the set it empty, that it wraps around and never terminates)? Can they readily differentiate it for dict.get() which has decidedly different semantics? To clarify point 3, given: x = set.get() y = set.get() then x and y will only be the same element if set has length one. So, it can't even be used for looping through a set because there is no termination? I believe that the patch supplied by Willi Richart implemented these behaviours. http://bugs.python.org/issue7212 So you want to introduce additional, hidden state to sets? (to make sure that successive invocations return different values) Do you want a thread local version too? (so that two threads can call gets without stomping on each other's guarantees that successive calls will produce distinct elements) Do you have any real-world use-cases where next(), for-loops, or itertools wouldn't suffice? Is there a precedent in *any* other language you've ever seen? (setl has an arb function but it makes no promises about returning different values on consequetive calls; otherwise, I've never seen an equivalent in any other set implementation). Do you think the return-different-values-on-successive-calls semantics is self-evident and non-magical as compared to a straight for-loop or next(it)? ISTM, that when streams have non-destructive getters with self-advancing pointers, they also have a seek() function so that it can be controlled. Will this proposal need a seek() method too? Sorry for so many questions, but I honestly think there are too many unresolved design issues. We've seen no real-world source code that would be improved fwith the proposal. I think it sounds conceptually tempting and is fun to theorize about, but it actual implementation it will make sets more difficult to learn and it would quickly become a piece of rarely used, poorly understood cruft. Raymond ___ 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
