Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Guido van Rossum [EMAIL PROTECTED] wrote: OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it to death in abstracto. However, the ORIGINAL proposal in this thread (to split off argv[0] and/or make that and the arguments read-only) is entirely different. That is purely a matter of convenience, cleanliness of specification or whatever you call it. I can't imagine any good reason to separate argv[0] from argv[1:] by a sandbox (either way). Regards, Nick Maclaren, University of Cambridge Computing Service, New Museums Site, Pembroke Street, Cambridge CB2 3QH, England. Email: [EMAIL PROTECTED] Tel.: +44 1223 334761Fax: +44 1223 334679 ___ 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] Community buildbots (was Re: User's complaints)
On 7/14/06, Anthony Baxter [EMAIL PROTECTED] wrote: The community buildbot idea is a good one, although it should just be possible to write something for buildbot that checks out and builds the latest Python SVN, then installs it to a temporary location, then adds that location to the front of the path. Then each project could just add a Python SVN buildbot to their exists bbot install. This is what Xenofarm for Pike has done for a long time now. See for example: http://pike.ida.liu.se/development/pikefarm/7.7.xml This is also what Bitten (http://bitten.cmlenz.net/) has implemented for Trac (which is one of the bug/incident trackers for Python's call for trackers). -- Jeroen Ruigrok van der Werven ___ 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] Community buildbots (was Re: User's complaints)
Terry Reedy wrote: That is the goal, but when I watched the buildbot results last spring, the degree of stability (greenness) appeared to vary. Is it possible to tag particular versions as a 'green' version, or the 'most recent green version' worth playing with? Don't get confused by these colors. The tree compiled nearly all of the time, even if some tests were failing for an extended period of time on some platforms. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
Jeroen Ruigrok van der Werven wrote: This is what Xenofarm for Pike has done for a long time now. See for example: http://pike.ida.liu.se/development/pikefarm/7.7.xml This is also what Bitten (http://bitten.cmlenz.net/) has implemented for Trac (which is one of the bug/incident trackers for Python's call for trackers). Are you aware of http://www.python.org/dev/buildbot/ ? We are not just talking about buildbots here (which the links you refer to seem to be); we are talking about buildbots that don't test Python, but test Python applications. We do know how to run a buildbot. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
[EMAIL PROTECTED] wrote: python -U is a failure for obvious reasons and a __future__ import is clearly better. I disagree. I am surprised that you do, since I thought that Chris's conclusion was pretty obvious. Python -U doesn't work, even on the standard library. Sure, it doesn't work. That doesn't mean it's a failure. It just hasn't been completed yet. A __future__ import would allow these behaviors to be upgraded module-by-module. Right now, all -U provides is an option that can't be used on any realistically sized program, so I don't see what the utility is. People can use it to improve the Unicode support in the Python standard library. When they find that something doesn't work, they can study the problem, and ponder possible solutions. Then, they can contribute patches. -U has worked fine for me in the past, I contributed various patches to make it work better. It hasn't failed for me at all. 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] list.__init__() vs. dict.__init__() behaviour
Hi,
When testing some 'real world' code using pypy, an inconsistancy with
the way __init__ works between lists and dicts.
The assumption was made when implementing __init__ for pypy that
list.__init__ and dict.__init__ would both wipe the contents of the
objects, but it seems that in cpython, this isn't precisely the case.
l = [2,3]
list.__init__(l)
l
[]
d = {2: 3}
dict.__init__(d)
d
{2: 3}
dict.__init__(mydict) does not wipe the keys. list.__init__(mylist)
wipes the lists contents.
https://codespeak.net/issue/pypy-dev/issue240
Is there a good reason for this behaviour? It has broken my code (a
subclass of dict that populates a key before calling the superclasses
constructer, in the twisted codebase).
--
Stephen Thorne
Give me enough bandwidth and a place to sit and I will move the world.
--Jonathan Lange
___
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] Community buildbots (was Re: User's complaints)
On 7/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Are you aware of http://www.python.org/dev/buildbot/ ? Yes. And it does not seem to be open for all, but then again, any documentation with regard to it seems to be very sparse or hidden so I can very well be wrong here. Ah, hidden away on the wiki: http://wiki.python.org/moin/BuildBot We are not just talking about buildbots here (which the links you refer to seem to be); we are talking about buildbots that don't test Python, but test Python applications. Then I would dare to say you haven't fully investigated the links fully, Bitten, for example, also runs the unit-tests for any target you configure, saves all the outputs and provides quick overviews as well as coverage statistics. So that would fall perfectly into that category. See http://bitten.cmlenz.net/build/0.5.x/762 for an example. We do know how to run a buildbot. How relevant was this comment in the entire? I am merely trying to help out here pointing out other similar projects when the community participating building issue was raised. -- Jeroen Ruigrok van der Werven ___ 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] Community buildbots (was Re: User's complaints)
Jeroen Ruigrok van der Werven wrote: Are you aware of http://www.python.org/dev/buildbot/ ? Yes. And it does not seem to be open for all Ah, ok. It indeed isn't open for anonymous participation; the test results are open for all, though. We are not just talking about buildbots here (which the links you refer to seem to be); we are talking about buildbots that don't test Python, but test Python applications. Then I would dare to say you haven't fully investigated the links fully, Bitten, for example, also runs the unit-tests for any target you configure I don't understand that comment. Bitten seems to be a software package, similar to buildbot. It doesn't do anything useful until I install and configure it, unlike, say, SourceForge, which is not (just) a soft package, but a running installation of it also. Right? The effort is in installing and configuring it, given that many such packages are already written. Distributed testing frameworks typically support running arbitrary target comments, so Bitten is not really special here (buildbot can also run about anything if you configure it to). We do know how to run a buildbot. How relevant was this comment in the entire? I am merely trying to help out here pointing out other similar projects when the community participating building issue was raised. It would have been helpful if you had stated *why* you think these URLs are relevant in the context of the discussion. To me, it seemed you are pointing to the existence of distributed testing frameworks. I was pointing out that we (at least, I) am aware of the existence of such frameworks, and that we were doing it for quite some time now also, just like Pike. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
On 7/14/06, Nick Maclaren [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: OK, then I propose that we wait to see which things you end up having to provide to sandboxed code, rather than trying to analyze it to death in abstracto. However, the ORIGINAL proposal in this thread (to split off argv[0] and/or make that and the arguments read-only) is entirely different. That is purely a matter of convenience, cleanliness of specification or whatever you call it. I can't imagine any good reason to separate argv[0] from argv[1:] by a sandbox (either way). Sure. But that proposal has already been discussed (and found little opposition). The thread then dispersed in a much less focused discussion about the true purpose of the sys module.. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] list.__init__() vs. dict.__init__() behaviour
On 7/15/06, Stephen Thorne [EMAIL PROTECTED] wrote:
When testing some 'real world' code using pypy, an inconsistancy with
the way __init__ works between lists and dicts.
The assumption was made when implementing __init__ for pypy that
list.__init__ and dict.__init__ would both wipe the contents of the
objects, but it seems that in cpython, this isn't precisely the case.
l = [2,3]
list.__init__(l)
l
[]
d = {2: 3}
dict.__init__(d)
d
{2: 3}
dict.__init__(mydict) does not wipe the keys. list.__init__(mylist)
wipes the lists contents.
I think it's an accident of implementation. I never thought about this
from the POV of a subclass. Apparently dict.__init__() shares some
code with dict.update(). Or does it do a merge without overwriting
existing keys?
https://codespeak.net/issue/pypy-dev/issue240
Is there a good reason for this behaviour? It has broken my code (a
subclass of dict that populates a key before calling the superclasses
constructer, in the twisted codebase).
I think your code was skating on awfully thin ice by making any
assumptions whatsoever about the base class constructor.
But I also think that this ought to be specified in the language spec.
I'm not sure that consistency between list and dict is important to
me, but they probably should both answer to some higher principle
which I cannot formulate ATM.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots
On Thu, Jul 13, 2006, Talin wrote: Actually - can we make new-style classes the default, but allow a way to switch to old-style classes if needed? Perhaps a command-line argument to set the default back to old-style? Nope. Python 3.0 will have new-style classes as the default, but there will probably not be any way to use old-style classes. As has been said before, if you want to make new-style classes the default for any module, just put __metaclass__ = type at the top. Please, just drop this subject. Guido has long since Pronounced. -- Aahz ([EMAIL PROTECTED]) * http://www.pythoncraft.com/ Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it. --Brian W. Kernighan ___ 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] Community buildbots
On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy [EMAIL PROTECTED] wrote: Is the following something like what you are suggesting? Something like it, but... A Python Application Testing (PAT) machine is set up with buildbot and any needed custom scripts. Sometime after that and after 2.5 is released, when you have a version of, for instance, Twisted that passes its automated test suite when run on 2.5, you send it (or a URL) and an email address to PAT. Other developers do the same. Periodically (once a week?), when PAT is ^ once per checkin to Python trunk free and a new green development version of either the 2.5.x or 2.6 branches is available, PAT runs the test suites against that version. An email is sent for any that fail, perhaps accompanied by the concatenation of the relevant checkin message. Some possible options are to select just one of the branches for testing, to have more than one stable version being tested, and to receive pass emails. Sending email also isn't really necessary; I would just like a web page I can look at (and draw the attention of the python core developers to). ___ 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] Community buildbots
On Sat, 15 Jul 2006 14:35:08 +1000, Nick Coghlan [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
A __future__ import would allow these behaviors to be upgraded module-by-
module.
No it wouldn't.
Yes it would! :)
__future__ works solely on the semantics of different pieces of syntax,
because any syntax changes are purely local to the current module.
...
Changing all the literals in a module to be unicode instances instead of str
instances is merely scratching the surface of the problem - such a module
would still cause severe problems for any non-Unicode aware applications
that expected it to return strings.
A module with the given __future__ import could be written to expect that
literals are unicode instances instead of str, and encode them appropriately
when passing to modules that expect str. This doesn't solve the problem, but
unlike -U, you can make fixes which will work persistently without having to
treat the type of every string literal as unknown.
The obvious way to write code that works under -U and still works in normal
Python is to .encode('charmap') every value intended to be an octet, and put
'u' in front of every string intended to be unicode. That would seem to
defeat the purpose of changing the default literal type.
___
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] Dynamic module namspaces
In an effort to reduce the memory usage used by GTK+ applications written in python I've recently added a feature that allows attributes to be lazy loaded in a module namespace. The gtk python module contains quite a few attributes (around 850) of which many are classes or interfaces (150+) The changes to PyGTK I had to make can not be considered anything but a hack; I had to put a subclass of a ModuleType in sys.modules and override __getattribute__ to be able to get old code which accessed gtk.__dict__ directly to still work (PyModule_GetDict requires that). However, even if I didn't have to use __getattribute__ overriding sys.modules is rather unpleasent and I'm afraid it'll cause problems in the future. My point is that I consider this to be a valid use case, the amount of saved memory is significan, and I could not find another way of doing it and still keep the gtk interface (import gtk; gtk.Button) to still be backwards compatible. What I want to ask, is it possible to have a sanctioned way to implement a dynamic module/namespace in python? For instance, it could be implemented to allow you to replace the __dict__ attribute in a module with a user provided object which implements the dictionary protocol. Johan ___ 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] Community buildbots
On Sat, 15 Jul 2006 10:43:22 +0200, \Martin v. Löwis\ [EMAIL PROTECTED] wrote: People can use [-U] to improve the Unicode support in the Python standard library. When they find that something doesn't work, they can study the problem, and ponder possible solutions. Then, they can contribute patches. -U has worked fine for me in the past, I contributed various patches to make it work better. It hasn't failed for me at all. I guess it makes more sense as a development tool to work on zero-dependency tools like the standard library. Still, -Q has both a __future__ import and a command-line option, why not -U? ___ 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] Dynamic module namspaces
Johan Dahlin wrote: My point is that I consider this to be a valid use case, the amount of saved memory is significan, and I could not find another way of doing it and still keep the gtk interface (import gtk; gtk.Button) to still be backwards compatible. You may want to have a look at SIP/PyQt. They implement the full Qt interface which is rather large, but import time is blazingly fast and memory occupation grows only of 4-5 Mb at import-time. The trick is that methods are generated dynamically at their first usage somehow (but dir() and introspection still works...). SIP is free and generic btw, you may want to consider it as a tool. -- Giovanni Bajo ___ 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] Community buildbots
On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote: Note that it also helps setting the default encoding to 'unknown'. That way you disable the coercion of strings to Unicode and all the places where this implicit conversion takes place crop up, allowing you to take proper action (i.e. explicit conversion or changing of the string to Unicode as appropriate). I've tried that before to verify no such conversion issues occurred in Twisted, but, as the python stdlib isn't usable like that, it's hard to use it to find bugs in any other libraries. (in particular, the re module is badly broken, some other stuff was too). James ___ 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] urllib.quote and unicode bug resuscitation attempt
Stefan Rank wrote: Well, originally, I would have expected it to return a byte str(ing), I'd assume unicode in, unicode out, and str in, str out, but since it's always going to produce ASCII-range characters, it wouldn't matter. Moot point anyway. BUT I am now converted and think it is best to raise a TypeError for unicode, and leave the encoding decisions to higher level code. So I'll repeat the patch #1, slightly modified:: if isinstance(s, unicode): raise TypeError(quote expects an encoded byte string as argument) Is it safe to assume that code that breaks because of this change was already broken? Yes. The patch seems fine to me, although maybe if not isinstance(s, str) would be better? ___ 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] Community buildbots
James Y Knight wrote: On Jul 15, 2006, at 3:15 PM, M.-A. Lemburg wrote: Note that it also helps setting the default encoding to 'unknown'. That way you disable the coercion of strings to Unicode and all the places where this implicit conversion takes place crop up, allowing you to take proper action (i.e. explicit conversion or changing of the string to Unicode as appropriate). I've tried that before to verify no such conversion issues occurred in Twisted, but, as the python stdlib isn't usable like that, it's hard to use it to find bugs in any other libraries. (in particular, the re module is badly broken, some other stuff was too). True: it breaks a lot of code that was written to work with both strings and Unicode (or does so by accident ;-). The stdlib isn't too well prepared for Unicode yet, so if your code relies a lot on it, then the above may not be the right strategy for you. Perhaps a new ASCII codec that issues warnings for all these cases would help ?! (one that still converts to Unicode assuming ASCII, but issues a warning pointing to the location in the code where the conversion happend) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Jul 15 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] Community buildbots
[EMAIL PROTECTED] wrote:
A module with the given __future__ import could be written to expect that
literals are unicode instances instead of str, and encode them appropriately
when passing to modules that expect str.
Such changes might have to be reverted in Python 3, since the module
might then expect character strings instead of byte strings, and then
might complain when it gets byte strings (which .encode will produce).
So declaring that all string literals are Unicode objects might not
help in the future, contrary to what the future import suggests.
The obvious way to write code that works under -U and still works in normal
Python is to .encode('charmap') every value intended to be an octet, and put
'u' in front of every string intended to be unicode. That would seem to
defeat the purpose of changing the default literal type.
The not so obvious way is to change the modules/methods receiving these
strings to work with either string type if that is reasonable.
Regards,
Martin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Community buildbots (was Re: User's complaints)
On 7/15/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Terry Reedy wrote: That is the goal, but when I watched the buildbot results last spring, the degree of stability (greenness) appeared to vary. Is it possible to tag particular versions as a 'green' version, or the 'most recent green version' worth playing with? Don't get confused by these colors. The tree compiled nearly all of the time, even if some tests were failing for an extended period of time on some platforms. Right. It's very rare that the interpreter or stdlib is broken. There are 19 buildbots currently. 7 are not green. 5 of those are offline, most with known (to me and the person that donated the machines) hardware issues ranging from lack of air conditioning, to a bad router, to no power. 1 is cygwin which is running an old version. I just (an hour or so ago) got an account on a cygwin box to help diagnose the status and figure out if anything within Python or the tests are broken. That leaves 1 unexplained failure on a Windows bot. This started happening recently after being down for a while. I haven't had time to investigate. The reason why it was not very green in spring was because that's when we were getting it set up! The master looks like it was installed at the end of 2005/beginning of 2006. It took several months to get rid of many testing issues. Tests that couldn't be run in a particular order, tests that couldn't be run simultaneously (socket), bad compilation of sqlite/bsddb modules (not in python), misconfigured systems, tests verifying something that was system dependent, signed addresses, etc. Of all the problems there were, I only remember a single problem in Python. (There were probably more, I just remember one.) That was in test code (xxmodule or something like that. There were a bunch of problems with ctypes and/or sqlite when they got integrated having to deal with these new platforms. That may be what you are recalling. Right before alpha 2 was a particularly bad time. What we mean by stable is that at any time/any stage of development, if a change goes in that breaks the tests, it is likely to be fixed or reverted within hours. The amount of time the build or tests are broken on the majority of platforms is quite small. It took a while to get to this point due to a bunch of flaky tests, but those have mostly been fixed. The only known problems are mentioned on the wiki. When the buildbots fail, we get mail to python-checkins. Unfortunately, that's mostly spam at this point. I hope to fix that at some point. I also hope to change the main page to give more info in less space. n ___ 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] Community buildbots (was Re: User's complaints)
[Neal Norwitz] ... That leaves 1 unexplained failure on a Windows bot. It wasn't my Windows bot, but I believe test_profile has failed (rarely) on several of the bots, and in the same (or very similar) way. Note that the failure went away on the Windows bot in question the next time the tests were run on it. That's typical of test_profile failures. Unfortunately, because test_profile works by comparing stdout against a canned expected-output file under Lib/test/output/, when we re-run the test in verbose mode at the end, that comparison isn't done, so there's isn't a simple way to know whether the test passed or failed during its second run. I _bet_ it actually passed, but don't know. This problem is obscured because when you run regrtest.py by hand with -v, you get this message at the end: CAUTION: stdout isn't compared in verbose mode: a test that passes in verbose mode may fail without it. which is intended to alert you to the possible problem. But when we re-run failing tests in verbose mode by magic (via passing -w), that warning isn't produced. BTW, the best solution to this is to convert all the tests away from regrtest's original compare stdout against a canned output/TEST_NAME file scheme. That won't fix test_profile, but would make it less of a puzzle to figure out what's wrong with it. ___ 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] Community buildbots
[EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED] On Sat, 15 Jul 2006 00:13:35 -0400, Terry Reedy [EMAIL PROTECTED] wrote: Other developers do the same. Periodically (once a week?), when PAT is ^ once per checkin to Python trunk If the average rate of checkins is equal to or greater than the maximum rate of test runs then that is physically impossible. (Indeed, queueing theory suggests that keeping the queue size small requires that the checkin be more like half the test rate.) This appears to be currently true for the Python trunk buildbot and I would expect running the test of numerous large applications would take even longer, making the test rate even lower. If you want something like twisted run against multiple Python versions a day, I suspect you will have to do so on a system you control. Terry Jan Reedy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
