Re: [Python-Dev] Community buildbots (was Re: User's complaints)
Neal Norwitz wrote: > This is the part I don't get. For the external developers, if they > care about compatibility, why aren't they testing periodically, > regardless of alpha/beta releases? because they don't want to waste time and effort on testing against releases that are not necessarily a close approximation of the full release? testing takes time, and time can be used for many different things. ___ Python-Dev mailing list [email protected] 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 Friday 14 July 2006 17:00, Fredrik Lundh wrote: > because they don't want to waste time and effort on testing against > releases that are not necessarily a close approximation of the full > release? testing takes time, and time can be used for many > different things. Oddly enough, so does release management. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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 Friday 14 July 2006 16:39, Neal Norwitz wrote: > Remember I also tried to push for more features to go in early? > That would have given more time for external testing. Still > features are coming in. Python developers weren't happy about > having to get things in earlier. I don't see a practical way to > implement what you propose (see Anthony's comments). Following up on this point: Given the number of "just-this-one-more-thing-please" we've _already_ had since the b1 feature freeze, do you really except that 90 days of feature freeze is feasible? And if there's not going to be a feature freeze, there's hardly any point to people doing testing until there _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. Oops. 2.5b9 added a new feature that broke my code, but I didn't test with that. Anthony -- Anthony Baxter <[EMAIL PROTECTED]> It's never too late to have a happy childhood. ___ Python-Dev mailing list [email protected] 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)
Greg Ewing <[EMAIL PROTECTED]> wrote: > > > On systems that are not Unix-derived (which, nowadays, are rare), > > there is commonly no such thing as a program name in the first place. > > It is possible to get into that state on some Unices - i.e. ones which > > have a form of exec that takes a file descriptor, inode number or > > whatever. > > I don't think that applies to the Python args[] though, > since its args[0] isn't the path of the OS-level > executable, it's the path of the main Python script. Oh, yes, it does! The file descriptor or inode number could refer to the script just as well as it could to the interpreter binary. > But you could still end up without one, if the main > script comes from somewhere other than a file. I didn't want to include that, to avoid confusing people who haven't used systems with such features. Several systems have had the ability to exec to a memory segment, for example. But, yes. 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 [email protected] 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)
Nick Maclaren wrote: >> I don't think that applies to the Python args[] though, >> since its args[0] isn't the path of the OS-level >> executable, it's the path of the main Python script. > > Oh, yes, it does! The file descriptor or inode number could refer to > the script just as well as it could to the interpreter binary. (insert sound of head hitting desk here) ___ Python-Dev mailing list [email protected] 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
Greg Ewing <[EMAIL PROTECTED]> wrote: >> "from __future__ import new_classes" exists, but the syntax is >> different: >> >> __metaclass__ = type > > Although it's not a very obvious spelling, > particularly to the casual reader who may not be > familiar with the intricacies of classes and > metaclasses. I don't think it would hurt to have > it available as a __future__ import as well. > > There's also the advantage that all of a > module's future assumptions could then be > documented uniformly in one place, i.e. in > a __future__ import at the top. +1. Giovanni Bajo ___ Python-Dev mailing list [email protected] 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] writes: > I just would have appreciated the opportunity to participate in the > discussion before the betas were out and the featureset frozen. I think something that has happened to some extent with this release is that there was a long-ish period where stuff got discussed and implemented (PEPs 343 and 344, new-style exceptions, the new compiler, the ssize_t branch) and then suddenly we went "crap! we have to release this!" and then the whole alpha/beta/release part has happened much more quickly. Maybe we should have had a more explicit discussion on what was going to be in 2.5 before beta1, but that kind of thing is difficult to make happen (it's entirely possible that it did happen and I just missed it by being snowed under, but I don't think so). Cheers, mwh -- Have you considered downgrading your arrogance to a reasonable level? -- Erik Naggum, comp.lang.lisp, to yet another C++-using troll ___ Python-Dev mailing list [email protected] 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)
Greg Ewing wrote: > Nick Maclaren wrote: >> On systems that are not Unix-derived (which, nowadays, are rare), >> there is commonly no such thing as a program name in the first place. >> It is possible to get into that state on some Unices - i.e. ones which >> have a form of exec that takes a file descriptor, inode number or >> whatever. > > I don't think that applies to the Python args[] though, > since its args[0] isn't the path of the OS-level > executable, it's the path of the main Python script. > > But you could still end up without one, if the main > script comes from somewhere other than a file. sys.argv[0] can end up being None in Python 2.5 - zipimporter objects don't currently expose the info runpy.run_module needs to set __file__ and sys.argv[0] correctly, so they'll both end up being None if you use -m to run a module from a zipfile. PEP 302 went a fairly long way towards decoupling imports from the filesystem lay out, but it isn't all the way there just yet. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] IDLE - firewall warning
I have posted the following message to idle-dev, but no reply yet. Just a suggestion: The firewall warning message in the Pythonshell window was introduced in Python 2.3 (IDLE 1.0 or something similar?) I remember well the problems, to which it was the answer. (If I remember correctly I was involved in the discussion thread which led to the introduction of that message.) Since more than three years I've used IDLE on many different systems and I didn't encounter a single Firewall warning since then. (It seems that firewalls nowadays are not offended by the use of 127.0.0.1) Therefore, and because the message is long and ugly, I'd like to suggest to delete it from the Python Shell window and - if considered necessary - for instance to put it into the IDLE Help - "About IDLE" submenu or in a special IDLE-Firewall warning submenu of IDLE-Help. Please observe that it pops up thousands of times and it's read at most once. Or perhaps a single-line message like === subprocesses use internal loopback interface === would do it, just to signal where you are as does the respective line in -n mode.? Regards, Gregor Lingl ___ Python-Dev mailing list [email protected] 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 <[EMAIL PROTECTED]> wrote: >> a longer beta period gives *external* developers more time to catch >> up, and results in less work for the end users. > > This is the part I don't get. For the external developers, if they > care about compatibility, why aren't they testing periodically, > regardless of alpha/beta releases? Because it is a cost, and I don't want to waste my time if the trunk is unstable or whatnot. There is no official statement of the kind "all the real development is done in branches, the trunk is always very stable, feel free to grab it". Thus, we (external developers) assume that it's better to wait for the first alpha or beta before starting doing any testing. Personally, I won't touch something before the first beta: there are already enough known bugs when the alphas are shipped that I prefer to wait a little bit more. In my case, the beta period is too short. It's already a great luck if, during the beta cycle, I'm not deep into some milestone or release cycle for my own software. It might well happen that I have barely time to notice a Python beta is out, but I can't afford spending any time on it because of time constraint. By the time I'm done with my own deadlines, Python final is already out. But for the sake of the argument and the rest of this mail, let's assume I have tons of spare time to dedicate to Python 2.5 beta testing. My applications have several external dependencies (I wouldn't classify those as "many", but still around 6-7 libraries in average). For each of those libraries, there won't be Py2.5-ready RPM or Windows installer to grab and build. Most of the time, I have to download the source package, and try to build it. This also means hunting down and fixing Py2.5-related bugs in all those libraries *before* I can even boot my own application (which is what I would care about). Then I occasionally hit a core Python bug while doing so, which is good, but I have to sit and wait. Some libraries have very complex build process which are still distutils-based, but might require many other external C/C++ libraries, which need to be fetched and compiled just to setup the build environment. Alternatively, I could cross my fingers and wait for all the maintainers of the external libraries to have spare time, and dedicate to Python 2.5 upgrading. If I'm lucky, by the time RC1 is out, most of them might have binary packages available for download, or at least have their (unstable) CVS/SVN trunk fixed for Python 2.5 (which means that I'll have to fetch that unstable version and basically perform a forced upgrade of the library, which might trigger another class of compatibility/feature/regression bugs in my application, not related at all to Python 2.5 by itself, but still needed to be dealt). So I think it's useless to ask people to rush testing beta releases: it takes months to get the community synched, and will always take. It's also useless to point the finger to external developers if they don't test Python and there is a bug in a .0 release. Bugs happen. It's software that evolves. My own suggestion is that it's useless to stall a release for months to give external developers time to fix things. I think it's much better to "release early - release often", and just get the damn release out of the door. Usually, it's at that point that the whole community start working on it, and discover bugs. And so what? For production usage, .0 releases of libraries (let alone the interpreter of the language) are a no-go for all software, and I know that for a long time already. I don't ship an application of mine with a Python .0 release no matter what, no matter even if the whole testsuite passes and everything seems to work. I don't have enough benefits for the risks, so I'll wait for .1 or .2 release anyway. It's *very* fine by me if .0 release is actually the first "official" "beta" release for the community, when the core developers say "we're done" and external developers really start get things going. If you really care about .0 stability from a purely commercial point-of-view (it's bad advertisement if many people complain if a major release is broken, etc. etc.), I might suggest you to coordinate with a small group of selected external developers maintaing the larger external packages (Twisted and others). You could put a list of those packages in the release PEP as showstoppers for the release: you should not get a .0 out if those packages are broken. I think this could help smooth out the process. If important external libraries work, many applications relying on it will *mostly* work as well. I personally don't think it's such a big problem if one has to fix a couple of things in a 100K-line application to adjust it to the new .0 release, even if it's actually because of a bug in Python itself. Giovanni Bajo ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-d
Re: [Python-Dev] Handling of sys.args (Re: User's complaints)
Greg Ewing wrote: > Maybe sys needs to be split into two modules, with > the non-sensitive one pre-imported (so that the > importless interpreter you suggest wouldn't be > unnecessarily crippled). Maybe not splitting it, but providing a read-only mechanism of getting at certain elements, with "import sys" still being the way of *modifying* any of these things. Relatively safe items (could be provided as attributes and methods of a read-only class instance in builtins instead of as a module): argv (as a tuple instead of a list) byteorder maxint maxunicode builtin_module_names copyright exc_info() exec_prefix executable exit([arg]) getdefaultencoding() getfilesystemencoding() getwindowsversion() hexversion platform prefix stdin stdout stderr version version_info winver Arguably privileged information (no real reason for non-privileged code to know this stuff): subversion getcheckinterval() getdlopenflags() dllhandle _current_frames() getrefcount(object) getrecursionlimit() _getframe([depth]) __displayhook__ __excepthook__ __stdin__ __stdout__ __stderr__ api_version warnoptions tracebacklimit displayhook(value) excepthook(type, value, traceback) ps1 ps2 Definitely privileged operations: Actually *setting* any of the above to something different modules path exc_clear() setcheckinterval(interval) setdefaultencoding(name) setdlopenflags(n) setprofile(profilefunc) setrecursionlimit(limit) settrace(tracefunc) settscdump(on_flag) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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)
Anthony Baxter wrote: > On Friday 14 July 2006 16:39, Neal Norwitz wrote: >> Remember I also tried to push for more features to go in early? >> That would have given more time for external testing. Still >> features are coming in. Python developers weren't happy about >> having to get things in earlier. I don't see a practical way to >> implement what you propose (see Anthony's comments). > > Following up on this point: > Given the number of "just-this-one-more-thing-please" we've _already_ > had since the b1 feature freeze, do you really except that 90 days of > feature freeze is feasible? And if there's not going to be a feature > freeze, there's hardly any point to people doing testing until there > _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. > Oops. 2.5b9 added a new feature that broke my code, but I didn't test > with that. I think this is where release candidates can come into their own - the beta's can flush out the "just-one-more-thing" pleases, the maintenance branch is forked for rc1, and then any changes on the branch are purely to fix regressions. As far as the idea of a suite of buildbots running the unit tests of large Python applications against the current SVN trunk goes, one problem is that failures in those buildbots will come from two sources: - Python itself fails (broken checkin) - the application unit tests fail (backwards incompatibility) To weed out the false alarms, the slaves will need to be set up to run the Python unit tests first and then the application unit tests only if the Python test run is successful. When the slave suffers a real failure due to a backwards incompatibility, it will take a developer of the application to figure out what it was that broke the application's tests. So while I think it's a great idea, I also think it will need significant support from the application developers in debugging any buildbot failures to really make it work. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE - firewall warning
Gregor Lingl wrote: > I have posted the following message to idle-dev, > but no reply yet. Just a suggestion: > > The firewall warning message in the Pythonshell window > was introduced in Python 2.3 (IDLE 1.0 or something similar?) > > I remember well the problems, to which it was the answer. > (If I remember correctly I was involved in the discussion > thread which led to the introduction of that message.) > > Since more than three years I've used IDLE on many different > systems and I didn't encounter a single Firewall warning since > then. (It seems that firewalls nowadays are not offended by > the use of 127.0.0.1) Unless that firewall is ZoneAlarm on Windows XP :) Something that can easily happen to suppress the firewall warnings for IDLE is that someone runs a Python application and grants it access to the internet. For an executable file signature based outbound firewall like ZoneAlarm, this actually grants passage through the firewall to *all* Python applications, since it is the interpreter binary that gets registered (ZA has a similar lack of granularity when it comes to Java applications). Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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 Fri, Jul 14, 2006 at 12:00:07PM +0200, Giovanni Bajo wrote: > unstable or whatnot. There is no official statement of the kind "all > the real development is done in branches, the trunk is always very > stable, feel free to grab it". Thus, we (external developers) assume > that it's better to wait for the first alpha or beta before starting > doing any testing. Where could we put such a statement? http://www.python.org/dev/tools/, in a discussion of checkin policies, does say: The Python source tree is managed for stability, meaning that if you make a checkout at a random point in time the tree will almost always compile and be quite stable. Large sets of changes, such as the 2.2 type/class rewrite, are usually tested on a branch first and merged into the main stream of development once they're believed to be complete. but this is buried pretty deeply. Maybe some text should be added to the release announcements about this. > I'm lucky, by the time RC1 is out, most of them might have binary packages > available for download, or at least have their (unstable) CVS/SVN trunk fixed > for Python 2.5 (which means that I'll have to fetch that unstable version and And many people won't make binary packages until 2.5 is final, so you're probably not often lucky. --amk ___ Python-Dev mailing list [email protected] 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
>> If you're concerned about noticing when a new release train is >> pulling out of the station ... glyph> I am aware of when new releases come out :). What I'm not aware glyph> of is what features (may) have broken my code, and why. Hmmm... Well, you could subscribe to the python-checkins mailing list. Most of the time you'd probably decide rather quickly to delete the messages, but the stuff you care about should be in the checkin comments. Skip ___ Python-Dev mailing list [email protected] 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)
Greg> Maybe there could be an "unstable" release phase that lasts for a Greg> whole release cycle. So you'd first release version 2.n as Greg> "unstable", and keep 2.(n-1) as the current "stable" release. Then Greg> when 2.(n+1) is ready, 2.n would become "stable" and 2.(n+1) would Greg> become the new "unstable". In GCC don't they do an odd (stable)/even (unstable) release schedule? Same for Linux kernels? Would that help? Skip ___ Python-Dev mailing list [email protected] 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)
>> I believe there was some shortening of the 2.5 release cycle two or >> three months ago. Fred> The squeezing of the releases isn't where the problem is, I think. Had we been in alpha a bit longer (officially before feature freeze) I think there'd have been less back-and-forth about a couple otherwise noncontroversial checkins. Skip ___ Python-Dev mailing list [email protected] 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)
"A.M. Kuchling" wrote: >> While the new python.org is very nice, I do note that there's no "blogs" >> entry on the front page, something which has become a fixture on almost >> every other website I visit regularly. > > A 'Blogs' link could be trivially added by linking to > planet.python.org, though the blogs collected there are not in any way > 'the Python developers', but a jumble of developers and users. I > don't think enough core developers have weblogs (or write about > Python) to make a 'python-dev only' planet very useful. on the other hand, the material you're producing for the "what's new" document would be a rather excellent development blog in itself. just post new sections to the blog when they're ready... (add PEP announcements and python-dev summary items to the mix, and you have a high-quality development blog generated entirely from existing content) (hmm. maybe this could be put together by a robot? time to start hacking on "The Daily URL 2.0 Beta", I suppose...) ___ Python-Dev mailing list [email protected] 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> How often is the python build broken or otherwise unusable? Not very often. I use the head branch of the repository as the source of the interpreter I run on my laptop. It generally takes just a couple minutes on my now-aging PowerBook to svn up and reinstall. I can only recall one time in the past where I had to temporarily fall back to 2.4 because of some change that broke an application. Admittedly, I'm not as sophisticated a user as Fredrik or Glyph, but I suspect that my usage of the language isn't all that different from most Python developers out there. Neal> Is part of your point that these developers only care about Neal> something called "release" and they won't start testing before Neal> then? If that's the case why don't we start making Neal> (semi-)automated alpha releases every month? How would that be any easier than a user setting up a read-only repository and svn-up-ing it once a month then using that as the default interpreter on that person's development machine? I maintain interpreters for 2.3, 2.4 and bleeding edge at the moment. If I need to it's fairly trivial (a symlink change) to fall back to the latest stable release. Glyph, would that sort of scheme work for you? Skip ___ Python-Dev mailing list [email protected] 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)
>> This is the part I don't get. For the external developers, if they >> care about compatibility, why aren't they testing periodically, >> regardless of alpha/beta releases? Fredrik> because they don't want to waste time and effort on testing Fredrik> against releases that are not necessarily a close approximation Fredrik> of the full release? testing takes time, and time can be used Fredrik> for many different things. How is that a waste of time? You've got the latest stable 2.4 installed I presume. Do the svn-up/make dance (at least on Unix-y systems - can it be much more difficult on Windows?). If it breaks something, either figure out why or drop back to 2.4 for a week or two and try again. If application breakage remains, investigate. Skip ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python Style Sheets ? Re: User's complaints
Guido van Rossum wrote: ... > > This is an illustration of the dilemma of maintaining a popular > language: Everybody hates change (me too!) but everybody also has one > thing that's bothering them so much they absolutely want it to be > changed. If you were to implement all those personal pet peeves, you'd > get a language that's more different from Python than Python is from > Fortran. > > So where's the middle ground? I feel some freedom could be reclaimed with a solution in the spirit of Turing equivalence. Or, to take a less grandiose comparison, web style sheets - separation of content and presentation. Suppose the standard required a (possibly empty) style-defining file prefix that constrains the python source code in the file, and concurrently defined (mostly) reversible and transparent source-to-source transforms that would map any source code file to an equivalent source code file with an arbitrary chosen prefix. Then users could chose their style of Python and either transform all source files they install to their own style, or setup their editor to do it back-and-forth for them. The choice of python presentation style would then become a private choice. To illustrate the idea, this already exists in very embryonic form with unicode encoding modelines. The current standard allows to imagine a Python editor that would permit to set a "local standard encoding modeline" and then present any source file as if it had been written while taking maximal profit from the chosen encoding. Which may also be simple ascii. Cheers, BB -- "C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré ___ Python-Dev mailing list [email protected] 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: > On Friday 14 July 2006 16:39, Neal Norwitz wrote: > > Remember I also tried to push for more features to go in early? > > That would have given more time for external testing. Still > > features are coming in. Python developers weren't happy about > > having to get things in earlier. I don't see a practical way to > > implement what you propose (see Anthony's comments). > > Following up on this point: > Given the number of "just-this-one-more-thing-please" we've _already_ > had since the b1 feature freeze, do you really except that 90 days of > feature freeze is feasible? And if there's not going to be a feature > freeze, there's hardly any point to people doing testing until there > _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. > Oops. 2.5b9 added a new feature that broke my code, but I didn't test > with that. Maybe the basic question is right, but the emphasis needs to be changed. If we had a rule that said the final release was 90 days after the last submission that wasn't to fix a regression, we'd ask "Is this feature important enough to warrant delaying the release until three months from now?" I'm not sure what I think, but it doesn't seem like an implausible policy. Jeremy > > Anthony > -- > Anthony Baxter <[EMAIL PROTECTED]> > It's never too late to have a happy childhood. > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] 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, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Anthony Baxter wrote: > > On Friday 14 July 2006 16:39, Neal Norwitz wrote: > >> Remember I also tried to push for more features to go in early? > >> That would have given more time for external testing. Still > >> features are coming in. Python developers weren't happy about > >> having to get things in earlier. I don't see a practical way to > >> implement what you propose (see Anthony's comments). > > > > Following up on this point: > > Given the number of "just-this-one-more-thing-please" we've _already_ > > had since the b1 feature freeze, do you really except that 90 days of > > feature freeze is feasible? And if there's not going to be a feature > > freeze, there's hardly any point to people doing testing until there > > _is_ a feature freeze, is there? Oh, great, my code works with 2.5b1. > > Oops. 2.5b9 added a new feature that broke my code, but I didn't test > > with that. > > I think this is where release candidates can come into their own - the beta's > can flush out the "just-one-more-thing" pleases, the maintenance branch is > forked for rc1, and then any changes on the branch are purely to fix > regressions. > > As far as the idea of a suite of buildbots running the unit tests of large > Python applications against the current SVN trunk goes, one problem is that > failures in those buildbots will come from two sources: >- Python itself fails (broken checkin) >- the application unit tests fail (backwards incompatibility) > > To weed out the false alarms, the slaves will need to be set up to run the > Python unit tests first and then the application unit tests only if the Python > test run is successful. > > When the slave suffers a real failure due to a backwards incompatibility, it > will take a developer of the application to figure out what it was that broke > the application's tests. > > So while I think it's a great idea, I also think it will need significant > support from the application developers in debugging any buildbot failures to > really make it work. These buildbots should run the tests from stable, released versions of external packages, assuming that those packages don't ship releases with failing tests. If you ran the test suite for a Zope release and had a test failure, I think there would be a reasonable expectation that it was a Python bug. I'd definitely avoiding mixing a development version of Python and a development version of the test software in the automated build environment. Jeremy > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ Python-Dev mailing list [email protected] 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)
[EMAIL PROTECTED] wrote: > Greg> Maybe there could be an "unstable" release phase that lasts > for a Greg> whole release cycle. So you'd first release version > 2.n as Greg> "unstable", and keep 2.(n-1) as the current "stable" > release. Then Greg> when 2.(n+1) is ready, 2.n would become > "stable" and 2.(n+1) would Greg> become the new "unstable". > > In GCC don't they do an odd (stable)/even (unstable) release > schedule? Same for Linux kernels? Would that help? No. Linux kernel releases are more aggressive because of the fact that all the patches are mostly developed in different branch/repositories and get merged when they are already well tested and incorporated. Linus can merge literally hundreds of patches daily into his *stable* tree, and do releases from it even weekly, because most destabilizing works are being done in large branches carried on for months before they even are evaluated for being merged; or because patches were settled in the -mm tree for months. Linus' tree is kind-of a release branch, with the difference that he is the BDFL and does what he wants with his tree :) To keep this into perspective, remember also that they don't have *any* kind of testsuite (nor a debugger, if I might say). GCC has a more "old-fashioned" release process, where the trunk evolves through 3 stages: Stage 1 is open for all kind of changes (eg: from simple polishing/refactoring, to merging of large branches containing work of several man-years). Stage 2 is still open for new features, but not for big merges. Stage 3 is feature-freezed, bug-fixing only. Then, the trunk is branched into the new release branch, and the trunk gets back to Stage 1. Nominally, a stage lasts 3 months, but Stage 3 often stretches up to 6 months. The release branches are open for *only* regression fixes (that is, fixes that correct things that used to work in previous releases but do not work anymore). Any regression fix (with a corresponding Bugzilla entry, where it's marked and confirmed as "regression") is applied to trunk *and* the open release branches where the regression exists. For convoluted or dangerous regression fixes, usually maintainers prefer to wait 1 week for the patch to settle down on the trunk before applying it to the release branches. The release manager pulls dot releases from the release branch. Usually, the first release (.0) happens 3-4 months *after* the release branch was created, that is after several months of regression-only patches being merged to it (while new work is being done on the trunk in parallel, in its aggressive Stage 1). The 3-Stage work in the trunk is streamlined by the release manager. At the beginning of Stage 1, a detailed techinical list of on-going "projects" (new features) is presented to the mailing list, explaining the current status of the work and its ETA, and the release manager then publishes a work-plan for Stage 1 and 2, telling which projects will be merged when. This avoids multiple large projects to hit the trunk at the same time, causing may headaches to all the other developers. The work-plan is managed and updated in the GCC Wiki (which is off-line right now, but I'll post a link as example when it's back). -- Giovanni Bajo ___ Python-Dev mailing list [email protected] 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 Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote: > (add PEP announcements and python-dev summary items to the mix, and you > have a high-quality development blog generated entirely from existing content) > (hmm. maybe this could be put together by a robot? time to start hacking on > "The Daily URL 2.0 Beta", I suppose...) There's already an RSS feed for the python-dev summaries, so that could go into an aggregator. There isn't a feed for the PEPs, but those events are rarer and could be handled manually. --amk ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Explicit Lexical Scoping (pre-PEP?)
[Fredrik Lundh] def counter(num): num = mutable_int(num) def inc(): num += 1 return num return inc >> >> feel free to replace that += with an .add(1) method call; the point >> wasn't the behaviour of augmented assigment, the point was that that the >> most common use pattern involves *mutation* of the target object. >> >> the syntax isn't that important, really. No it isn't, but I believe it deserves notice that it's easy enough, currently, to mock your mutable_int replacing the "+=" by a simple "+", while the "+=" itself is not possible even though it reflects the intention more precisely. [Jeremy Hylton] > > Mutation is different from rebinding.A tuple is immutable, but you > can rebind the variable that refers to the tuple. It's more than just rebinding, it's rebinding to a function of the currently bound value. And /that/ has clear features in common with mutation (witness most of the current semantics and implementation of augmented assignments, ie, how much and far it manages to postpone the decision as to which is actually the case). > I think we will > confuse users if we use the term mutation to refer to name binding. > Name binding is already a subtle issue, so I think the risk is > significant. I'd tend to agree, but imho there is a complementary risk of propagating confusion by denying what augmented assignments clearly show : that rebinding to a function of the currently bound value has so much in common with mutation that augmented assignments allow to confuse both cases in source code. Except for the scoping issue under discussion, that is. Cheers, BB -- "C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial support for dlmodule.c in 64-bits OSes
Pierre Baillargeon schrieb: > Currently, many 64-bits Oses cannot uses the dlmodule due to the conflicts > between the sizes of int, long and char *. That is well. The check is made as > run-time, which is also very well. > > The problem is that the Python configuration script (setup.py) also makes the > check and plainly excludes dlmodule.c from being built and deployed. That is > not > so well. > > The reason is that we use the dlmodule solely to get access to the various > flags > (RTLD_NOW, RTLD_GLOBAL, etc), so that we can do some magic with loaded shared > libraries, such as over-ridding the import mechanism so that the default load > flags get changed (via sys.setdlopenflags()) to force some semantics. > > Currently this doesn't work on most 64-bits OSes because the dl module doesn't > exists, so it cannot be imported and its RTLD_* symbols are not accessible. > > So I ask if it would be possible that the test for sys.maxint == 0x7fff in > setup.py be dropped in future releases. I don't know if your patch is acceptable or not, but if it is applied Lib/test/test_dl.py crashes on 64-bit platforms, so this must be changed as well. Further, patches should be uploaded to the SF tracker so they don't get lost or forgotten. OTOH, the RTLD_ constants are possibly available in the DLFCN module, as the documentation explains. Thomas ___ Python-Dev mailing list [email protected] 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)
Jeremy Hylton wrote: >> When the slave suffers a real failure due to a backwards >> incompatibility, it >> will take a developer of the application to figure out what it was >> that broke >> the application's tests. >> >> So while I think it's a great idea, I also think it will need significant >> support from the application developers in debugging any buildbot >> failures to >> really make it work. > > These buildbots should run the tests from stable, released versions of > external packages, assuming that those packages don't ship releases > with failing tests. If you ran the test suite for a Zope release and > had a test failure, I think there would be a reasonable expectation > that it was a Python bug. Definitely, but there's a difference between "bug that broke Python's own unit tests" and "change to a behaviour that package X depended on". It's the latter cases that the external buildbots would be looking for - and while some of those will be shallow enough that the regression is obvious from the unit test error message and the recent Python checkins, the non-obvious ones will require a collaborative resolution. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] 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 Fri, 14 Jul 2006 06:46:55 -0500, [EMAIL PROTECTED] wrote: > >Neal> How often is the python build broken or otherwise unusable? > >Not very often. I have to agree. The effort I'm talking about is not in fixing large numbers of problems, but simply gearing up to properly test to see if there *are* problems. Keep in mind though: just because the problems are small or easy to fix doesn't mean they're not severe. One tiny bug can prevent a program from even starting up. >Admittedly, I'm not as sophisticated a user as Fredrik or Glyph, but I >suspect that my usage of the language isn't all that different from most >Python developers out there. A huge percentage of Python developers are working with Zope, which means that although *their* code might not be terribly "sophisticated", it is nevertheless sitting on top of a rather large and intricate pile of implicit dependencies on interpreter behavior. >Neal> Is part of your point that these developers only care about >Neal> something called "release" and they won't start testing before >Neal> then? If that's the case why don't we start making >Neal> (semi-)automated alpha releases every month? >How would that be any easier than a user setting up a read-only repository >and svn-up-ing it once a month then using that as the default interpreter on >that person's development machine? I maintain interpreters for 2.3, 2.4 and >bleeding edge at the moment. If I need to it's fairly trivial (a symlink >change) to fall back to the latest stable release. >Glyph, would that sort of scheme work for you? No. I really think you're underestimating the sort of effort required to upgrade Python. First of all, I do have a job :) and it'd be very hard to make the case to an investor that it was worth tracking down every potential bug I had to determine whether it was a problem because I was working with an unreleased version of Python. This is the same reason I don't use beta versions of the kernel or libc for development. For that matter, I've had to avoid posting to this mailing list because even *this* is stretching my already overburdened schedule :). Secondly, I have to work with a few extension modules. To name a few: * ctypes * PyPAM * pysqlite2 * zope.interface (C optimizations) * xapian * pylucene * dspam * PyOpenSSL * PIL * PyCrypto * pyexpat * pygtk * pyvte Recompiling all of these is a project that takes a day. PyLucene, in fact, I've never managed to build myself, and I can only run because there happen to be debian packages which work (with some fiddling) on Ubuntu. There's no interactive warning during 'svn up' that it's time to recompile everything, either, so I don't even know when the ABIs are going to have changed. Even if everything works perfectly, and were perfectly automated, the compile itself would take a few hours. I also test work on Windows on occasion and recompiling these things _there_ is the work of a week and a half, not to mention it requires that I be sitting at the one machine where I have my Microsoft™ Developer™ Tools™ installed. I made the buildbot recommendation specifically because it would centralize the not inconsiderable effort of integrating these numerous dependencies (presuming that I could submit a Divmod buildbot as well as a Twisted one). ___ Python-Dev mailing list [email protected] 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 Thu, 13 Jul 2006 23:39:06 -0700, Neal Norwitz <[EMAIL PROTECTED]> wrote: >On 7/13/06, Fredrik Lundh <[EMAIL PROTECTED]> wrote: >> a longer beta period gives *external* developers more time to catch up, >> and results in less work for the end users. >This is the part I don't get. For the external developers, if they >care about compatibility, why aren't they testing periodically, >regardless of alpha/beta releases? How often is the python build >broken or otherwise unusable? How often do you test new builds of Python against the most recent alpha of, e.g. the Linux kernel? This isn't just a hypothetical question: Twisted has broken because of changes to Linux as often as it has broken due to changes in Python :). In Linux's case we're all lucky because *any* regressions with existing software are considered bugs, whereas in Python's case, some breakagaes are considered acceptable since it's more feasible to have multiple builds of Python installed more than multiple kernels for different applications. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] IDLE - firewall warning
Gregor Lingl <[EMAIL PROTECTED]> wrote: > I have posted the following message to idle-dev, > but no reply yet. Just a suggestion: > > The firewall warning message in the Pythonshell window > was introduced in Python 2.3 (IDLE 1.0 or something similar?) Speaking of 'features that would have been nice to get into 2.5'; had we gotten the asynchronous subprocess support in, we could have done away with the socket support, though it would have required a bit of modification to the XML-RPC implementation. - Josiah ___ Python-Dev mailing list [email protected] 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, A.M. Kuchling <[EMAIL PROTECTED]> wrote: > On Fri, Jul 14, 2006 at 01:37:28PM +0200, Fredrik Lundh wrote: > > (add PEP announcements and python-dev summary items to the mix, and you > > have a high-quality development blog generated entirely from existing > > content) > > (hmm. maybe this could be put together by a robot? time to start hacking > > on > > "The Daily URL 2.0 Beta", I suppose...) > > There's already an RSS feed for the python-dev summaries, so that > could go into an aggregator. There isn't a feed for the PEPs, but > those events are rarer and could be handled manually. I believe that's broken at the moment, at least in the sense that it's no longer updated: http://psf.pollenation.net/cgi-bin/trac.cgi/ticket/366 I don't have enough time right now to figure out the new website and how to fix it. Maybe when I get back from Sydney in a couple of weeks. Steve -- I'm not *in*-sane. Indeed, I am so far *out* of sane that you appear a tiny blip on the distant coast of sanity. --- Bucky Katt, Get Fuzzy ___ Python-Dev mailing list [email protected] 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 Style Sheets ? Re: User's complaints
You must be misunderstanding. The root problem is that people (rightly) complain that the language changes too much. And you want to "fix" this by adding a deep and fundamental change to the language? What planet are you from? It reminds me of Jini, which was presented as a new standard to address the problem of too many conflicting standard. Get it? :-) --Guido On 7/14/06, Boris Borcic <[EMAIL PROTECTED]> wrote: > Guido van Rossum wrote: > ... > > > > This is an illustration of the dilemma of maintaining a popular > > language: Everybody hates change (me too!) but everybody also has one > > thing that's bothering them so much they absolutely want it to be > > changed. If you were to implement all those personal pet peeves, you'd > > get a language that's more different from Python than Python is from > > Fortran. > > > > So where's the middle ground? > > I feel some freedom could be reclaimed with a solution in the spirit of Turing > equivalence. Or, to take a less grandiose comparison, web style sheets - > separation of content and presentation. > > Suppose the standard required a (possibly empty) style-defining file prefix > that > constrains the python source code in the file, and concurrently defined > (mostly) > reversible and transparent source-to-source transforms that would map any > source > code file to an equivalent source code file with an arbitrary chosen prefix. > Then users could chose their style of Python and either transform all source > files they install to their own style, or setup their editor to do it > back-and-forth for them. The choice of python presentation style would then > become a private choice. > > To illustrate the idea, this already exists in very embryonic form with > unicode > encoding modelines. The current standard allows to imagine a Python editor > that > would permit to set a "local standard encoding modeline" and then present any > source file as if it had been written while taking maximal profit from the > chosen encoding. Which may also be simple ascii. > > Cheers, BB > -- > "C++ is a contradiction in terms" - Lorentz, Einstein, Poincaré > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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)
Whoa, whoa. What's the *problem* we're trying to solve here? On 7/14/06, Nick Coghlan <[EMAIL PROTECTED]> wrote: > Greg Ewing wrote: > > Maybe sys needs to be split into two modules, with > > the non-sensitive one pre-imported (so that the > > importless interpreter you suggest wouldn't be > > unnecessarily crippled). > > Maybe not splitting it, but providing a read-only mechanism of getting at > certain elements, with "import sys" still being the way of *modifying* any of > these things. > > Relatively safe items (could be provided as attributes and methods of a > read-only class instance in builtins instead of as a module): > >argv (as a tuple instead of a list) >byteorder >maxint >maxunicode >builtin_module_names >copyright >exc_info() >exec_prefix >executable >exit([arg]) >getdefaultencoding() >getfilesystemencoding() >getwindowsversion() >hexversion >platform >prefix >stdin >stdout >stderr >version >version_info >winver > > > Arguably privileged information (no real reason for non-privileged code to > know this stuff): >subversion >getcheckinterval() >getdlopenflags() >dllhandle >_current_frames() >getrefcount(object) >getrecursionlimit() >_getframe([depth]) >__displayhook__ >__excepthook__ >__stdin__ >__stdout__ >__stderr__ >api_version >warnoptions >tracebacklimit >displayhook(value) >excepthook(type, value, traceback) >ps1 >ps2 > > > Definitely privileged operations: >Actually *setting* any of the above to something different >modules >path >exc_clear() >setcheckinterval(interval) >setdefaultencoding(name) >setdlopenflags(n) >setprofile(profilefunc) >setrecursionlimit(limit) >settrace(tracefunc) >settscdump(on_flag) > > Cheers, > Nick. > > -- > Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia > --- > http://www.boredomandlaziness.org > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/guido%40python.org > -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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, Guido van Rossum <[EMAIL PROTECTED]> wrote: Whoa, whoa. What's the *problem* we're trying to solve here?I have a use case for sandboxing. I am already having to plan to have a mini-sys module in a sandbox so that they cannot get access to dangerous things. -BrettOn 7/14/06, Nick Coghlan < [EMAIL PROTECTED]> wrote:> Greg Ewing wrote:> > Maybe sys needs to be split into two modules, with> > the non-sensitive one pre-imported (so that the> > importless interpreter you suggest wouldn't be > > unnecessarily crippled).>> Maybe not splitting it, but providing a read-only mechanism of getting at> certain elements, with "import sys" still being the way of *modifying* any of > these things.>> Relatively safe items (could be provided as attributes and methods of a> read-only class instance in builtins instead of as a module):>>argv (as a tuple instead of a list) >byteorder>maxint>maxunicode>builtin_module_names>copyright>exc_info()>exec_prefix>executable>exit([arg])>getdefaultencoding() >getfilesystemencoding()>getwindowsversion()>hexversion>platform>prefix>stdin>stdout>stderr>version>version_info >winver>>> Arguably privileged information (no real reason for non-privileged code to> know this stuff):>subversion>getcheckinterval()>getdlopenflags() >dllhandle>_current_frames()>getrefcount(object)>getrecursionlimit()>_getframe([depth])>__displayhook__>__excepthook__>__stdin__>__stdout__ >__stderr__>api_version>warnoptions>tracebacklimit>displayhook(value)>excepthook(type, value, traceback)>ps1>ps2>>> Definitely privileged operations: >Actually *setting* any of the above to something different>modules>path>exc_clear()>setcheckinterval(interval)>setdefaultencoding(name)>setdlopenflags(n) >setprofile(profilefunc)>setrecursionlimit(limit)>settrace(tracefunc)>settscdump(on_flag)>> Cheers,> Nick.>> --> Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia> ---> http://www.boredomandlaziness.org > ___> Python-Dev mailing list> [email protected]> http://mail.python.org/mailman/listinfo/python-dev> Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org >Guido van Rossum (home page: http://www.python.org/~guido/)___Python-Dev mailing list [email protected]://mail.python.org/mailman/listinfo/python-devUnsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list [email protected] 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, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote: > > Whoa, whoa. What's the *problem* we're trying to solve here? > > I have a use case for sandboxing. I am already having to plan to have a > mini-sys module in a sandbox so that they cannot get access to dangerous > things. 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. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list [email protected] 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, Guido van Rossum <[EMAIL PROTECTED]> wrote: On 7/14/06, Brett Cannon <[EMAIL PROTECTED]> wrote:> On 7/14/06, Guido van Rossum <[EMAIL PROTECTED]> wrote:> > Whoa, whoa. What's the *problem* we're trying to solve here? >> I have a use case for sandboxing. I am already having to plan to have a> mini-sys module in a sandbox so that they cannot get access to dangerous> things.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 todeath in abstracto.Fine by me. My design doc already has a preliminary list going that people can take a look at. But it could still change if security analysis shows possible problems with exposing some of them. -Brett ___ Python-Dev mailing list [email protected] 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
Christopher Armstrong wrote: > python -U is a failure for obvious reasons and a > __future__ import is clearly better. I disagree. Regards, Martin ___ Python-Dev mailing list [email protected] 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)
Christopher Armstrong wrote: > I'm at least willing to set up the buildbots for projects I care about > (Twisted, pydoctor, whatever), and perhaps help out with the setting > up the buildmaster. If you need trigger calls from subversion's post-commit hooks, please let me know, and I can set them up. Regards, Martin ___ Python-Dev mailing list [email protected] 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)
"A.M. Kuchling" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > http://www.python.org/dev/tools/, in a discussion of checkin policies, > does say: > > The Python source tree is managed for stability, meaning that > if you make a checkout at a random point in time the tree will almost > always compile and be quite stable. 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? tjr ___ Python-Dev mailing list [email protected] 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 Fri, 14 Jul 2006 23:38:52 +0200, "\"Martin v. Löwis\"" <[EMAIL PROTECTED]> wrote: >Christopher Armstrong 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. For example, [EMAIL PROTECTED]:~% python -S -U -c 'import pickletools' Traceback (most recent call last): File "", line 1, in ? File "/usr/lib/python2.4/pickletools.py", line 219, in ? doc="One-byte unsigned integer.") File "/usr/lib/python2.4/pickletools.py", line 187, in __init__ assert isinstance(name, str) AssertionError This was just the first convenient example. There are others. 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. ___ Python-Dev mailing list [email protected] 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 Thu, 13 Jul 2006 23:27:56 -0500, [EMAIL PROTECTED] wrote: > >>The buildbot idea sounds excellent. > > Thanks. If someone can set this up, it pretty much addresses my > concerns. > ... > I am aware of when new releases come out :). What I'm not aware of is > what > features (may) have broken my code, and why. As long as Python's > [EMAIL PROTECTED] > continues to run the test suites cleanly, I am mostly unconcerned. When > it > breaks, though, I want a chance to look at the cause of the breakage, > *before* > there is an alpha or beta Python release out and people are starting to > write > code that depends on its new features. Is the following something like what you are suggesting? 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 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. Terry Jan Reedy ___ Python-Dev mailing list [email protected] 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 __future__ import would allow these behaviors to be upgraded > module-by-module. No it wouldn't. __future__ works solely on the semantics of different pieces of syntax, because any syntax changes are purely local to the current module. This doesn't work for datatypes, because data types can cross module boundaries - other modules may still be using the old behaviour, and there's nothing the current module can do about it. 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. > 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. There's never been a concerted effort to make even the standard library work under -U. Maybe that should be a goal for Python 2.6 - figure out what tools or changes are needed to make code -U safe, add them, and then update the standard library to use them. PEP 349 (currently deferred, although I don't recall why) discusses some of the issues involved in making code unicode-safe, while still supporting non-unicode safe applications as clients. Cheers, Nick. [1] http://www.python.org/dev/peps/pep-0349/ -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
