Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
Russell Owen ro...@uw.edu wrote: I agree that a policy is a good idea, and I suggest it be primarily based on age, since we cannot assume Apple will release new versions of the OS on a given timeline. I personally think too early to drop support for MacOS X 10.6 and am on the edge about 10.5. I run one 10.5 machine, three 10.6 machines, and 5+ 10.7+ machines right now. I have a perfectly fine and fast Mac Pro which can't even be upgraded past 10.7. So using Apple's OS release numbers as the gating factor might be a problem. I'd be happy to drop pre-built binary installers for 10.6, but that's different from dropping all support for it. Bill -- Russell On Sep 18, 2013, at 5:54 AM, Martin v. Löwis mar...@v.loewis.de wrote: Am 18.09.13 08:43, schrieb Gregory P. Smith: Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux. This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to maintain such a long legacy support tail there ourselves. I don't mind such a decision in principle, but also in principle, I'd prefer if there was a pre-set policy to decide this question, documented in PEP 11. Here a piece of OSX release history: - 10.5: October 2007 * 10.5.8: August 2009 - 10.6: August 2009 * 10.6.8: July 2011 - 10.7: July 2011 * 10.7.5: July 2012 - 10.8: July 2012 So possible policy that would now exclude 10.6 for binary installers would be: - only the two latest feature releases are supported - only feature releases younger than 3 years are supported Note that a separate policy should be added to decide whether support for older versions is actively removed from source code (or equally bug fixes for old versions are not accepted anymore). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4
Russell E. Owen ro...@uw.edu wrote: In article b3293155-e4d5-4389-a555-c31bc49ce...@gmail.com, Raymond Hettinger raymond.hettin...@gmail.com wrote: On Sep 14, 2013, at 1:32 PM, Ned Deily n...@acm.org wrote: The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK. Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries. We have been burned by that in the past. I think we should offer a separate Mac build just for 10.6 (much like we do for the 32-bit PPC option for 10.5). If Apple drops support for gcc in 10.9 I guess we have to go this route, Could go the Sage route -- Sage first checks for an up-to-date version of gcc, and downloads it and builds it for its own use if necessary. Bill but please be careful. Every time you add a new version of python for MacOS X it means that folks providing binary installers (e.g. for numpy) have to provide another binary, and folks using those installers have another chance of picking the wrong one. If you do make a 10.6-only installer, what is the minimum version of MacOS X the modern compiler would support? 10.7 gives a more measured upgrade path, but 10.8 gives a better compiler. -- Russell ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/bill%40janssen.org ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Status of packaging in 3.3
Nick Coghlan ncogh...@gmail.com wrote: On Wed, Jun 20, 2012 at 9:46 PM, Antoine Pitrou solip...@pitrou.net wrote: Agreed, especially if the proven in the wild criterion is required (people won't rush to another third-party distutils replacement, IMHO). The existence of setuptools means that proven in the wild is never going to fly - a whole lot of people use setuptools and easy_install happily, because they just don't care about the downsides it has in terms of loss of control of a system configuration. Maybe not happily :-). Speaking for myself, I'd love to find an alternative, but setuptools seems to be the only system that knows how to build shared libraries across all my platforms. I've got little interest in a packaging module that doesn't include the compiler magic to do that. 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] JITted regex engine from pypy
Maciej Fijalkowski fij...@gmail.com wrote: On Sun, Jun 3, 2012 at 5:21 PM, Martin v. Löwis mar...@v.loewis.dewrote: On the minus side, the JIT only works on x86 and x86_64, on the plus side, since it's 100% API compatible, it can be used as a _xxx speedup module relatively easy. Do people have opinions? The main concern for re is not speed, but functionality. The Python re module needs to grow a number of features, and correct a number of bugs. So 100% compatible is actually not good enough. 95% compatible (with the features added and the bugs fixed) would be better. From my point of view, for textual data reduction, the MRAB regex now has substantial improvements which enable very different kinds of uses, like named lists and fuzzy matching, which I don't believe occur (together) in any other RE library. Along with features it shares with the existing CPython re library, such as the ability to handle very large RE's (which IronPython, for instance, is unable to handle, apparently due to its use of the standard .NET RE library). And do so fairly efficiently. Bill OTOH, sharing the re code with PyPy would be a desirable goal, as would be writing the re code in Python (although SRE already implements significant parts in Python). We did not reimplement those parts in RPython, they're still in python (so the sre engine does not accept regex, but instead the lower-level description, etc. etc.) As a speedup module, it's uninteresting - we want to simplify maintenance, not complicate it. So this can only work if it replaces SRE. 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/bill%40janssen.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] OS X buildbots missing
Antoine Pitrou solip...@pitrou.net wrote: For the record, we don't have any stable OS X buildbots anymore. Sigh. That's me again. We are currently installing a virtual private cloud at our workspace, and I'm seeing a lot of intermittent failures in that server room. I need to work out a way in which buildbot restarts automatically either when the machine reboots, or when it hangs up (which happens every couple of weeks). 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] PEP 407 / splitting the stdlib
Nick Coghlan ncogh...@gmail.com wrote: On Thu, Jan 19, 2012 at 10:19 AM, Steven D'Aprano st...@pearwood.info wrote: Brett Cannon wrote: Do we have any evidence of this alleged bitrot? I spend a lot of time on the comp.lang.python newsgroup and I see no evidence that people using Python believe the standard library is rotting from lack of attention. IMO, it's a problem mainly with network (especially web) protocols and file formats. It can take the stdlib a long time to catch up with external developments due to the long release cycle, so people are often forced to switch to third party libraries that better track the latest versions of relevant standards (de facto or otherwise). I'm not sure how much of a problem this really is. I continually build fairly complicated systems with Python that do a lot of HTTP networking, for instance. It's fairly easy to replace use of the standard library modules with use of Tornado and httplib2, and I wouldn't think of *not* doing that. But the standard modules are there, out-of-the-box, for experimentation and tinkering, and they work in the sense that they pass their module tests. Are those standard modules as Internet-proof as some commercially-supported package with an income stream that supports frequent security updates would be? Perhaps not. But maybe that's OK. Another way of doing this would be to bless certain third-party modules in some fashion short of incorporation, and provide them with more robust development support, again, somehow, so that they don't fall by the wayside when their developers move on to something else, but are still able to release on an independent schedule. 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] Hash collision security issue (now public)
Christian Heimes li...@cheimes.de wrote: Am 29.12.2011 12:13, schrieb Mark Shannon: The attack relies on being able to predict the hash value for a given string. Randomising the string hash function is quite straightforward. There is no need to change the dictionary code. A possible (*untested*) patch is attached. I'll leave it for those more familiar with unicodeobject.c to do properly. I'm worried that hash randomization of str is going to break 3rd party software that rely on a stable hash across multiple Python instances. Persistence layers like ZODB and cross interpreter communication channels used by multiprocessing may (!) rely on the fact that the hash of a string is fixed. Software that depends on an undefined hash function for synchronization and persistence deserves to break, IMO. There are plenty of well-defined hash functions available for this purpose. 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] Fixing the XML batteries
Stefan Behnel stefan...@behnel.de wrote: Bill Janssen, 09.12.2011 19:15: I think another thing that might go into refreshing the batteries is a feature comparison of BeautifulSoup and HTML5lib against the stdlib competition, to see what needs to be added/revised. Having to switch to an outside package for parsing possibly invalid HTML is a pain. Such a feature request should be worth a separate thread. Note, however, that html5lib is likely way too big to add it to the stdlib, and that BeautifulSoup lacks a parser for non-conforming HTML in Python 3, which would be the target release series for better HTML support. So, whatever library or API you would want to use for HTML processing is currently only the second question as long as Py3 lacks a real-world HTML parser in the stdlib, as well as a robust character detection mechanism. I don't think that can be fixed all that easily. Sounds like it needs a PEP. I'm only advocating spending some thought on what needs to be done -- whether outside libraries need to be adopted into the stdlib would be a step after that. But understanding *why* those libraries exist and are widely used should be a prerequisite to refreshing the stdlib's support. 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] Unicode re support in Python 3
Michael Foord fuzzy...@voidspace.org.uk wrote: Hey python-devers, As I'm sure many of you are aware, Armin Ronacher posted a blog entry explaining the reasons he dislikes Python 3 in its current form. Whilst I don't agree with all of his complaints, he makes a fair point about the re module Unicode support. It seems that the specific issue he has could be fixed by accepting the re module improvement / overhaul implemented by mrab: http://bugs.python.org/issue2636 As it comes with an active maintainer, and is a big step forward for Python regex support, I'd like to see it in Python 3.3. Reading through the issue it's not clear to me what needs to be done for it to be accepted (or rejected), beyond a general it's a big change. I've been using mrab's regex daily for about six months, and have found it stable and useful. It now includes two features which are both unusual and useful (very Pythonic!), named lists and fuzzy matching. 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] Fixing the XML batteries
Mike Meyer m...@mired.org wrote: On Fri, 09 Dec 2011 09:02:35 +0100 Stefan Behnel stefan...@behnel.de wrote: a) The stdlib documentation should help users to choose the right tool right from the start. b) cElementTree should finally loose it's special status as a separate library and disappear as an accelerator module behind ElementTree. +1 and +1. I've done a lot of xml work in Python, and unless you've got a particular reason for wanting to use the dom, ElementTree is the only sane way to go. I use ElementTree for parsing valid XML, but minidom for producing it. I think another thing that might go into refreshing the batteries is a feature comparison of BeautifulSoup and HTML5lib against the stdlib competition, to see what needs to be added/revised. Having to switch to an outside package for parsing possibly invalid HTML is a pain. 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] Fixing the XML batteries
Xavier Morel python-...@masklinn.net wrote: On 2011-12-09, at 19:15 , Bill Janssen wrote: I use ElementTree for parsing valid XML, but minidom for producing it. Could you expand on your reasons to use minidom for producing XML? Inertia, I guess. I tried that first, and it seems to work. I tend to use html5lib and/or BeautifulSoup instead of ElementTree, and that's mainly because I find the documentation for ElementTree is confusing and partial and inconsistent. Having various undated but obsolete tutorials and documentation still up on effbot.org doesn't help. 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] readd u'' literal support in 3.3?
=?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= mar...@v.loewis.de wrote: While this is true for FORTRAN, it is not for Python 1.5: no new Python 1.5 code is written around the world, at least not every day. I don't know about that. I've seen a lot of Python 2 code which was apparently written by folks who learned Python 1.5.2 and never needed to learn about newer features. I suspect that's still going on fairly widely. 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] Snow Leopard buildbot failing again...
Antoine Pitrou solip...@pitrou.net wrote: On Mon, 27 Jun 2011 10:01:13 PDT Bill Janssen jans...@parc.com wrote: I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: Well, doesn't the slave work correctly now? Or is there a problem? It does seem to have connected, but the error message from buildslave is new. Let's see if it goes into the zombie state again running 0.8.4. The Tiger buildbot (an old dual-1GHz G4 running buildbot-slave 0.8.1p1) is the only one which seems to run reliably :-). 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] open(): set the default encoding to 'utf-8' in Python 3.3?
M.-A. Lemburg m...@egenix.com wrote: How about a more radical change: have open() in Py3 default to opening the file in binary mode, if no encoding is given (even if the mode doesn't include 'b') ? +1. That'll make it compatible to the Py2 world again and avoid all the encoding guessing. Yep. 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] open(): set the default encoding to 'utf-8' in Python 3.3?
Terry Reedy tjre...@udel.edu wrote: Making such default encodings depend on the locale has already failed to work when we first introduced a default encoding in Py2, so I don't understand why we are repeating the same mistake again in Py3 (only in a different area). I do not remember any proposed change during the Py3 design discussions. I certainly proposed it, more than once. 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] EuroPython Language Summit report
Michael Foord fuzzy...@voidspace.org.uk wrote: The new regex library has some great improvements: http://bugs.python.org/issue2636 It also has users and committed maintainers, so I hope we can bring it into 3.3. It wasn't easy to tell from skimming the change notes that Unicode character classes are amongst the new features. Is that the case? According to http://effbot.org/zone/unicode-objects.htm (from 2004), the existing re module already supports Unicode character classes, so the regex module will as well. But the support has been updated, according to the change notes. 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] EuroPython Language Summit report
Michael Foord fuzzy...@voidspace.org.uk wrote: Thanks. Support for Unicode character classes was one of the improvements needed in the re module reported from the language summit - so I wonder if the changes in regex are sufficient. I guess it depends on what you're asking -- what does support for Unicode character classes mean? Apparently something different from what it meant in 2004 :-). 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] Issue10403 - using 'attributes' instead of members in documentation
Nick Coghlan ncogh...@gmail.com wrote: And no, the fact that methods can be treated as attributes is not a minor detail. It is *fundamental* to Python's object model that *methods are not a special case of attribute access*. All attributes work the same way, it is just the way functions implement the descriptor protocol that makes instance methods behave the way they do. Well put, Nick. This paragraph is a good thing to read a couple of times. 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
[Python-Dev] Snow Leopard buildbot failing again...
I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: $ buildslave start ~/buildarea/ /Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/internet/_sslverify.py:5: DeprecationWarning: the md5 module is deprecated; use hashlib instead import itertools, md5 Following twistd.log until startup finished.. /Library/Python/2.6/site-packages/buildbot_slave-0.8.4-py2.6.egg/buildslave/scripts/logwatcher.py:67: PotentialZombieWarning: spawnProcess called, but the SIGCHLD handler is not installed. This probably means you have not yet called reactor.run, or called reactor.run(installSignalHandler=0). You will probably never see this process finish, and it may become a zombie process. env=os.environ, /Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/persisted/sob.py:12: DeprecationWarning: the md5 module is deprecated; use hashlib instead import os, md5, sys /Library/Python/2.6/site-packages/Twisted-8.2.0-py2.6-macosx-10.6-universal.egg/twisted/python/filepath.py:12: DeprecationWarning: the sha module is deprecated; use the hashlib module instead import sha 2011-06-27 09:45:31-0700 [-] Log opened. 2011-06-27 09:45:31-0700 [-] twistd 8.2.0 (/usr/bin/python 2.6.1) starting up. 2011-06-27 09:45:31-0700 [-] reactor class: twisted.internet.selectreactor.SelectReactor. 2011-06-27 09:45:31-0700 [-] Starting BuildSlave -- version: 0.8.4 2011-06-27 09:45:31-0700 [-] recording hostname in twistd.hostname The buildslave took more than 10 seconds to start, so we were unable to confirm that it started correctly. Please 'tail twistd.log' and look for a line that says 'configuration update complete' to verify correct startup. $ Now, I thought of updating Twisted, but the Twisted downloads page says, ``Twisted is no longer making a .dmg for OS X because OS X versions 10.5 and greater ship with Twisted installed and the default Python path configuration makes it impossible for a user to upgrade Twisted without possibly breaking applications which depend on the system Twisted installation.'' Anyone know just what those applications are? All this machine is doing is running the Python buildbot. 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] Snow Leopard buildbot failing again...
exar...@twistedmatrix.com wrote: On 05:01 pm, jans...@parc.com wrote: I see that parc-snowleopard-1 went down again. I've done a software update, rebooted, and installed the latest buildslave, 0.8.4. I can ping dinsdale.python.org successfully from the machine. However, when I start the buildslave, I get this: [snip] The buildslave took more than 10 seconds to start, so we were unable to confirm that it started correctly. Please 'tail twistd.log' and look for a line that says 'configuration update complete' to verify correct startup. Did you look at twistd.log? Jean-Paul Um... not to look for configuration update complete, I'm afraid. Isn't that a buildmaster-only thing? Here's what was there. 2011-06-27 09:45:31-0700 [-] Log opened. 2011-06-27 09:45:31-0700 [-] twistd 8.2.0 (/usr/bin/python 2.6.1) starting up. 2011-06-27 09:45:31-0700 [-] reactor class: twisted.internet.selectreactor.SelectReactor. 2011-06-27 09:45:31-0700 [-] Starting BuildSlave -- version: 0.8.4 2011-06-27 09:45:31-0700 [-] recording hostname in twistd.hostname 2011-06-27 09:46:01-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x101637368 2011-06-27 09:46:01-0700 [-] Connecting to dinsdale.python.org:9020 2011-06-27 09:46:02-0700 [Broker,client] message from master: attached 2011-06-27 09:46:02-0700 [Broker,client] I have a leftover directory '3.1.parc-snowleopard-1' that is not being used by the buildmaster: you can delete it now 2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow Leopard 2 custom): message from master: attached 2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow Leopard 2 2.7): message from master: attached 2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow Leopard 2 3.x): message from master: attached 2011-06-27 09:46:03-0700 [Broker,client] SlaveBuilder.remote_print(AMD64 Snow Leopard 2 3.2): message from master: attached 2011-06-27 09:46:05-0700 [Broker,client] Connected to dinsdale.python.org:9020; slave is ready 2011-06-27 09:46:05-0700 [Broker,client] sending application-level keepalives every 600 seconds There is that 30-second lag between recording hostname in twistd.hostname and Starting factory, which is presumably what triggers the warning from buildslave. See http://trac.buildbot.net/ticket/68 and http://trac.buildbot.net/ticket/745. 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] Snow Leopard buildbot failing again...
I also find http://trac.buildbot.net/ticket/1854 interesting, because it seems a good explanation of why the build slave might go into the zombie state of attempting to reconnect to the master. 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] Stable buildbots update
Ned Deily n...@acm.org wrote: In article 87zkmcalt8@uwakimon.sk.tsukuba.ac.jp, Stephen J. Turnbull step...@xemacs.org wrote: Are you saying you expect Mac OS X 10.4 Tiger to go green once the bots update? If so, I'm impressed, and thank you! to all involved. Apple and MacPorts have long since washed their hands of that release. OS X 10.4 does have its quirks that makes it challenging to get all of the tests to run without a few cornercase failures but, besides the buildbots, I still test regularly with 10.4 and occasionally build there, too. And, FWIW, while top-of-trunk MacPorts may not officially support 10.4, many ports work there just fine including python2.6, 2.7, and 3.1. (3.2 has a build issue that may get fixed in 3.2.1). Perhaps more importantly, parc-leopard-1 and parc-tiger-1 are two of the very few usually-connected buildbots we have running on big-endian architectures, along with loewis-sun (I *think* Solaris-10 on SPARC is still big-endian). 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] Stable buildbots update
Tarek Ziadé ziade.ta...@gmail.com wrote: Yes, I am aware of this. I have fixed today most remaining issues, and fixing the final ones right now. Just FYI: the AMD64 Snow Leopard buildbot and PPC Leopard buildbots are now green, but the PPC Tiger buildbot is still failing for all branches because of packaging errors: == FAIL: test_user_site (packaging.tests.test_command_install_dist.InstallTestCase) -- Traceback (most recent call last): File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/packaging/tests/test_command_install_dist.py, line 95, in test_user_site self._test_user_site() File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/packaging/tests/test_command_install_dist.py, line 124, in _test_user_site self.assertTrue(os.path.exists(self.user_base)) AssertionError: False is not true == FAIL: test_get_outputs (packaging.tests.test_command_install_lib.InstallLibTestCase) -- Traceback (most recent call last): File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/packaging/tests/test_command_install_lib.py, line 71, in test_get_outputs self.assertEqual(len(cmd.get_outputs()), 4) AssertionError: 2 != 4 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] Python 3.x and bytes
Georg Brandl g.bra...@gmx.net wrote:
We do have
bytes.fromhex('deadbeef')
Sort of reminds me of Java's Integer.parseInt(), and not in a good way.
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] Simple XML-RPC server over SSL/TLS
Éric Araujo mer...@netwok.org wrote: Hi, But what I would like to know, is if is there any reason why XML-RPC can't optionally work over TLS/SSL using Python's ssl module. I'll create a ticket, and send a patch, but I was wondering if it was a reason why this was not implemented. I think there’s no deeper reason than nobody thought about it. The ssl module is new in 2.6 and 3.x, xmlrpc is an older module for an old technology *cough*, so feel free to open a bug report. Patch guidelines are found at http://docs.python.org/devguide Thanks in advance! What he said. I'm not a big fan of XMLRPC in the first place, so I probably didn't even notice that there wasn't SSL support for it. Go for 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
[Python-Dev] funky buildbot problems again...
My Intel Snow Leopard 2 build slave has gone into outer-space again. When I look at it, I see buildslave taking up most of a CPU (80%), and nothing much else going on. The twistd log says: [... much omitted ...] 2011-04-04 08:35:47-0700 [-] sending app-level keepalive 2011-04-04 08:45:47-0700 [-] sending app-level keepalive 2011-04-04 08:55:47-0700 [-] sending app-level keepalive 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] Lost connection to dinsdale.python.org:9020 2011-04-04 09:03:15-0700 [Broker,client] twisted.internet.tcp.Connector instance at 0x101629ab8 will retry in 3 seconds 2011-04-04 09:03:15-0700 [Broker,client] Stopping factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:18-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:18-0700 [-] Connecting to dinsdale.python.org:9020 2011-04-04 09:03:18-0700 [Uninitialized] Connection to dinsdale.python.org:9020 failed: Connection Refused 2011-04-04 09:03:18-0700 [Uninitialized] twisted.internet.tcp.Connector instance at 0x101629ab8 will retry in 8 seconds 2011-04-04 09:03:18-0700 [Uninitialized] Stopping factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:27-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:27-0700 [-] Connecting to dinsdale.python.org:9020 So it's been spinning its wheels for 3 days. Sure looks like the connection attempt is failing, for some reason. I'm using the stock Twisted that comes with Snow Leopard -- tried to upgrade it but apparently can't. On my OS X 10.4 buildslave, I see a similar but more successful sequence: 2011-04-04 08:56:06-0700 [-] sending app-level keepalive 2011-04-04 09:04:39-0700 [Broker,client] lost remote 2011-04-04 09:04:39-0700 [Broker,client] lost remote 2011-04-04 09:04:39-0700 [Broker,client] lost remote 2011-04-04 09:04:39-0700 [Broker,client] lost remote 2011-04-04 09:04:39-0700 [Broker,client] lost remote 2011-04-04 09:04:39-0700 [Broker,client] twisted.internet.tcp.Connector instance at 0x10352d8 will retry in 3 seconds 2011-04-04 09:04:39-0700 [Broker,client] Stopping factory buildslave.bot.BotFactory instance at 0x133bd78 2011-04-04 09:04:42-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x133bd78 2011-04-04 09:04:43-0700 [Uninitialized] twisted.internet.tcp.Connector instance at 0x10352d8 will retry in 10 seconds 2011-04-04 09:04:43-0700 [Uninitialized] Stopping factory buildslave.bot.BotFactory instance at 0x133bd78 2011-04-04 09:04:53-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x133bd78 2011-04-04 09:04:57-0700 [Broker,client] message from master: attached 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] funky buildbot problems again...
Michael Foord fuzzy...@voidspace.org.uk wrote: On 07/04/2011 21:31, Bill Janssen wrote: My Intel Snow Leopard 2 build slave has gone into outer-space again. [snip...] So it's been spinning its wheels for 3 days. Sure looks like the connection attempt is failing, for some reason. I'm using the stock Twisted that comes with Snow Leopard -- tried to upgrade it but apparently can't. You certainly shouldn't update the Twisted on your system Python. Can't you install Python 2.6 (from python.org) separately and install Twisted into that? Apparently not. That's what I tried first -- install Python 2.7, and then the latest Twisted. 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] funky buildbot problems again...
exar...@twistedmatrix.com wrote: On 08:31 pm, jans...@parc.com wrote: My Intel Snow Leopard 2 build slave has gone into outer-space again. When I look at it, I see buildslave taking up most of a CPU (80%), and nothing much else going on. The twistd log says: [... much omitted ...] 2011-04-04 08:35:47-0700 [-] sending app-level keepalive 2011-04-04 08:45:47-0700 [-] sending app-level keepalive 2011-04-04 08:55:47-0700 [-] sending app-level keepalive 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] lost remote 2011-04-04 09:03:15-0700 [Broker,client] Lost connection to dinsdale.python.org:9020 2011-04-04 09:03:15-0700 [Broker,client] twisted.internet.tcp.Connector instance at 0x101629ab8 will retry in 3 seconds 2011-04-04 09:03:15-0700 [Broker,client] Stopping factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:18-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:18-0700 [-] Connecting to dinsdale.python.org:9020 2011-04-04 09:03:18-0700 [Uninitialized] Connection to dinsdale.python.org:9020 failed: Connection Refused 2011-04-04 09:03:18-0700 [Uninitialized] twisted.internet.tcp.Connector instance at 0x101629ab8 will retry in 8 seconds 2011-04-04 09:03:18-0700 [Uninitialized] Stopping factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:27-0700 [-] Starting factory buildslave.bot.BotFactory instance at 0x1016299e0 2011-04-04 09:03:27-0700 [-] Connecting to dinsdale.python.org:9020 So it's been spinning its wheels for 3 days. Does this mean that the 2011-04-04 09:03:27-0700 [-] Connecting to dinsdale.python.org:9020 message in the logs is the last one you see until you restart the slave? Yes, that's the last line in the file. Or does it mean that the logs go on and on for three days with these Connecting to dinsdale / Connection Refused / ... will retry in N seconds cycles, thousands and thousands of times? Well, it's doing something, chewing up cycles, but there's only one Connecting line at the end of the log file. What does the buildmaster's info page for this slave say when the slave is in this state? In particular, what does it say about connects/hour? Ah, good question. Too bad I restarted the slave after I sent out my info. Is there some way to recover that from earlier? If not, it will undoubtedly fail again in a few days. 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
[Python-Dev] funky buildbot
I'm trying to get a new buildbot in the swim of things, and it keeps getting into this state where the buildslave process seems caught in an endless loop. Perhaps someone here knows why? It's a new Mac Mini running the latest Snow Leopard, with Python 2.6.1 (the /usr/bin/python) and buildslave 0.8.3, using Twisted 8.2.0. 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] funky buildbot
David Bolen db3l@gmail.com wrote: Bill Janssen jans...@parc.com writes: I'm trying to get a new buildbot in the swim of things, and it keeps getting into this state where the buildslave process seems caught in an endless loop. Perhaps someone here knows why? Do you have any information as to what it is doing while in the loop? Not much. The twistd log shows that it is, in fact, trying to reconnect to the build master. It's just chewing up 100% CPU. Could just be updates to the master that are doing this, but my other (PPC) buildbots seem OK with it. Bill I think the only obvious looping I've seen with any of my buildbots is a loop while trying to attach to the master, either because the master was down/unreachable, rejecting connections (bad user/password), not yet configured for my buildbot, or occasionally because it thought the buildbot was still attached. In that latter case I just had to wait long enough for the status page to switch from idle to disconnected and then try again. -- 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/bill%40janssen.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] funky buildbot
David Bolen db3l@gmail.com wrote: There used to be a way to request a ping from the master side (I think on the same page you could manually run a build from) that I would used to force it to recognize a slave was really down, but after the web interface got rearranged a while back, I can't seem to find the option any more. Looks like the ping option is back now :-). I restarted the buildslave, and it built 3.2 OK. Still don't know what's up, but this runaway buildslave condition has happened three times in the last week or so. 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] [Python-checkins] r88395 - python/branches/py3k/Lib/asyncore.py
Giampaolo Rodolà g.rod...@gmail.com wrote: Although I don't use it, it seems that Twisted managed to do this by splitting the concepts of transport and protocol / application and by using zope.interface. You might want to look at the ILU core, too, just for ideas. Somewhat to my surprise, the link http://www2.parc.com/istl/projects/ILU/ still works. The protocol/transport distinction is at ftp://ftp.parc.xerox.com/pub/ilu/2.0b1/manual-html/manual_14.html#SEC475. The key requirements for an async loop, IMO, are the normal file descriptor state change notifications, support for timer events, and support for time-bounded work tasks (that get run when nothing is happening). The Tornado IOLoop does all three of these; also worth taking a look at: http://www.tornadoweb.org/. 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] Python merge module
Martin v. Löwis mar...@v.loewis.de wrote: The Installer COM object is the platform standard mechanism, and that's what msilib uses. I really see no need to move away from that - it can create arbitrary MSI files. I've used it to package UpLib for Windows -- see http://uplib.parc.com/hg/uplib/file/e29e36f751f7/win32/build-msi-installer.py. I've generalized some of Martin's code to create a Packager class which supports non-Python pre and post install scripts. I found it much easier to use than WiX, which I also tried. 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] devguide: Cover how to (un-)apply a patch.
Steven D'Aprano st...@pearwood.info wrote: s...@pobox.com wrote: I realize the world is passing me by and that I'm rapidly turning into a dinosaur w.r.t. distributed version control, but as you write/update the developer's guide remember that proficiency in Python does not necessarily equate to proficiency in version control systems, especially with the less frequently used commands. I personally would prefer that more general commands and concepts be used where possible so that newcomers not be put off unnecessarily by the complexity of version control. What he said, only bolded and underlined. Indeed. I now have to deal with an unholy mix of CVS, Subversion, git, and Mercurial -- a twisty maze of little one-letter options, all so similar, all too powerful. At least with CVS and Subversion you could concentrate your mistakes on a single file :-). 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] PEP 3333: wsgi_string() function
P.J. Eby p...@telecommunity.com wrote: Right. Also, it should be mentioned that none of this would be necessary if we could've gotten a bytes of a known encoding type. Indeed! Or even string using a known encoding... If you look back to the last big Python-Dev discussion on bytes/unicode and stdlib API breakage, this was the holdup for getting a sane WSGI spec. Yep. 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] Using logging in the stdlib and its unit tests
Glenn Linderman v+pyt...@g.nevcal.com wrote: On 12/10/2010 12:06 AM, Vinay Sajip wrote: This simplistic easy usage somewhat echo's Glenn's comment on this thread about logging seeming way to daunting as presented today. It needn't be. Indeed, and the very first code sample in the logging documentation shows exactly the simplistic easy usage you're talking about. I can't see why anyone would be scared off by that example. It didn't scare me off. But it wasn't _quite_ comprehensive enough to keep me from being put off by the next bit of manual, (about 8%, as mentioned before), which had lots of discussion, but no more examples, so what is lacking up front is a few more examples of using the convenience methods as Greg apparently does, without configuration, but showing use in multiple modules. After it is shown to be simple to get started in a multi-module code base, then all the refinements can be explained and added, but by then people are already using the logger, and learning becomes incremental. Just a note: after spacing out over this thread for a bit, I thought I'd try out logging, which I'd never tried before, in some code I was writing. I added a couple of lines like logging.info(foo is %s, foo) where I'd usually write sys.stderr.write(foo is %s\n % foo) Liked it just fine -- easier to write. But nothing came out! Because it's got this odd idea (from Java?) about severities of messages, and by default passes nothing less threatening than warnings, because logger.root is initialized by default to WARNING. So, still a bit disconcerting for newbies. 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] Using logging in the stdlib and its unit tests
Guido van Rossum gu...@python.org wrote: And yet, I have helped many people who were baffled by exactly what Bill observed: logging.info() didn't do anything. Maybe the default should be INFO? Yeah, I was curious enough to read the code and find out why. But many won't. By the way, I tried reading the 2.7 docs first, and didn't figure it out from them. So I looked at the code. 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] Using logging in the stdlib and its unit tests
Glenn Linderman v+pyt...@g.nevcal.com wrote: 1) simple example for one file programs, include an example of specifying output severity threshold. I'm with Antoine here on my expectations. Yes, once I put logging.basicConfig(stream=sys.stdout, level=logging.DEBUG) in my main(), I got what I thought I'd get in the first place. All logging messages. But I can see Antoine's point: if we use this in the stdlib, you don't want that default. I think that logging events (context) have to come into this; you can't do it with just severity alone. I'd expect to have different settings, by default, for __main__ and for http.client, for instance. 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] constant/enum type in stdlib
Isaac Morland ijmor...@uwaterloo.ca wrote: On Tue, 23 Nov 2010, Antoine Pitrou wrote: Le mardi 23 novembre 2010 à 12:32 -0500, Isaac Morland a écrit : On Tue, 23 Nov 2010, Antoine Pitrou wrote: We already have a bunch of bizarrely unrelated stuff in collections (such as Callable), so we could put enum there too. Why not just enum (i.e., from enum import [...] or import enum.[...])? Enumerations are one of the basic kinds of types overall (speaking informally and independent of any specific language) - they aren't at all exotic. Enumerations aren't a type at all (they have no distinguishing property). Not in C, but in some other languages. Each enumeration is a type (well, OK, not in every language, presumably, but certainly in many languages). The main purpose of that is to be able to catch type mismatches with static typing, though. Seems kind of pointless for Python. Classes have their own keyword. I don't think it's disproportionate to give enums a top-level module name. I do. Hey, how about this syntax: enum Colors: red = 0 green = 10 blue Why not class Color: red = (255, 0, 0) green = (0, 255, 0) blue = (0, 0, 255) Seems to handle the situation OK. 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] Help deploying a new buildbot running OpenIndiana/x86
Jesus Cea j...@jcea.es wrote: On 17/11/10 17:23, Antoine Pitrou wrote: There is no incoming connection; however, a bunch of outgoing connections are made to various hosts by various tests, so it's better if there's no overzealous firewall in-between. For those of us who can't do that, there's a list of what machines the testing framework needs to be able to reach at http://wiki.python.org/moin/BuildBot. If you modify the tests, please keep that list up-to-date. 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] Stable buildbots
Ned Deily n...@acm.org wrote:
In article 30929.1289879...@parc.com, Bill Janssen jans...@parc.com
wrote:
Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
Looking at the changes since the last success, I can't see anything
which would obviously affect that... Any suspects?
It appears to be a duplicate of Issue8458. Playing with it again, it
seems to be a race condition: sometimes I see all three failures you
reported, sometimes just one, sometimes none. Again, only on 10.4
(Tiger), not 10.5 or 10.6. But the 10.4 machine I'm using is by far the
slowest of the three so it is possible that could be a factor.
Good thought. It's also the slowest of my buildbots -- dual 1GHz PPC.
Perhaps a race condition with cleaning up the p2c pipe from a previous run?
Here's what's failing:
==
ERROR: test_run_code (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py
, line 95, in test_run_code
assert_python_failure('-c')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 29, in _assert_python
env=env)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_run_module (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py
, line 72, in test_run_module
assert_python_failure('-m')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 29, in _assert_python
env=env)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_version (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py
, line 48, in test_version
rc, out, err = assert_python_ok('-V')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 48, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py
, line 29, in _assert_python
env=env)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
--
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/bill%40janssen.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] Stable buildbots
Both the Tiger buildbots are suddenly failing 3.x on test_cmd_line.
Looking at the changes since the last success, I can't see anything
which would obviously affect that... Any suspects?
Here's what's failing:
==
ERROR: test_run_code (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 95, in test_run_code
assert_python_failure('-c')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_run_module (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 72, in test_run_module
assert_python_failure('-m')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 55, in assert_python_failure
return _assert_python(False, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
==
ERROR: test_version (test.test_cmd_line.CmdLineTest)
--
Traceback (most recent call last):
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/test_cmd_line.py,
line 48, in test_version
rc, out, err = assert_python_ok('-V')
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 48, in assert_python_ok
return _assert_python(True, *args, **env_vars)
File
/Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/test/script_helper.py,
line 29, in _assert_python
env=env)
File /Users/buildbot/buildarea/3.x.parc-tiger-1/build/Lib/subprocess.py,
line 683, in __init__
self.stdin = io.open(p2cwrite, 'wb', bufsize)
OSError: [Errno 9] Bad file descriptor
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] [Python-checkins] r86441 - python/branches/py3k/Lib/test/test_nntplib.py
Antoine Pitrou solip...@pitrou.net wrote: On Sat, 13 Nov 2010 07:30:05 -0500 James Y Knight f...@fuhm.net wrote: On Nov 13, 2010, at 7:08 AM, Antoine Pitrou wrote: Funny, it shows that the NNTP SSL tests don't check the certificate, then. Unsurprising, given that you need 140 lines of pretty non-obvious python code to do so... You must have missed the new match_hostname() function: http://docs.python.org/dev/library/ssl.html#ssl.match_hostname (its implementation is 50 lines rather than 140 lines, though) On the client side, it's pretty easy to see an invalid (say, expired) certificate. Just call get_server_certificate(), which will fail if the server certificate is invalid. That's a separate issue from matching the request hostname to the various host identifiers in the certificate, which various application protocols may or may not require. 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] Continuing 2.x
Kristján Valur Jónsson krist...@ccpgames.com wrote: Let's move the current 'trunk' into /branches/afterlife-27. Open it for submissions from people such as myself that use 2.7 on a regular basis and are willing to give it some extra love. Though I'm not personally convinced it's a good idea, I can see where some could find it useful. Host it there without the usual stringent python quality assurance, buildbot support, release management and all that rigmarole. Open-source it, if you will. No real need to go that far, I think. The tests after all are part of the source tree, buildbots are still running them, etc. And if the buildbot master stops doing that, there are community buildbots for testing things like this. Release management is going to happen one way or another. 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
[Python-Dev] PPC Leopard buildbot failing sqlite test for Python 3.2
There was a test added to the sqlite suite between 3.1 and the current 3.x trunk, TestInTransaction. It's failing pretty consistently on the PPC Leopard buildbot (2.7 and 3.1 are testing OK). Calling sqlite3.sqlite_version returns 3.4.0. A couple of things come to mind: * Does this require a different flavor of the sqlite libraries? I looked through the 3.x docs and couldn't find any mention of a specific sqlite version. * Is this a big-endian bug? Might fail on SPARC, too, then. What should I look at? 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] PPC Leopard buildbot failing sqlite test for Python 3.2
R. David Murray rdmur...@bitdance.com wrote: On Sat, 16 Oct 2010 13:14:20 -0700, Bill Janssen jans...@parc.com wrote: There was a test added to the sqlite suite between 3.1 and the current 3.x trunk, TestInTransaction. It's failing pretty consistently on the PPC Leopard buildbot (2.7 and 3.1 are testing OK). Calling sqlite3.sqlite_version returns 3.4.0. A couple of things come to mind: * Does this require a different flavor of the sqlite libraries? I looked through the 3.x docs and couldn't find any mention of a specific sqlite version. That's what I was wondering (I see you found the relevant issue...), but it doesn't *seem* to be a version issue, but it would be cool if you could check it against 3.7 just for confirmation. * Is this a big-endian bug? Might fail on SPARC, too, then. It might be, except for two things: it passes on the Sparc Solaris 10 buildbot, For 3.x, the SPARC Solaris gcc buildbot says, [ 87/349] test_sqlite test_sqlite skipped -- No module named _sqlite3 and the io module also makes use of a T_BOOL field and its tests pass on all buildbots. On the flip side, the only other failure I've see was on the Debian Sparc buildbot. Which claims it is running sqlite 3.7.2-1. It works for me using 3.7.2 on Gentoo i86. What should I look at? Good question :) When I added this it seemed like such a simple thing. Maybe the endianness issue is the one to look at, despite the pass on Solaris. The SPARC architecture supports either big-endian and little-endian use (as does the PowerPC -- actually, I think any program can switch endianness on the PowerPC, except...); the OS gets to decide. I'd expect Solaris on SPARC to run big-endian, like OS X on PPC, and Wikipedia says Ubuntu on SPARC runs big-endian, too. Except: PPC Leopard is running on a G5 process, a PowerPC 970. As far as I know, that's the only PowerPC chip that couldn't run either-endian -- it only runs big-endian. So that code has to be running big-endian on PPC Leopard. Looks like it's not passing on any big-endian architecture. 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
[Python-Dev] PPC Tiger is back up
I've moved the OS X buildbot parc-tiger-1 (PPC Tiger) to new hardware, a MDD dual-G4 PowerMac with more memory. Should move considerably faster. Enjoy! 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] sad state of OS X Python testing...
Sorry to drop out like that -- I've been having some email issues. Stephen, great job; thanks for providing that Snow Leopard buildbot. I think what we're missing now is an Intel Leopard buildbot. 35% of Mac users are still running Leopard. I'm running it myself on some machines, due to the NIS issues in Snow Leopard. And, of course, we'd like to get some of these Mac buildbots into the stable category, so that they are consulted for releases. The PPC Leopard and x86 Snow Leopard buildbots look like good candidates. 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
[Python-Dev] PPC Tiger buildbot going down for an upgrade
I've found a dual-processor G4 to run the PPC Tiger buildbot on (it's currently an old e Mac), and I plan to take this buildbot down tomorrow, Wednesday, to upgrade. 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
[Python-Dev] the PPC Leopard buildbot is back online
I've finished upgrading the PPC Leopard builder to a dual 2 GHz G5 machine. Tests should run a bit faster now that the eMac is out of the loop :-). I'm looking for a faster machine for the PPC Tiger buildbot. 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
[Python-Dev] sad state of OS X Python testing...
Folks, I was looking at the buildbots again. Do you realize that we have no OS X Snow Leopard buildbot? No Intel Leopard buildbot? Well over half of Mac users are using Snow Leopard, and we're not testing on that platform. In fact, the only Intel OS X machine we're testing on is a Core Duo, not a Core 2 Duo, and that's running Tiger. Surely someone could volunteer an old Intel Mac to run some tests? (Actually, two someones -- we'd need separate machines for Leopard and Snow Leopard.) I'd be happy to stick it in a server room at PARC and keep an eye on it. (Right now I've got a rack full of old eMacs and a G5 running PPC buildbots.) Perhaps we could get Apple to contribute some seconds? I believe donations to the PSF are deductible. 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
[Python-Dev] PPC Leopard build slave going down for an upgrade
I'm replacing the PPC Leopard build slave with a dual 2GHz G5 machine... 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] Rework nntlib?
Jesse Noller jnol...@gmail.com wrote: no one seems to take the betas or alphas for serious test drives (to be expected) with real code I wonder if there's some way to improve that situation -- perhaps by some engineering of the Python packaging, or some such? 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] Rework nntlib?
Interesting. I personally use nis and poplib quite a bit, but I can see how that would be very location-dependent. 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] Python Language Summit EuroPython 2010
Tim, thanks for this write-up! 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] Removing IDLE from the standard library
Stephen Hansen apt.shan...@gmail.com wrote: On Sun, Jul 11, 2010 at 4:53 PM, Steve Holden st...@holdenweb.com wrote: Stephen Hansen wrote: On Sat, Jul 10, 2010 at 9:23 PM, Guilherme Polo ggp...@gmail.com mailto:ggp...@gmail.com wrote: By never had a problem do you mean using some of the latest versions ? Here, running idle from a mac terminal and trying to type: print hi crashes when entering the quotation mark. Huh? Works fine for me. Python 2.6.1, OSX 10.6.3, intel. One of the good things about the python-dev community is its commitment to test-driven development. If you are prepared to define fine as 'successfully runs \'print hello\'' then I guess we should be perfectly happy about IDLE. Er, how hostile. My point is, the poster made an assertion-- that you couldn't do the simple act as launching idle from a command line, and printing Hi. Maybe they can't, I have no idea. I know I can. I know that I have also opened random python files, saved them, and ran them with IDLE. I don't use IDLE beyond that though: I live in TextMate on my mac. My point was not, IDLE is perfect. My point was, You've claimed you can't even print out a word in IDLE, so its utterly and completely non-functional -- and that assertion surprises me and I challenge. Steve, you encouraged me to try it again. From an xterm on OS X 10.5.8, it launches fine (long as you know where it is -- /System/Library/Frameworks/Python.framework/Versions/Current/bin/idle). Seems to work OK for what it is, too. Same for Terminal. When I start it from the *shell* buffer in Cocoa GNU Emacs, though, the idle window pops up under the Emacs window, which is why I didn't see it over the weekend. 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] Removing IDLE from the standard library
Tal Einat talei...@gmail.com wrote: Although several people say that they think having IDLE in the stdlib is important, the fact is that IDLE is considered quite unimportant by most of the Python community. Having IDLE in the stdlib may be convenient for a few people, but most never use it and don't care about it. I think that in its current state, IDLE may still be helpful for learning Python, but it is more likely to drive away users who run into its various quirks and problems. And for experienced Python developers, very few actually use IDLE, and those who do could easily install it if it weren't part of the stdlib. I agree with you on this, Tal. On OS X, this is particularly aggravating, as the Apple-supplied Python doesn't seem to include a working version, and installing MacPython leads to other problems (see, for instance, the thread at http://groups.google.com/group/nltk-users/browse_thread/thread/e14b647243ca5b66). For David and other teachers, there are plenty of alternative IDEs, outlined at http://wiki.python.org/moin/IntegratedDevelopmentEnvironments. 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] Can ftp url start with file:// ?
Fred Drake fdr...@acm.org wrote: On Sat, Jul 10, 2010 at 11:56 PM, Senthil Kumaran orsent...@gmail.com wro= te: I see the reason. But I doubt if this is a reliable approach. =A0Also when the scheme begins with file:// it should not be confused with ftp, so I think, that portion of code in urllib which work that way should be removed. I'm not trying to defend the current behavior of defaulting to FTP as a good thing; it's definitely surprising. I am trying to rationalize it so I can be sure I understand why it might have been done to start with. My own preference is to kick out any non-local references with an exception that can be detected (possibly derived from ValueError) so that applications that want rewrite (hopefully with user agreement!) can do so. (Checking for non-local file: URLs on input might be better, of course.) Sounds like a good plan to me, too. 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] Can ftp url start with file:// ?
Senthil Kumaran orsent...@gmail.com wrote: On Fri, Jul 09, 2010 at 02:23:40PM +1000, Steven D'Aprano wrote: Is this is valid ftp url? # file://ftp.example.com/blah.txt (an ftp URL) My answer is no. When we have the scheme specifically mentioned as file:// it is no point in considering it as ftp url (which should start with ftp://). I agree. Just because the host is *called* ftp doesn't mean you should use the ftp protocol to get the file. It was not just for the host being called ftp.example.com It was for a pattern that file:/// is local file (correct) and file://localhost/somepath is again local file (correct again) but file://anyhost.domain/file.txt is actually ftp (pretty weird). RFC 1738 explicitly says that file://host/path is pretty much useless for anything except host=localhost: ``The file URL scheme is unusual in that it does not specify an Internet protocol or access method for such files; as such, its utility in network protocols between hosts is limited.'' So, FTP is *not* the default protocol. On the other hand, if host actually begins with ftp., it's a pretty good guess that FTP will work. Similarly, if host actually begins with www., it's a pretty good guess that HTTP will work. This seems to me like a practicality-vs.-purity consideration. 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] Can ftp url start with file:// ?
Tim Lesher tles...@gmail.com wrote:
On Fri, Jul 9, 2010 at 12:41, Bill Janssen jans...@parc.com wrote:
So, FTP is *not* the default protocol. On the other hand, if host
actually begins with ftp., it's a pretty good guess that FTP will
work.
Actually, FTP *is* the default protocol for most URLs with hostnames in
urllib.py.
urllib.open_file() delegates to open_ftp() if there's a any host other than
the exact string localhost, and open_local_file() otherwise.
I just meant to point out that it's not specified that way by any RFC.
And, while FTP might have been a good default choice last century when
urllib.py was originally written, times have changed. I'd suggest that
HTTP is a better (more likely to succeed) default choice in this century.
If we want to perpetuate these guessing heuristics, I'd suggest using
FTP if the hostname starts with ftp., and HTTP if the hostname starts
with www., and raise an error otherwise.
Bill
import urllib
f =urllib.urlopen('file:///foo.txt')
f =urllib.urlopen('file://localhost/foo.txt')
f = urllib.urlopen('file://www.google.com/')
Traceback (most recent call last):
File stdin, line 1, in module
File c:\python25\lib\urllib.py, line 82, in urlopen
return opener.open(url)
File c:\python25\lib\urllib.py, line 190, in open
return getattr(self, name)(url)
File c:\python25\lib\urllib.py, line 457, in open_file
return self.open_ftp(url)
File c:\python25\lib\urllib.py, line 538, in open_ftp
ftpwrapper(user, passwd, host, port, dirs)
File c:\python25\lib\urllib.py, line 844, in __init__
self.init()
File c:\python25\lib\urllib.py, line 850, in init
self.ftp.connect(self.host, self.port)
File c:\python25\lib\ftplib.py, line 129, in connect
raise socket.error, msg
IOError: [Errno ftp error] (10060, 'Operation timed out')
f =urllib.urlopen('file://127.0.0.1/foo.txt')
Traceback (most recent call last):
File stdin, line 1, in module
File c:\python25\lib\urllib.py, line 82, in urlopen
return opener.open(url)
File c:\python25\lib\urllib.py, line 190, in open
return getattr(self, name)(url)
File c:\python25\lib\urllib.py, line 457, in open_file
return self.open_ftp(url)
File c:\python25\lib\urllib.py, line 538, in open_ftp
ftpwrapper(user, passwd, host, port, dirs)
File c:\python25\lib\urllib.py, line 844, in __init__
self.init()
File c:\python25\lib\urllib.py, line 850, in init
self.ftp.connect(self.host, self.port)
File c:\python25\lib\ftplib.py, line 129, in connect
raise socket.error, msg
IOError: [Errno ftp error] (10061, 'Connection refused')
--
Tim Lesher tles...@gmail.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/janssen%40parc.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] OS X buildbots: why am I skipping these tests?
Guido van Rossum gu...@python.org wrote: On Tue, Jun 29, 2010 at 7:55 PM, Bill Janssen jans...@parc.com wrote: My Leopard and Tiger PPC buildbots are momentarily green! But I'm looking into why I'm skipping some tests. My buildbots are up-to-date OS-wise and very vanilla, with the latest applicable Xcode. 4 skips unexpected on darwin: test_gdb test_ioctl test_readline test_ttk_guionly Three of these (gdb, readline, ttk_guionly) are just bad predictions of which tests should skip on Darwin, I think -- gdb is only version 6, so that test won't run, readline doesn't get built, ttk doesn't work without Tcl/Tk 8.5. So it looks like you gould get readline and ttk to run and pass by separately downloading and installing readline (I've done this many times before) and Tcl/Tk (no idea but I suppose it should work). Sure. But the skips should be expected on Darwin, since a vanilla OS X system apparently won't have the necessary bits. At the very least, regrtest.py should test for these conditions and add them to the expected skips list if necessary. I'll work up a patch. But the the skip of test_ioctl baffles me. test_ioctl skipped -- Unable to open /dev/tty But when I log in via ssh and try it with the system python: ~ wjanssen$ python python Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. open(/dev/tty) open(/dev/tty) open file '/dev/tty', mode 'r' at 0x597b8 Seems to work fine. So this I don't understand. Any ideas, anyone? Maybe the buildbot runs the tests as a tty-less daemon process. If you ask me it's pretty crazy to have a test that requires a tty. But there you have it -- and it's the same in Python 3. (But then again, who knows, I might have written that test. ;-) So, my question then is, why are these skips unexpected? Seems to me that if this is the case, this test will never run on any platform. 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] OS X buildbots: why am I skipping these tests?
Martin v. Löwis mar...@v.loewis.de wrote: Seems to work fine. So this I don't understand. Any ideas, anyone? Didn't we discuss this before? Possibly, but I don't recall doing so. The buildbot slave has no controlling terminal anymore, hence it cannot open /dev/tty. If you are curious, just patch your checkout to output the exact errno (e.g. to stdout), and trigger a build through the web. So, why is skipping this test unexpected? I see x86 Tiger is also showing this as an unexpected skip. Should I just add it to the list of expected skips on Darwin? Actually, will it run on any platform? 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] OS X buildbots: why am I skipping these tests?
exar...@twistedmatrix.com wrote:
Could the test be rewritten (or supplemented) to use a pty? Most or
perhaps all of the same operations should be supported.
Buildbot seems to be explicitly not using a PTY. From the the top of
the test output:
make buildbottest
in dir /Users/buildbot/buildarea/trunk.parc-leopard-1/build (timeout 1800 secs)
watching logfiles {}
argv: ['make', 'buildbottest']
[...]
closing stdin
using PTY: False
I believe this is specified by the build master.
This test seems to work on Ubuntu and FreeBSD, though.
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] OS X buildbots: why am I skipping these tests?
Martin v. Löwis mar...@v.loewis.de wrote: The whole unexpected skipping is somewhat of a mess. In an ideal situation modules that are optionally built should be allowed to skip, While this may be the wide-spread interpretation, it is definitely *not* the original intention of the feature. When Tim Peters added it, he wanted it to tell him whether he did the Windows build correctly, INCLUDING ALL OPTIONAL PACKAGES that can possibly work on Windows. If you try to generalize this beyond Windows, then the only skips that are expected are the ones for tests that absolutely cannot work on the platform - i.e. Unix tests on Windows, and Windows tests on Unix. Otherwise, if you can get it to pass by installing additional software, Tim did *not* mean this to be an expected skip. Perfectly reasonable, good to know. So on my OS X buildbots I should update gdb, tcl/tk, and readline, so that those tests can run. Probably be good to put a note in the regrtest.py comments to this effect, as I don't see a PEP about testing or buildbots. 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
[Python-Dev] OS X buildbots: why am I skipping these tests?
My Leopard and Tiger PPC buildbots are momentarily green! But I'm looking into why I'm skipping some tests. My buildbots are up-to-date OS-wise and very vanilla, with the latest applicable Xcode. 4 skips unexpected on darwin: test_gdb test_ioctl test_readline test_ttk_guionly Three of these (gdb, readline, ttk_guionly) are just bad predictions of which tests should skip on Darwin, I think -- gdb is only version 6, so that test won't run, readline doesn't get built, ttk doesn't work without Tcl/Tk 8.5. But the the skip of test_ioctl baffles me. test_ioctl skipped -- Unable to open /dev/tty But when I log in via ssh and try it with the system python: ~ wjanssen$ python python Python 2.5.1 (r251:54863, Jun 17 2009, 20:37:34) [GCC 4.0.1 (Apple Inc. build 5465)] on darwin Type help, copyright, credits or license for more information. open(/dev/tty) open(/dev/tty) open file '/dev/tty', mode 'r' at 0x597b8 Seems to work fine. So this I don't understand. Any ideas, anyone? 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] thoughts on the bytes/string discussion
Guido van Rossum gu...@python.org wrote: On Fri, Jun 25, 2010 at 1:43 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote: On Jun 24, 2010, at 4:59 PM, Guido van Rossum wrote: Regarding the proposal of a String ABC, I hope this isn't going to become a backdoor to reintroduce the Python 2 madness of allowing equivalency between text and bytes for *some* strings of bytes and not others. I never actually replied to this... Absolutely right, which is why you might really want another kind of string, rather than a way to treat some bytes values as strings in some places. Both Python 2 and Python 3 are missing one of the three types. Python 1 and 2 didn't have bytes, and this caused problems because str was pressed into use to hold arbitrary byte sequences. (Python 2 str has other problems as well, like losing track of the encoding.) Python 3 doesn't have Python 2's str (encoded string), and bytes are being pressed into use for that. Each of these uses is an ad hoc hijack of an inappropriate type, and additional frameworks not directly supported by the Python language are being jury-rigged to try to support the uses. On the other hand, this is all in the eye of the beholder. Both byte sequences and strings are horrible formless things; they remind me of BLISS. You seldom really have a byte sequence; what you have is an XDR float or an encoded string or an IP header or an email message. Similarly for strings; they are really file names or city names or English sentences or URIs or other things with significant semantic constraints not captured by the typical type system. So, yes, there *is* an inescapable equivalency between text and bytes for *some* sequences of bytes (those that represent encoded strings) and not others (those that contain the XDR float, for instance). Creating a separate encoded string type would be one way to keep that straight. For my part, what I want out of a string ABC is simply the ability to do application-specific optimizations. There are many applications where all input and output is text, but _must_ be UTF-8. Even GTK uses UTF-8 as its native text representation, so output could just be display. Right now, in Python 3, the only way to be correct about this is to copy every byte of input into 4 bytes of output, then copy each code point *back* into a single byte of output. If all your application does is rewrite the occasional XML attribute, for example, this cost can be significant, if not overwhelming. I'd like a version of 'decode' which would give me a type that was, in every respect, unicode, and responded to all protocols exactly as other unicode objects (or str objects, if you prefer py3 nomenclature ;-)) do, but wouldn't actually copy any of that memory unless it really needed to (for example, to pass to a C API that expected native wide characters), and that would hold on to the original bytes so that it could produce them on demand if encoded to the same encoding again. So, as others in this thread have mentioned, the 'ABC' really implies some stuff about C APIs as well. Seems like it. I'm not sure about the exact performance impact of such a class, which is why I'd like the ability to implement it *outside* of the stdlib and see how it works on a project, and return with a proposal along with some data. Yes, exactly. There are also different ways to implement this, and other optimizations (like ropes) which might be better. You can almost do this today, but the lack of things like the hypothetical __rcontains__ does make it impossible to be totally transparent about it. But you'd still have to validate it, right? You wouldn't want to go on using what you thought was wrapped UTF-8 if it wasn't actually valid UTF-8 (or you'd be worse off than in Python 2). Yes, but there are different ways to validate it that have different performance impacts. Simply trusting the source of the string, for example, would be appropriate in some cases. So you're really just worried about space consumption. I'd like to see a lot of hard memory profiling data before I got overly worried about that. While I've seen some big Web pages, I think the email folks, who often have to process messages with attachments measuring in the tens of megabytes, have the stronger problems here, and I think speed may be more important than memory. I've built both a Web server and an IMAP server in Python, and the IMAP server is where the issues of storage management really prevail. If you have to convert a 20 MB encoded string into a Unicode string just to look at the headers as strings, you have issues. (The Python email package doesn't do that, by the way.) 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
[Python-Dev] thoughts on the bytes/string discussion
Here are a couple of ideas I'm taking away from the bytes/string discussion. First, it would probably be a good idea to have a String ABC. Secondly, maybe the string situation in 2.x wasn't as broken as we thought it was. In particular, those who deal with lots of encoded strings seemed to find it handy, and miss it in 3.x. Perhaps strings are more like numbers than we think. We have separate types for int, float, Decimal, etc. But they're all numbers, and they all cross-operate. In 2.x, it seems there were two missing features: no encoding attribute on str, which should have been there and should have been required, and the default encoding being ASCII (I can't tell you how many times I've had to fix that issue when a non-ASCII encoded str was passed to some output function). So maybe having a second string type in 3.x that consists of an encoded sequence of bytes plus the encoding, call it estr, wouldn't have been a bad idea. It would probably have made sense to have estr cooperate with the str type, in the same way that two different kinds of numbers cooperate, promoting the result of an operation only when necessary. This would automatically achieve the kind of polymorphic functionality that Guido is suggesting, but without losing the ability to do x = e(ASCII)bar a = ''.join(foo, x) (or whatever the syntax for such an encoded string literal would be -- I'm not claiming this is a good one) which presume would bind a to a Unicode string foobar -- have to work out what gets promoted to what. The language moratorium kind of makes this all theoretical, but building a String ABC still would be a good start, and presumably isn't forbidden by the moratorium. 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] bytes / unicode
Tres Seaver tsea...@palladion.com wrote: Stephen J. Turnbull wrote: We do need str-based implementations of modules like urllib. Why would that be? URLs aren't text, and never will be. The fact that to the eye they may seem to be text-ish doesn't make them text. This URLs are exactly text (strings, representable as Unicode strings in Py3K), and were designed as such from the start. The fact that some of the things tunneled or carried in URLs are string representations of non-string data shouldn't obscure that point. They're not text-ish, they're text. They're not opaque, either; they break down in well-specified ways, mainly into strings. The trouble comes in when we try to go beyond the spec, or handle things that don't conform to the spec. Sure, a path component of a URI might actually be a %-escaped sequence of arbitrary bytes, even bytes that don't represent a string in any known encoding, but that's only *after* reversing the %-escapes, which should happen in a scheme-specific piece of code, not in generic URL parsing or manipulation. 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] bytes / unicode
Guido van Rossum gu...@python.org wrote: So I propose that we drop the discussion are URLs text or bytes and try to find something more pragmatic to discuss. For example: how we can make the suite of functions used for URL processing more polymorphic, so that each developer can choose for herself how URLs need to be treated in her application. While I agree with find something more pragmatic to discuss, it also seems to me that introducing polymorphic URL processing might make things more confusing and error-prone. The bigger problem seems to be that we're revisiting the design discussion about urllib.parse from the summer of 2008. See http://bugs.python.org/issue3300 if you want to recall how we hashed this out 2 years ago. I didn't particularly like that design, but I had to go off on vacation :-), and things got settled while I was away. I haven't heard much from Matt Giuca since he stopped by and lobbed that patch into the standard library. But since Guido is the one who settled it, why are we talking about it again? 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] os.getgroups() on MacOS X Was: red buildbots on 2.7
See also http://gimper.net/viewtopic.php?f=18t=3185. 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] red buildbots on 2.7
Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Mon, Jun 21, 2010 at 9:26 PM, Bill Janssen jans...@parc.com wrote: .. Though, isn't that behavior of urllib.proxy_bypass another bug? I don't know. Ask Ronald. Hmmm. I brought up the System Preferences panel on my Mac, and sure enough, there's a checkbox, Exclude simple hostnames. So I guess it's not a bug, though none of my Macs are configured that way. 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] Use of cgi.escape can lead to XSS vulnerabilities
Craig Younkins cyounk...@gmail.com wrote: cgi.escape never escapes single quote characters, which can easily lead to a Cross-Site Scripting (XSS) vulnerability. This seems to be known by many, but a quick search reveals many are using cgi.escape for HTML attribute escaping. Did you file a bug report? 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] red buildbots on 2.7
Bill Janssen jans...@parc.com wrote: Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed? Thanks to some action by Ronald, my two PPC OS X buildbots are now showing green for the trunk. 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
[Python-Dev] red buildbots on 2.7
Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed? On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid. On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet. We don't have a buildbot running Snow Leopard, apparently. 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] red buildbots on 2.7
Benjamin Peterson benja...@python.org wrote: 2010/6/21 Bill Janssen jans...@parc.com: Considering that we've just released 2.7rc2, there are an awful lot of red buildbots for 2.7. In fact, I don't remember having seen a green buildbot for OS X and 2.7. Shouldn't these be fixed? It seems most of them are off line and there last run was just a failure. No, the three OS X buildbots are all online and reporting failures. As far as I can remember, they haven't been green for weeks. They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them. On OS X Leopard, I'm seeing failures in test_py3kwarn, test_urllib2_localnet, test_uuid. On OS X Tiger, I'm seeing failures in test_pep277, test_py3kwarn, test_ttk_guionly, and test_urllib2_localnet. Um -- saying what, the buildbots are red? Shouldn't having green buildbots be a part of the release process? In fact, it is -- but none of the OS X buildbots are part of the stable set. Why is that? 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] red buildbots on 2.7
Antoine Pitrou solip...@pitrou.net wrote: Benjamin is not qualified to fix OS X bugs AFAIK (if you are, Benjamin, then sorry for misrepresenting you :-)). Actually, neither are most of us. Right. I was thinking that the release manager should however be responsible for not releasing while there are red buildbots. But it's not his fault, either; there are no OS X buildbots on the stable list, and that's the list PEP 101 says to look at. The real problem here is that a major platform doesn't have a stable buildbot, I think. I've logged an issue to that effect. Apparently some of these buildbots belong to you. Why don't you step up and investigate? The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think. I did look at the py3kwarn failure, and couldn't figure out the various twisty passages of deprecation warning as further snarled by the test package. I think that one needs someone who's intimately familiar with the testing framework. 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] red buildbots on 2.7
Benjamin Peterson benja...@python.org wrote: 2010/6/21 Bill Janssen jans...@parc.com: They are at the end of the buildbot list, so off-screen if you are using a normal browser. You have to scroll to see them. But not on the stable view and that's the only one I look at. Right, and properly so. 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] red buildbots on 2.7
Antoine Pitrou solip...@pitrou.net wrote: Le lundi 21 juin 2010 à 12:57 -0700, Bill Janssen a écrit : Apparently some of these buildbots belong to you. Why don't you step up and investigate? The fact that I'm running some buildbots doesn't mean I have to fix the problems that they reveal, I think. You certainly don't have to. But please don't ask others to do it for you, *especially* if the failure can't be reproduced under anything else than OS X, and if no useful diagnosis is available. I'm more concerned about doing it for *us*, rather than for *me*. Yes, an OS X machine would be required to poke at it, but I doubt I'm the only one here with an OS X machine :-). If I am, that's a problem, and we as a community should do something about that. I downloaded 2.7rc2 and built it on my Intel OS X 10.5.8 machine. It still fails the test_uuid test: % make test [...] test_uuid test test_uuid failed -- Traceback (most recent call last): File /private/tmp/Python-2.7rc2/Lib/test/test_uuid.py, line 472, in testIssue8621 self.assertNotEqual(parent_value, child_value) AssertionError: '8395a08e40454895be537a180539b7fb' == '8395a08e40454895be537a180539b7fb' [...] However, when I run it directly: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_uuid == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58012 test_uuid testIssue8621 (test.test_uuid.TestUUID) ... ok test_UUID (test.test_uuid.TestUUID) ... ok test_exceptions (test.test_uuid.TestUUID) ... ok test_getnode (test.test_uuid.TestUUID) ... ok test_ifconfig_getnode (test.test_uuid.TestUUID) ... ok test_ipconfig_getnode (test.test_uuid.TestUUID) ... ok test_netbios_getnode (test.test_uuid.TestUUID) ... ok test_random_getnode (test.test_uuid.TestUUID) ... ok test_unixdll_getnode (test.test_uuid.TestUUID) ... ok test_uuid1 (test.test_uuid.TestUUID) ... ok test_uuid3 (test.test_uuid.TestUUID) ... ok test_uuid4 (test.test_uuid.TestUUID) ... ok test_uuid5 (test.test_uuid.TestUUID) ... ok test_windll_getnode (test.test_uuid.TestUUID) ... ok -- Ran 14 tests in 0.087s OK 1 test OK. % So I don't know what to think. The same thing happens with the py3kwarn test: % ./python.exe -Wd -3 -E -tt ./Lib/test/regrtest.py -v test_py3kwarn == CPython 2.7rc2 (r27rc2:82137, Jun 21 2010, 12:50:22) [GCC 4.0.1 (Apple Inc. build 5493)] == Darwin-9.8.0-i386-32bit little-endian == /private/tmp/Python-2.7rc2/build/test_python_58057 test_py3kwarn test_backquote (test.test_py3kwarn.TestPy3KWarnings) ... ok test_buffer (test.test_py3kwarn.TestPy3KWarnings) ... ok test_builtin_function_or_method_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_cell_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_code_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_dict_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_file_xreadlines (test.test_py3kwarn.TestPy3KWarnings) ... ok test_forbidden_names (test.test_py3kwarn.TestPy3KWarnings) ... ok test_frame_attributes (test.test_py3kwarn.TestPy3KWarnings) ... ok test_hash_inheritance (test.test_py3kwarn.TestPy3KWarnings) ... ok test_methods_members (test.test_py3kwarn.TestPy3KWarnings) ... ok test_object_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_operator (test.test_py3kwarn.TestPy3KWarnings) ... ok test_paren_arg_names (test.test_py3kwarn.TestPy3KWarnings) ... ok test_slice_methods (test.test_py3kwarn.TestPy3KWarnings) ... ok test_softspace (test.test_py3kwarn.TestPy3KWarnings) ... ok test_sort_cmp_arg (test.test_py3kwarn.TestPy3KWarnings) ... ok test_sys_exc_clear (test.test_py3kwarn.TestPy3KWarnings) ... ok test_tuple_parameter_unpacking (test.test_py3kwarn.TestPy3KWarnings) ... ok test_type_inequality_comparisons (test.test_py3kwarn.TestPy3KWarnings) ... ok test_mutablestring_removal (test.test_py3kwarn.TestStdlibRemovals) ... ok test_optional_module_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok test_os_path_walk (test.test_py3kwarn.TestStdlibRemovals) ... ok test_platform_independent_removals (test.test_py3kwarn.TestStdlibRemovals) ... ok test_platform_specific_removals (test.test_py3kwarn.TestStdlibRemovals) ... /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:303: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setlocation(object_alias, (x, y)): /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:445: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setwindowsize(folder_alias, (w, h)): /private/tmp/Python-2.7rc2/Lib/plat-mac/findertools.py:496: SyntaxWarning: tuple parameter unpacking has been removed in 3.x def _setwindowposition(folder_alias, (x, y)): ok test_reduce_move (test.test_py3kwarn.TestStdlibRemovals) ... ok
Re: [Python-Dev] red buildbots on 2.7
Antoine Pitrou solip...@pitrou.net wrote: OS X is only a supported and important platform if we have dedicated core developers diagnosing or even fixing issues for it (like we obviously have for Windows and Linux). Otherwise, I don't think we have any moral obligation to support it. Fair enough. That being said, there are two classes of OS X issues. The first is the kind of thing that Ronald Oussoren and Ned Deily keep fixing for us, which require a knowledge of OS X frameworks and SDKs and various other deeply-Apple oddnesses. But the second class is a set of UNIX issues, where OS X is just a variant of UNIX with minor differences from other UNIX platforms. It looks to me as if we don't really need Apple geeks for the second class of issues, we just need developers who have a Mac to test on. It looks to me, for instance, as if the failures in test_py3kwarn and test_uuid on Leopard are bugs in the Python testing framework that happen to be exercised on OS X, rather than bugs caused in some way by the platform. There, the requisite knowledge is, how does regrtest.py really work? 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] red buildbots on 2.7
Alexander Belopolsky alexander.belopol...@gmail.com wrote: Oh, I thought that was about http://bugs.python.org/issue8455 . On Mon, Jun 21, 2010 at 9:05 PM, Alexander Belopolsky alexander.belopol...@gmail.com wrote: On Mon, Jun 21, 2010 at 6:39 PM, Paul Moore p.f.mo...@gmail.com wrote: .. Yes, looks like it's a bug in the test. http://bugs.python.org/issue9055 raised. I concur. I've updated the issue with a proposed fix. (The problem is that proxy host names should have a '.' in them on OSX.) I am trying to decide whether the fix should be applied for all platforms or conditionally for darwin. Can someone test the fix on Windows? Ah, thanks for tracking that one down. I'll bet it's the same problem I'm seeing with proxy authentication with bad credentials unexpectedly succeeding. Though, isn't that behavior of urllib.proxy_bypass another bug? 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] email package status in 3.X
Giampaolo Rodolà g.rod...@gmail.com wrote: 2010/6/17 Bill Janssen jans...@parc.com: There's a related meta-issue having to do with antique protocols. Can I know what meta-issue are you talking about exactly? Giampaolo, I believe that you and I have already discussed this on one of the FTP issues. 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] email package status in 3.X
Nick Coghlan ncogh...@gmail.com wrote: My personal perspective is that a lot of that code was likely already broken in hard to detect ways when dealing with mixed encodings - releasing 3.x just made the associated errors significantly easier to detect. I have to agree with this, and not just about encodings. I think much of the stdlib code dealing with all aspects of HTTP (urllib and the http package which now includes cgi) is kind of shaky. And it affects (infects) other parts of the stdlib, too; sockets are hacked to support the read-after-close paradigm that httplib uses, for instance. Which means that SSL and other socket-using code also has to support it, etc. Some of this was cleaned up in the move to 3.x, but more work needs to be done. Cudos to the folks working on httplib2 (http://code.google.com/p/httplib2/) and WSGI. There's a related meta-issue having to do with antique protocols. FTP, for instance, was designed when the Internet had only 19 nodes connected together with custom-built refrigerator-sized routers. A very early experiment in application protocols. It does a few odd things that we've since learned to be inefficient/unwise/unnecessary. Does it make sense that Python support every part of it? On the other hand, it was fairly static when the Python support was added (unlike HTTP, which was under very active development!) so that module is pretty robust. 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] Reintroduce or drop completly hex, bz2, rot13, ... codecs
Antoine Pitrou solip...@pitrou.net wrote: Le mercredi 09 juin 2010 à 12:38 +0100, Michael Foord a écrit : On 09/06/2010 12:35, Antoine Pitrou wrote: On Wed, 09 Jun 2010 10:41:29 +0200 M.-A. Lemburgm...@egenix.com wrote: The above example will read: b'abc'.transform(hex) b'616263' b'616263'.untranform(hex) b'abc' This doesn't look right to me. Hex-encoded data is really text (it's a textual representation of binary, and isn't often used as an opaque binary transport encoding). Of course, this is not necessarily so for all codecs. For base64-encoded data, for example, it is debatable whether you want it as ASCII bytes or unicode text. But in both cases you probably want bytes - bytes and str - str. If you want text out then put text in, if you want bytes out then put bytes in. No, I don't think so. If I'm using hex encoding, it's because I want to see a text representation of some arbitrary bytestring (in order to display it inside another piece of text, for example). In other words, the purpose of hex is precisely to give a textual display of non-textual data. Yes. And base64, and quoted-printable, etc. 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] Future of 2.x.
Barry Warsaw ba...@python.org wrote: On Jun 09, 2010, at 04:42 PM, M.-A. Lemburg wrote: Many of them are not keen on having to maintain Python2 for much longer, but some of them may have assets codified in Python2 or interests based Python2 that they'll want to keep for more than just another 5 years. E.g. we still have customers that are on Python 2.3 and have just recently considered moving to Python 2.5. Depending on where you look, motivations are rather diverse. It's certainly not fair to require all core developers to continue working on Python2, but it would also be unfair to cancel out that possibility for a subset of interested devs. Even more so, since it doesn't really create any extra work for those that have no interest. Note that Python 2.7 will be *maintained* for a very long time, which should satisfy those folks who still require Python 2. Anybody on older (and currently unmaintained) versions of Python 2 will not care about new features so a Python 2.8 wouldn't help them anyway. There are two kinds of new features, though. Those added to improve (or at any rate modify :-) the product, and those added to keep the product relevant to a changing external world (new operating systems, new communication protocols, etc.) I think it would take a pretty strong crystal ball to be able to rule out the latter kind of feature add from the 2.x line. 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] Summing up
Nick Coghlan ncogh...@gmail.com wrote: B. some more thought should be given to incorporating the new GIL into 2.7. However, this requires two things: - an update to the patch in 7753 to either retain the old GIL for platforms not supported by the new GIL or else to make the new GIL a configure option - Benjamin accepting that patch (as it would likely mean adding another beta release to the cycle) I think I agree with that, at least for 2.7.0. My fallback plan is to write an extension that does the thread affinity hack, monkeypatching threading.py, only for OS X. People like me who are really annoyed with the continued presence of the multicore bug can just add that to site.py or sitecustomize.py (does that still work?). I'd like to find out first whether you can actually change the thread affinity on OS X after the thread has been started. In the absence of an updated version of the 7753 patch, backporting the new GIL to 2.7 isn't really a serious option. Right. At least, not for this revision level. 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
[Python-Dev] pybuildbot.identify?
The PPC buildbots are running pretty well, now that I've opened a few more ports, but I'd like to find this script pybuildbot.identify that they keep complaining about, and install it. I've poked around the Python sources, but haven't found it. Anyone know where to get it from? Thanks. 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] pybuildbot.identify?
Matthias Klose d...@ubuntu.com wrote: On 19.05.2010 18:09, Bill Janssen wrote: The PPC buildbots are running pretty well, now that I've opened a few more ports, but I'd like to find this script pybuildbot.identify that they keep complaining about, and install it. I've poked around the Python sources, but haven't found it. Anyone know where to get it from? it's just a custom script, currently very linux specific. attached here. maybe it's worth to check it in and extend it for other configurations. Matthias Well, please check it in somewhere, at least. Thanks. 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] pybuildbot.identify?
Martin v. Löwis mar...@v.loewis.de wrote: Bill Janssen wrote: Matthias Klose d...@ubuntu.com wrote: On 19.05.2010 18:09, Bill Janssen wrote: The PPC buildbots are running pretty well, now that I've opened a few more ports, but I'd like to find this script pybuildbot.identify that they keep complaining about, and install it. I've poked around the Python sources, but haven't found it. Anyone know where to get it from? it's just a custom script, currently very linux specific. attached here. maybe it's worth to check it in and extend it for other configurations. Matthias Well, please check it in somewhere, at least. Thanks. Can you please investigate why it was causing an error message in the first place? The which test should have determined that the script doesn't exist, and then it shouldn't have been invoked. So I'm puzzled why there is an error message at all. I agree. Must be something in the buildbot code. I slightly object to checking it in. It's *not* a mandatory part of a buildbot slave setup, and if you don't know what it is, you don't need to know. Well, if it failed silently, I would agree. As it is, I created a Darwin version and sent it off to Matthias. 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] Fixing the GIL (with a BFS scheduler)
Martin v. Löwis mar...@v.loewis.de wrote: Peter Portante wrote: Does anybody think that by having problems with the new GIL that it might further weaken the adoption rate for 3k? -peter No, to the contrary. By having the new GIL being superior to the old implementation, the adoption rate for 3k will increase. Well, if that's a strategy, there's still time to make 2+2 equal 5 in the old implementation. 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] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou solip...@pitrou.net wrote: On Sun, 16 May 2010 15:13:44 PDT Bill Janssen jans...@parc.com wrote: So the patch to the threading code would presumably, for those OSs where the capability exists, try to put all created threads in the same affinity set. This is not really a good idea. Yes, fixing the GIL for multicore in 2.7 would be a better idea, IMO. But that might be too large a change. There's some code which releases the GIL, precisely so that you can run several threads (computations) at once. If they can get hold of the GIL in the first place! Yes, you'd want to be able to unbind threads if you knew what you were doing, so that they could run on other cores, and you'd want a switch to disable the affinity mechanism entirely. But I'd be happy to have things in the naive case run as well as they do on single-core machines, and let experts do optimizations. If you aren't too concerned with interactivity, you can increase sys.setcheckinterval() to alleviate the problem on 2.x. Unfortunately, many use cases might well be concerned with interactivity. Things like event-processing loops. 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] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou solip...@pitrou.net wrote: Well, 2.7rc1 is scheduled in less than three weeks now. IMO any patch changing fundamental threading properties is a no-no (even the processor affinity proposal). Unfortunately, our fundamental threading properties are broken for multicore machines. And multicore seems to be the wave of the future. Not fixing this is a big problem. It relegates the only Python which will be usable by many many people for many years, 2.x, to a toy language status on modern machines. It will have threads, but the use of them, either directly or indirectly by modules you may import, may cause unpredictable performance problems. I'd hate to let a fundamental flaw like this go through simply because someone somewhere somewhen set a completely synthetic deadline. Someone had tried to backport the new GIL to 2.7 (there's a tracker issue for it, I'm too lazy to search right now), but it was concluded that compatibility requirements for Python 2.x (compatibility with various legacy threading libraries) made things too complicated and tedious. http://bugs.python.org/issue7753, from January. I've read through that issue (several times), and I have to say that I wind up gnashing my teeth each time. Here's a fix that's rejected because it only supports NT and POSIX threads. What percentage of Python use cases do those two threading systems cover? Do we know? If by compatibility requirements you mean that new releases of Python should run on antique systems just as the older releases did, that's satisfied by the issue's current state, you're right. On the other hand, to me that seems an odd goal to prioritize. After all, the older releases are still there, for that antique system. Nor do I see an answer to Russ' final question: ``What if, as you proposed earlier, the patch were to leave the old behavior if the threading model on the given platform were not supported?'' There's some code which releanses the GIL, precisely so that you can run several threads (computations) at once. If they can get hold of the GIL in the first place! Yes, you'd want to be able to unbind threads if you knew what you were doing, so that they could run on other cores, and you'd want a switch to disable the affinity mechanism entirely. But I'd be happy to have things in the naive case run as well as they do on single-core machines, and let experts do optimizations. Letting experts do optimizations is a regression, though, because right now you don't have to be an expert to take advantage of such optimizations (just run a separate thread doing e.g. some zlib compression). If threading performance wasn't broken on multicore, I'd agree with you. But right now, *everyone* has to be an expert just to use Python 2.x effectively on modern multicore hardware -- you have to find the right patch in issue 7753, apply it to the sources, build a custom python, and use it. Whether or not use explicitly know you are using threads (because some other package may be using them under the covers). 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] Fixing the GIL (with a BFS scheduler)
Bill Janssen jans...@parc.com wrote: use it. Whether or not use explicitly know you are using threads (because some other package may be using them under the covers). Of course, I meant to say, Whether or not *youse* explicitly know you are using threads (because some other package may be using them under the covers). :-). 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] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou solip...@pitrou.net wrote: Well, if instead of gnashing your teeth, you had contributed to the issue, perhaps a patch would have been committed by now (or perhaps not, but who knows?). If you stay silent, you cannot assume that someone else will stand up for *your* opinion (and the fact that nobody did could indicate that not many people care about the issue, actually). Unfortunately, I somehow did not even *know* about the issue until February, after the issue had been closed. What I did know was that some of our big complicated Python multi-threaded daemons had shown puzzling resource hogging when moved from small Macs to large 8-core machines with hardware RAID and lots of memory. But, simpleton that I am, I'd presumed that threading in Python wasn't broken, and was looking elsewhere for the cause. Python works reasonably well on multicore hardware, especially if you don't run spinning loops and if you're not on Mac OS X. I'm not sure what you mean by spinning loops. But I *am* on Mac OS X, along with an increasing percentage of the world. And I'm dismayed that there's no momentum to fix this problem. Not a good sign. 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] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou solip...@pitrou.net wrote: On Mon, 17 May 2010 11:15:49 PDT Bill Janssen jans...@parc.com wrote: What I did know was that some of our big complicated Python multi-threaded daemons had shown puzzling resource hogging when moved from small Macs to large 8-core machines with hardware RAID and lots of memory. Could you give detailed information about this? Probably not detailed enough. IP issues. It's a version of UpLib. Since you're talking about a big complicated Python multi-threaded daemon, I presume you can't port it to Python 3 very quickly, but it would be nice to know if the problem disappears with 3.2. Yes, it would. As soon as I have working 3.x versions of BeautifulSoup, PIL, ReportLab, JCC, pylucene, pyglet, nltk, email, epydoc, feedparser, dictclient, docutils, hachoir, mutagen, medusa, python-dateutil, and vobject, I'll let you know. :-) There /has/ been momentum in fixing it. In py3k. Yes, I specifically meant in the 2.x branch. I'm guessing I'll have to stay on 2.x for at least 5 more years, due to the other package dependencies. 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] Fixing the GIL (with a BFS scheduler)
Martin v. Löwis mar...@v.loewis.de wrote: I'd hate to let a fundamental flaw like this go through simply because someone somewhere somewhen set a completely synthetic deadline. No, it's not like that. We set the deadline so that we are able to cancel discussions like this one. It would be possible to change the schedule, if we would agree that it was for a good cause - which we don't. I do appreciate that, and also what you and Antoine are saying. If threading performance wasn't broken on multicore, I'd agree with you. But right now, *everyone* has to be an expert just to use Python 2.x effectively on modern multicore hardware Not at all. Just use the multiprocessing module instead, and be done. It's really easy to use if you already managed to understand threads. But that's just the problem. Most folks don't use threads, they use a higher-level abstraction like the nltk library. Does it use threads? Has its owner ported it to py3k? Has its owner ported it to the multiprocessing module? I have to be an expert to know. I'll stop talking about this now... At least, here. Apparently we only need to fix this for OS X. 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] Fixing the GIL (with a BFS scheduler)
Terry Reedy tjre...@udel.edu wrote: On 5/17/2010 2:59 PM, Bill Janssen wrote: Yes, it would. As soon as I have working 3.x versions of BeautifulSoup, PIL, ReportLab, JCC, pylucene, pyglet, nltk, email, epydoc, feedparser, dictclient, docutils, hachoir, mutagen, medusa, python-dateutil, and vobject, I'll let you know. :-) There /has/ been momentum in fixing it. In py3k. Yes, I specifically meant in the 2.x branch. I'm guessing I'll have to stay on 2.x for at least 5 more years, due to the other package dependencies. I suspect it will be sooner than that, especially if users like you ask/beg/plead with the maintainers of libraries like those you listed to make them work with 3.2. Oh, that's the way I like to spend my day (and, as you can tell from this conversation, I'm really good at it :-). Though I will of course do that. But some of these, like JCC+pylucene, nltk, and vobject, were developed with idiosyncratic funding resources which no longer exist. Others, like pyglet, were developed for a completely different purpose, and I doubt the developers care what I want. So, realistically, I doubt it will be less than five years. 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] Fixing the GIL (with a BFS scheduler)
Antoine Pitrou solip...@pitrou.net wrote: On Sun, 16 May 2010 15:13:44 PDT Bill Janssen jans...@parc.com wrote: So the patch to the threading code would presumably, for those OSs where the capability exists, try to put all created threads in the same affinity set. This is not really a good idea. There's some code which releases the GIL, precisely so that you can run several threads (computations) at once. Could the macro that releases the GIL also release the thread affinity? And the macro that acquires it again set the affinity tag back again? 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 svn exceptions again...
Martin v. Löwis mar...@v.loewis.de wrote: Bill Janssen wrote: parc-leopard-1 (and most of the other builders) are failing the svn checkout with the following error: svn: PROPFIND of '/projects/python/trunk': Could not resolve hostname `svn.python.org': Temporary failure in name resolution (http://svn.python.org) When I log into that machine as buildbot and do the svn checkout manually using the following command /usr/bin/svn checkout --non-interactive --no-auth-cache --revision HEAD http://svn.python.org/projects/python/trunk build it works fine. That's a common OSX problem/bug. Processes occasionally lose the ability to resolve host names. A workaround is to just put them in the /etc/hosts file. 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 svn exceptions again...
Martin v. Löwis mar...@v.loewis.de wrote: That's a common OSX problem/bug. Processes occasionally lose the ability to resolve host names. Various theories float around what's causing this (most commonly, people expect that a controlling terminal must be present); my theory is this: There is a Mach port in the system that lets a process talk to the local resolver (lookupd, or whatever Apple's naming infrastructure is called today). For some reason, this port gets closed in a background process, perhaps because the parent process closed it when you logged out. Or the Kerberos credentials expired, or some such... In short, if some OS X expert could shed some light on this, it would be appreciated. It would then be good to add this to the wiki. See also This is as close to an explanation as I've been able to get from Apple: http://lists.apple.com/archives/Darwin-kernel/2009/Apr/msg00016.html http://buildbot.net/trac/wiki/UsingLaunchd http://developer.apple.com/mac/library/technotes/tn2005/tn2083.html 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] OS X buildbots and launchd
I can find no evidence that the buildbot installation process given on the wiki will cause the buildbot slave to be restarted after a reboot of the machine. To accomplish this, you should also undertake the work described in http://buildbot.net/trac/wiki/UsingLaunchd On my Leopard slave, I created the file /Library/LaunchAgents/org.python.buildbot.slave.plist, and put in it this XML: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist PUBLIC -//Apple//DTD PLIST 1.0//EN http://www.apple.com/DTDs/PropertyList-1.0.dtd; plist version=1.0 dict keyStandardOutPath/key stringtwistd.log/string keyStandardErrorPath/key stringtwistd-err.log/string keyEnvironmentVariables/key dict keyPATH/key string/usr/local/bin:/sbin:/usr/sbin:/bin:/usr/bin/string /dict keyGroupName/key stringdaemon/string keyKeepAlive/key dict keySuccessfulExit/key false/ /dict keyLabel/key stringorg.python.buildbot.slave/string keyProgramArguments/key array string/usr/bin/twistd/string string-no/string string-y/string string/Users/buildbot/buildarea/buildbot.tac/string /array keyRunAtLoad/key true/ keyUserName/key stringbuildbot/string keyWorkingDirectory/key string/Users/buildbot/buildarea/string /dict /plist Note that I am using the system Python 2.5, and that I have configured the buildbot slave machine to login the buildbot account automatically upon boot, which login will cause this daemon to start, and will provide access to the GUI context for testing tk. I've configured it with a locking screensaver that starts immediately; let's see if that works OK. I've also put dinsdale.python.org and svn.python.org in /etc/hosts. 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
