[Python-Dev] bsddb broken
Anyone wanna give bsddb some tlc? Head and 2.4 work with 4.2 on amd64 and x86. Neither python version works when using BSD db 4.1 or 3.2. I don't know anything about bsddb, so any help fixing this would be appreciated. In 4.1 it seems associate doesn't work. http://python.org/sf/1332873 3.2 has other problems. 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] TAR problems under Solaris
Anthony Baxter wrote: Dunno, but I'm always having problems w/ Solaris tar, so I just use GNU tar on Solaris. ;) Maybe we should switch to cpio-based distributions? Peace, brother... Err, pax(1). -bash-3.00$ uname -a SunOS tb3 5.10 Generic sun4u sparc SUNW,Sun-Fire-V440 -bash-3.00$ bunzip2 -c Python-2.4.2.tar.bz2 |pax -r pax: ././@LongLink : Unknown filetype This message refers to the links in Mac/OSXResources/app/Resources/English.lproj/Documentation/ide Apart from that, pax extracts it the same way as gtar. Regards, Martin P.S. I always ROTFL when I see mentioning of the tar wars in the POSIX standard. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
me This works for me (compiles with no warnings, passes all tests). ... The bagpipe didn't say no, so I checked this in on trunk and the 2.4 branch. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildbot
On 5-jan-2006, at 11:53, [EMAIL PROTECTED] wrote: me This works for me (compiles with no warnings, passes all tests). ... The bagpipe didn't say no, so I checked this in on trunk and the 2.4 branch. I haven't tested this on 10.4 yet, but it should work. The heuristic is false for anyone that will try to build a 10.3-only binary on 10.4, but I'd be surprised if that would work anyway. Ronald Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Buildbot questions
I currently have a (quite weak) computer that mostly sits idle (shares the web connection), Tbird 750; 640Mb RAM; Windows Server 2003 Standard Edition. Since the computer sits there doing nothing, I could probably put a buildbot on it if needed (since the python-dev thread states that many windows flavour would be appreciable and that Win2003 may not be extremely common), but i'd like to know how often it'll try to build, and how long the build itself may take on such a platform. Morel Xavier ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
Morel but i'd like to know how often it'll try to build, and how long Morel the build itself may take on such a platform. It should build every time there's a checkin on trunk or the 2.4 branch. As for performance, take a look at http://www.python.org/dev/buildbot/ to see how long some of the other build bots take and extrapolate from that. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
On Thu, 2006-01-05 at 00:36 +0100, Martin v. Löwis wrote: The portable way would be to check for svnversion in configure, and then only use it if it was found. You could also check for .svn in configure, and generate the entire buildno generation. OTOH, I also think we should get rid of buildno entirely. Instead, svnversion should be compiled into the object file, or, if it is absent, $Revision$ should be used; the release process should be updated to force a commit to the tag/Modules/buildno.c right after creating the tag. sys.build_number should go, and be replaced with sys.svn_info, which should also include the branch from which the checkout/export was made. $Revision$ should only be trusted if it comes from a tag/. Should I write a PEP for that? To be honest I don't think we need a PEP for that. I saw that you checked in a bunch of stuff here, and that's great, thanks! I was working on a patch to add a PY_BUILDNO macro to Include/patchlevel.h, which would have $Revision$ as its value. patchlevel.h seems like the natural place to put this, since any release manager is going to be modifying this file anyway. PEP 101 should be updated so that updating patchlevel.h be the last commit before an svn export is done (but that PEP needs an overhaul anyway to change the cvs references into svn commands). Thoughts? -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
FWIW, I have an older box running Ubuntu 05.10 that spends most of it's days pining for stuff to do (at the moment, it does DHCP and DNS for the house. Yes, I know I have too many damn computers here). I can set up a buildbot on it easily enough. It's something like a 600MHz P3 or something. Is it going to be useful to have this in the mix? Heck, there's a pile of 500MHz P3s sitting here that I could drop a random free unix onto if someone wants to nominate something that's a) useful b) not a total pain in the clacker to install. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
[Morel Xavier] I currently have a (quite weak) computer that mostly sits idle (shares the web connection), Tbird 750; 640Mb RAM; Windows Server 2003 Standard Edition. Since the computer sits there doing nothing, I could probably put a buildbot on it if needed (since the python-dev thread states that many windows flavour would be appreciable and that Win2003 may not be extremely common), but i'd like to know how often it'll try to build, and how long the build itself may take on such a platform. A problem for Windows buildbot slaves is that they need an appropriate compiler. Does this machine have MS VC 7.1 installed? If not, it can't compile the code. The Windows Python would also like to build several other packages (like bz2 and Tcl/Tk). An update style of slave does an svn update rather than a full checkout, and that usually goes very fast after the first time. Likewise compiling if binaries are left behind across runs. For the rest, open a DOS box on this machine, cd to root of a Python 2.4.2 installation, and time python Lib\test\regrtest.py -uall That's about how long it will take on that machine to run all the tests from the current trunk too. Really thorough tests take 8x as long (with and without purging .pyc/.pyo files first, with and without -O, and under release and debug builds: 2*2*2 = 8). ___ 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] Jython and CPython
If the portability problem can be solved by checking things into Jython instead, I think I would prefer that. I'm definitely interested in bringing ElementTree into Jython at some point, though I probably won't have time to look into it until after the next Jython release. I'm quite sure that we can work something out so that Jython-specific portability code can reside in Jython only. Though whenever it is cleanly do-able, I'd like to be able to use the python libraries unchanged. It sounds like this is a case where it is not that clean to do... -Frank ___ 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] file.next() vs. file.readline()
On Wed, Jan 04, 2006 at 10:10:07AM -0800, Guido van Rossum wrote: I'd say go right ahead and submit a change to SF (and then after it's reviewed you can check it in yourself :-). http://www.python.org/sf?id=1397960 The patch comments and source should explain it all. The diff is quite big (just over 16k) because of the 16k testfile. As for checking in myself, I think my write-access was (rightly, considering my absense) removed sometime last year :) In Py3K I want to revise the whole I/O stack to be independent from C stdio (except on those platforms where that's the only I/O you have.) When I first read that, I thought yck. Then I went and actually read all of fileobject.c, went yck more times than I cared to count, and now I wholeheartedly agree ;) Changing the read* methods to use the file-iteration buffer would be a lot simpler than I thought, by the way. And it would simplify a lot of the code (not just because of the code duplication currently necessary.) I'm sure there'll be people who like having direct control over howmuch gets read though. Which is fine, I think that should stay possible, but I don't think those people deserve to get the full force of Tim's optimizations either. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
Hi Martin, On Thu, Jan 05, 2006 at 12:36:40AM +0100, Martin v. L?wis wrote: OTOH, I also think we should get rid of buildno entirely. Instead, svnversion should be compiled into the object file, or, if it is absent, $Revision$ should be used; the release process should be updated to force a commit to the tag/Modules/buildno.c right after creating the tag. sys.build_number should go, and be replaced with sys.svn_info, which should also include the branch from which the checkout/export was made. $Revision$ should only be trusted if it comes from a tag/. All this sounds good. Should I write a PEP for that? I agree with Barry that it's overkill to ask for PEPs for too many small details. A bientot, Armin ___ 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] New PEP: Using ssize_t as the index type
Hi Martin, On Fri, Dec 30, 2005 at 11:26:44AM +0100, Martin v. L?wis wrote: Hum. It would be much cleaner to introduce a new format character to replace '#' and deprecate '#'... That would certainly be clearer. What character would you suggest? I see two drawbacks with that approach: 1. writing backwards-compatible modules will become harder. Users have to put ifdefs around the ParseTuple calls (or atleast around the format strings) Ok, I see your point. In theory we could reuse a macro-based trick in C extensions: #include Python.h #ifndef Py_SIZE_CHR typedef int Py_Ssize_t; #define Py_SIZE_CHR # #endif And then we can replace -- say -- the format string is#s# with is Py_SIZE_CHR s Py_SIZE_CHR But it's rather cumbersome. An equally strange alternative would be to start C modules like this: #define Py_Ssize_t int /* compatibility with Python = 2.4 */ #include Python.h This would do the right thing for = 2.4, using ints everywhere; and the Python.h version 2.5 would detect the #define and assume it's a 2.5-compatible module, so it would override the #define with the real thing *and* turn on the ssize_t interpretation of the '#' format character. Not that I think that this is a good idea. Just an idea. I still don't like the idea of a magic #define that changes the behavior of '#include Python.h', but I admit I don't find any better solution. I suppose I'll just blame C. A bientot, Armin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
On Thu, 5 Jan 2006, Tim Peters wrote: [...] A problem for Windows buildbot slaves is that they need an appropriate compiler. Does this machine have MS VC 7.1 installed? If not, it can't compile the code. The Windows Python would also like to build several other packages (like bz2 and Tcl/Tk). Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? http://groups.google.co.uk/group/comp.lang.python/browse_frm/thread/226584dd47047bb6/1e33ad19197bee20 (I'm not offering a buildbot myself, just pointing out the possibility of using this tool) There always the chance it gets something wrong or falls over while trying to interpret the project file, of course. That in itself would be beneficial, though, if there's a committer willing to fix it when it breaks -- I currently have access to MS compilers, but I remember many happy :-/ hours as a graduate student trying to compile Fortran and C extensions on win32 with free compilers. An update style of slave does an svn update rather than a full checkout, and that usually goes very fast after the first time. Likewise compiling if binaries are left behind across runs. [...] Much though I like SVN, it seems its working copy management still leaves a little to be desired: Even quite recently (fairly sure it was client version 1.2.*, on Win XP) and with read-only checkouts used only for builds, I've still seen it end up in an incorrect state. I suspect 'svn switch' or 'svn up -r x' was the culprit, though, so perhaps it's not a problem if exactly 'svn up' is the only svn command ever executed on the checkout. Still, perhaps it's wise to wipe the checkout every so often? John ___ 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] New PEP: Using ssize_t as the index type
Armin Rigo wrote: This would do the right thing for = 2.4, using ints everywhere; and the Python.h version 2.5 would detect the #define and assume it's a 2.5-compatible module, so it would override the #define with the real thing *and* turn on the ssize_t interpretation of the '#' format character. This would be very similar to the PY_SIZE_T_CLEAN approach, except that it would also help to detect spelling mistakes. From an implementation point of view, the real challenge is to give PyArg_ParseTuple a different meaning; I do this be #defining it to PyArg_ParseTupleSsize_t (to preserve binary compatibility for the original interpretation of ParseTuple). Putting additional flags arguments in the entire code is also quite hackish. I still don't like the idea of a magic #define that changes the behavior of '#include Python.h', but I admit I don't find any better solution. I suppose I'll just blame C. More precisely, the printf style of function calling, and varargs functions. ISO C is pretty type safe, but with varargs functions, you lose that completely. I still hope I can write a C parser some day that does ParseTuple/BuildValue checking. 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] Buildbot questions
Anthony Baxter wrote: FWIW, I have an older box running Ubuntu 05.10 that spends most of it's days pining for stuff to do (at the moment, it does DHCP and DNS for the house. Yes, I know I have too many damn computers here). I can set up a buildbot on it easily enough. It's something like a 600MHz P3 or something. Is it going to be useful to have this in the mix? With the gentoo installation, I think we have enough linux for the moment. Somebody noticed that the Waterfall view of buildbot quickly becomes unreadable if there are too many builds. Heck, there's a pile of 500MHz P3s sitting here that I could drop a random free unix onto if someone wants to nominate something that's a) useful b) not a total pain in the clacker to install. For a), I think one of the BSDs might be useful. Whether they qualify for b), I don't know. 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] Buildbot questions
John J Lee wrote: Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? I feel that any contribution here takes quite some time initially, so somebody making that offer should accept some pain until it really works self-contained. I would need to know the exact sequence of commands that are necessary for the build; I assume the autoconf builder would be useless. 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] Buildbot questions
On Friday 06 January 2006 07:44, Martin v. Löwis wrote: With the gentoo installation, I think we have enough linux for the moment. Somebody noticed that the Waterfall view of buildbot quickly becomes unreadable if there are too many builds. My only concern is that it's gentoo, not just linux. I know that for a couple of my other open source projects I usually don't spend too long debugging bizarrely broken apparent bugs, because it ends up being some strange build flag or some such on the gentoo box in question. On the other hand, this box is unlikely to have been built with a selection of gcc flags that Neal just selected randomly from the gcc manual wink so it's probably going to be better than that. Heck, there's a pile of 500MHz P3s sitting here that I could drop a random free unix onto if someone wants to nominate something that's a) useful b) not a total pain in the clacker to install. For a), I think one of the BSDs might be useful. Whether they qualify for b), I don't know. Anyone else have an opinion on the ease of installation for the various BSDs? Last time I tried one (which was several years ago) it was Not Very Good. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
On Jan 5, 2006, at 1:08 PM, Anthony Baxter wrote: On Friday 06 January 2006 07:44, Martin v. Löwis wrote: With the gentoo installation, I think we have enough linux for the moment. Somebody noticed that the Waterfall view of buildbot quickly becomes unreadable if there are too many builds. My only concern is that it's gentoo, not just linux. I know that for a couple of my other open source projects I usually don't spend too long debugging bizarrely broken apparent bugs, because it ends up being some strange build flag or some such on the gentoo box in question. On the other hand, this box is unlikely to have been built with a selection of gcc flags that Neal just selected randomly from the gcc manual wink so it's probably going to be better than that. Heck, there's a pile of 500MHz P3s sitting here that I could drop a random free unix onto if someone wants to nominate something that's a) useful b) not a total pain in the clacker to install. For a), I think one of the BSDs might be useful. Whether they qualify for b), I don't know. Anyone else have an opinion on the ease of installation for the various BSDs? Last time I tried one (which was several years ago) it was Not Very Good. FreeBSD and OpenBSD are painless these days, assuming that you're comfortable reading text during installation. No experience with NetBSD. -bob ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
On Thu, 5 Jan 2006, John J Lee wrote: Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? s/Munman/Murmann/ John ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
Anthony Baxter wrote: My only concern is that it's gentoo, not just linux. I know that for a couple of my other open source projects I usually don't spend too long debugging bizarrely broken apparent bugs, because it ends up being some strange build flag or some such on the gentoo box in question. For buildbot, failures to build are good (if they are reproducable); if it succeeds for gentoo, but fails on some other system on which it ought to work, then adding this system as a build slave would be useful. Regards, Martin P.S. That's assuming we get in a state where the tests usually pass, of course. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Draft proposal: Implicit self in Python 3.0
Hello! I have some proposal for Python 3.0 (interesting one, from my point of view). I'm sorry for my English, it is not very good. Abstract There are three different peculiarity in Python 2.x in respect of 'self' method argument: 1. Each method must have explicit 'self' argument in its argument list 2. This argument must be used explicitly for instance's attribute value assignment 3. The count of explicit arguments in method definition differs from count of explicit parameters when method is called Example 1 (Python 2.x): --- class Foo: def __init__(self, x): # 1: Explicit 'self' argument self.x = x # 2: 'self' must be used explicitly def bar(self, a, b): # 3: There are three arguments... print self.x + a + b Foo(10).bar(20, 30) # ...but only two explicit parameters #is presented This document proposes to change this, as the next example shows: Example 2 (Python 3.0): --- class Foo: def __init__(x): # 1: Implicit self .x = x # 2: Brief form of: self.x = x def bar(a, b): # 3: Two arguments... print .x + a + b Foo(10).bar(20, 30) # ...and exactly two parameters According Python Zen, Explicit is better then implicit, but practicality beats purity and Readability counts ;-) This draft document describes high-level semantic of proposed changes and doesn't discuss details of C implementation. Rationale = When programmer tries to pick up some new programming language from different possibilities (e.g. Smalltalk, Python, Perl, ...), he often bases his choice on secondary and non-essential details. Almost any language has peculiarities, which can distract potential users from language evaluation. Examples of such warts may be [EMAIL PROTECTED]% perlish syntax in Ruby, abundance of parenthesis in Lisp and Schema, and explicit 'self' argument in Python. Of course, from technical point of view, such peculiarities are completely non-issue. Parenthesis is not problem in Lisp if you use a good text editor, perlisms in Ruby can be avoided, etc. But from sociological and usability points of view, such warts can cause remarkable hurt, because they affect first impression about language. In many superficial language comparisons Python's OO approach dismissed as after-thought because of the explicit 'self'. Example: But the most important aspect, why I am using Ruby instead of Python or Perl are the object-orientated features of Ruby, and that Ruby was designed object-oriented right from beginning, unlike Python and Perl where object-orientation was added on later. You can recognize this in e.g. in Python very good, because the first parameter (often named self) of every method of a class is the object on which the method is called (http://www.ntecs.de/old-hp/s-direktnet/rb/ruby.pdf) Of course, this words about Python are not true. Python was object-oriented from the beginning, and explicit 'self' is intentional design decision, which is elegant in some aspects. But from pragmatical point of view, implicit 'self' in Python 3.0 may lower entry barrier for many people and assist Python's wide adoption. The proposed change is not backward-compatible with Python 2.x Detailed proposals == 1. 'self' becomes a keyword, and may be used inside function definition to denote a special implicit function argument 2. New syntax shortcut is introduced: '.attr' inside a function is exact equivalent to 'self.attr'. Full syntax can be used as well 3. 'class' keyword can be used in two different syntactical construction: a) If 'class' keyword immediately followed by identifier, then it is usual class definition. b) In all other cases (inside a function) 'class' keyword denotes value of implicit function argument # in Python 3.0: def sample(a, b): ... class C: pass # ordinary class definition ... print class.__name__ # 'class' is implicit argument ... 4. Each function (not only class methods) accepts two implicit arguments, 'class' and 'self'. With ordinary function call, this arguments has 'None' value def f(a, b): ... return [class, self, a, b] ... f(1, 2) [None, None, 1, 2] Implicit 'class' and 'self' attributes don't participates in partial function application 5. Each function have two constant attributes, __class__ and __self__, both of them have value 'None' f.__class__, f.__self__ (None, None) 6. New builtin function bind(func, self_, [class_]) is introduced. The result is a new function with the same name, __self__ and __class__ attributes of which are equal to self_ and class_, correspondly. If bind function is called without class_ argument, then __class__ value in new
Re: [Python-Dev] buildbot
Brian Warner wrote: There was also a patch[1] to add some regexps to svn_buildbot.py to do this kind of branch determination. I haven't been able to review it properly yet, but it may give you some ideas. The patch itself is completely broken. It removes random parts of svn_buildbot.py, so after applying it, svn_buildbot isn't even syntactically correct anymore. However, I adjusted the patch, so it now works fine. (the other issue was that the regex was not entirely correct: it assumes a trunk/project structure, where we have a project/trunk structure). So at the moment, I'm quite happy with buildbot. My only wish is that it would do static pages, rather than being a web server. I set it up as a reverse proxy (so nobody knows what the port number is, but still). 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] buildbot
Trent Mick wrote: Or for separate logic projects being built with the same builtbot master. For example, say Python's buildbot wanted to do regular builds and tests of the distutils tree (http://svn.python.org/view/distutils/trunk/). I believe you could always get it arranged the way you like by properly setting up an uninteresting changes filter. You would have several builders, one change source, and each builder would filter out the changes it is interested in. 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] Draft proposal: Implicit self in Python 3.0
I wrote: 5. Each function have two constant attributes, __class__ and __self__, both of them have value 'None' Of course, this attributes have names 'im_class' and 'im_self', as before, but can be used with any function. I have not sleep enough last night :) Best regards, Alexandermailto:[EMAIL PROTECTED] ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Buildbot-devel] Re: buildbot
Trent Mick wrote: I meant that more as a justification for improving the Waterfall status receiver to support separate summary pages for separate projects and trunks... all with the same buildbot master server. python.org/dev/buildbot/python/... python.org/dev/buildbot/python-release24-maint/... python.org/dev/buildbot/distutils/... Ah, right. On result presentation, there is definitely room for improvement. 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] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
Barry Warsaw wrote: I was working on a patch to add a PY_BUILDNO macro to Include/patchlevel.h, which would have $Revision$ as its value. As you can see, this is done now. The value appears at the Python level only for tags, though, because it will be unreliable for the trunk and for branches. patchlevel.h seems like the natural place to put this, since any release manager is going to be modifying this file anyway. PEP 101 should be updated so that updating patchlevel.h be the last commit before an svn export is done (but that PEP needs an overhaul anyway to change the cvs references into svn commands). It would still be one level behind: patchlevel.h gets N, then 'svn cp' creates the tag, producing N+1. OTOH, for a tag, the revision number is nearly irrelevant. 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] Draft proposal: Implicit self in Python 3.0
Alexander Kozlovsky wrote: Hello! I have some proposal for Python 3.0 (interesting one, from my point of view). I'm sorry for my English, it is not very good. Your English seems fine. About the only thing I noticed is that you have the meaning of 'function arguments' vs 'function parameters' switched from a Python point of view - the parameters are defined as part of the function definition, while the arguments are provided at call time. This is really a minor semantic quibble though - I expect most people wouldn't have any real trouble figuring out what you meant. Even though I still disagree with it, this is one of the better reasoned no explicit self proposals I've encountered - even if Guido ends up not liking it, I believe it should still be recorded as a PEP on python.org. To sum the proposal up in my own words: Eliminate the need for explicit class and self slots in class and instance methods by implicitly providing those slots on all functions. The main concern I have is with the answer to the question How many positional arguments does the function have if I retrieve it from the class, rather than from an instance? (this is the common concern for almost all proposals to remove the explicit self and class_ slots). That is, the rationale for requiring the explicit self is an outgrowth of the fact that methods can be retrieved directly from the class: class Foo: def __init__(self, x): # 1: Explicit 'self' argument self.x = x # 2: 'self' must be used explicitly def bar(self, a, b): # 3: There are three parameters... print self.x + a + b f = Foo.bar # We retrieve the unbound method f(Foo(10), 20, 30) # And there are three arguments at call time f = Foo().bar# Using an instance binds the first argument f(20, 30)# Which means there are two arguments left You can also bypass the type machinery entirely, and retrieve the raw function object from the class dictionary: f = Foo.__dict__[bar] # This gives a function. . . f(Foo(10), 20, 30) # which takes three arguments as written Under the proposal being discussed, things become far less clear: class Foo: def __init__(x): # 1: Implicit self .x = x # 2: Brief form of: self.x = x def bar(a, b): # 3: Two arguments... print .x + a + b f = Foo(10).bar # We agree this accepts 2 arguments f = Foo.bar # How many arguments does f accept? f = Foo.__dict__[bar] # How many arguments does it accept now? The answer to the first question *has* to be 3, or we lose too much functionality - but that's seriously surprising (the method appears to require two arguments when its defined, but actually requires 3 due to its being retrieved from a class). And it still requires that a distinction be made between instance, class and static methods in order to control the signature of the retrieved method. However, that answer creates its own problems - what if we have a 3-argument function that does exactly what we want our method to do? We'd need some way of signalling to the class that the function should be left alone when being retrieved from the class, but have the first argument bound automatically when being retrieved from an instance. This is where the Explicit is better than implicit and Practicality beats purity *both* kick in in favour of explicit self and class_ parameters - the signature of the retrieved function is exactly what the source code says it is, because there aren't any implicit parameters getting slipped into the parameter list when you aren't looking. As I see it, the real issue is that people are often coming from a Java or C++ background where you can't manipulate functions and classes as first-class objects - the idea that the instance method signature could be written to describe the signature of the unbound method returned by Foo.bar rather than the bound method returned by Foo().bar is an entirely foreign concept. Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
On Fri, 2006-01-06 at 01:33 +0100, Martin v. Löwis wrote: As you can see, this is done now. The value appears at the Python level only for tags, though, because it will be unreliable for the trunk and for branches. Cool, thanks. I can chuck my local diffs now. :) patchlevel.h seems like the natural place to put this, since any release manager is going to be modifying this file anyway. PEP 101 should be updated so that updating patchlevel.h be the last commit before an svn export is done (but that PEP needs an overhaul anyway to change the cvs references into svn commands). It would still be one level behind: patchlevel.h gets N, then 'svn cp' creates the tag, producing N+1. OTOH, for a tag, the revision number is nearly irrelevant. Unless we tagged and then modified the file in that tag as the very last thing we do before we create the tarball. Or is that too evil? -Barry signature.asc Description: This is a digitally signed message part ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Buildbot questions
[John J Lee] Might a buildbot running this setup of David Munman's (free MS compiler + NAnt interpreting the MS project file) be useful? http://groups.google.co.uk/group/comp.lang.python/browse_frm/thread/226584dd47047bb6/1e33ad19197bee20 No comment from me about that (don't know anything about it, and don't have time to learn). Someone who wants to see a platform exercised needs to volunteer that platform themself (and realize that every stinkin' little step has to be so well defined that the people running the buildbot _master_ can send the exact steps needed to the slave). ... Much though I like SVN, it seems its working copy management still leaves a little to be desired: Even quite recently (fairly sure it was client version 1.2.*, on Win XP) and with read-only checkouts used only for builds, I've still seen it end up in an incorrect state. I suspect 'svn switch' or 'svn up -r x' was the culprit, though, so perhaps it's not a problem if exactly 'svn up' is the only svn command ever executed on the checkout. I doubt anyone slings more svn projects, branches and tags than Zope Corp, and I've had no problems with svn on WinXP there except when a project switches from making copies of externals to getting them via svn:externals instead -- and then everyone has problems, regardless of platform. What I _have_ had problems with is PuTTY, and recently discovered that all my months-long svn+ssh problems went away after backing off to the older PuTTY 0.57 (and come back again immediately upon switching to 0.58). Still, perhaps it's wise to wipe the checkout every so often? I think it is. And while I haven't seen this under MS VC7.1 yet, a few times I caught VC 6.0 failing to recompile after a relevant header file changed. Certainly from-scratch checkout + build should be done before a release. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Buildbot-devel] Re: buildbot
Or for separate logic projects being built with the same builtbot master. For example, say Python's buildbot wanted to do regular builds and tests of the distutils tree (http://svn.python.org/view/distutils/trunk/). I believe you could always get it arranged the way you like by properly setting up an uninteresting changes filter. You would have several builders, one change source, and each builder would filter out the changes it is interested in. I meant that more as a justification for improving the Waterfall status receiver to support separate summary pages for separate projects and trunks... all with the same buildbot master server. python.org/dev/buildbot/python/... python.org/dev/buildbot/python-release24-maint/... python.org/dev/buildbot/distutils/... Trent -- Trent Mick [EMAIL PROTECTED] ___ 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] buildno (Was: [Python-checkins] commit of r41907- python/trunk/Makefile.pre.in)
Barry Warsaw wrote: It would still be one level behind: patchlevel.h gets N, then 'svn cp' creates the tag, producing N+1. OTOH, for a tag, the revision number is nearly irrelevant. Unless we tagged and then modified the file in that tag as the very last thing we do before we create the tarball. Or is that too evil? That would work, and I wouldn't see anything wrong with it. I believe it would also work to modify the working copy, and then svn cp it (instead of svn committing it) - atleast the svn docs suggest that you can copy a working copy into a repo URL. 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
