Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
Tim Peters wrote: That would be great. A dupe of WinXP would also be great: I'm not going to keep my buildbot slave up all the time, or anywhere near all the time. It seems like the buildbot needs even more hand-holding on Windows: it apparently doesn't survive a master stop/start cycle. While the Unix buildbots reconnect, the Windows one doesn't. 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] Developing/patching ctypes
Thomas Wouters wrote: On 3/10/06, Martin v. Löwis [EMAIL PROTECTED] wrote: Thomas Heller wrote: BTW: The buildbot reports ctypes test failures on the gentoo amd64 machine: http://www.python.org/dev/buildbot/trunk/amd64%20gentoo%20trunk/builds/277/step-test/0 Is there a way to get the actual failures somehow? They are now in http://www.python.org/dev/buildbot/all/amd64%20gentoo%20trunk/builds/280/step-test/0 I suspect that some of those failures probably aren't ctypes failures, but re-running-ctype-tests-in-the-same-process failures (like the very first one) -- I get more errors when running -R:: than I do when running the test verbosely directly. I can reproduce that now - thanks for finding the problem. IMO, some of the ctypes tests are kind-of broken, since they keep state although they should not. Maybe re-running the test could be done in a freshly spawned Python? I'll try to fix the ctypes-tests starting on Monday, so I assume that would not be necessary. Thomas ___ 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] decorator module patch
Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Please review! Cheers, Georg ___ 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] decorator module patch
Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Given that @decorator is a definition time only operation to modify a function's __name__, __doc__ and __dict__ attributes, and doesn't actually introduce any extra levels of run-time nesting to function calls, I'm not clear on why you bothered with a hybrid implementation instead of sticking with pure Python. (To clarify what I mean: using the example in the doc patch, the extra layer of run-time nesting from @decorator's wrapper function applies only to the @logged decorator, not to the function 'print_nested'. If an application has a decorated function definition in a performance critical path, a little bit of extra overhead from @decorator is the least of its worries.) Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Regards, 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] decorator module patch
Nick Coghlan wrote: Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. Sorry, I forgot the initial comment which was meant to be Thanks for moving this proposal forward :) It's currently all too easy to write decorators that don't play nicely with introspection. 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] decorator module patch
Nick Coghlan wrote: Georg Brandl wrote: Hi, to underlay my proposals with facts, I've written a simple decorator module containing at the moment only the decorator decorator. http://python.org/sf/1448297 It is implemented as a C extension module _decorator which contains the decorator object (modelled after the functional.partial object) and a Lib/decorator.py to allow further decorators added as Python code. Comes with docs and unit test. Given that @decorator is a definition time only operation to modify a function's __name__, __doc__ and __dict__ attributes, and doesn't actually introduce any extra levels of run-time nesting to function calls, I'm not clear on why you bothered with a hybrid implementation instead of sticking with pure Python. Good question... partly because I wanted to make myself more intimate with the C API and extension modules. Everyone can write that in Python... wink (To clarify what I mean: using the example in the doc patch, the extra layer of run-time nesting from @decorator's wrapper function applies only to the @logged decorator, not to the function 'print_nested'. If an application has a decorated function definition in a performance critical path, a little bit of extra overhead from @decorator is the least of its worries.) Right. I'm not opposed to a Python-only module, I've had my fun :) Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. I thought about decorators too, that would make decorators.decorator. Hm. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Depends on what else will end up there. If it's memoize or deprecated then the name functools doesn't sound too good either. Georg ___ 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] str.count is slow
Hi Ben, On Mon, Feb 27, 2006 at 06:50:28PM -0500, Ben Cartwright wrote: It seems to me that str.count is awfully slow. Is there some reason for this? stringobject.c could do with a good clean-up. It contains very similar algorithms multiple times, in slightly different styles and with different performance characteristics. If I find some motivation I'll try to come up with a patch. 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] Making staticmethod objects callable?
Hi Nicolas, On Thu, Mar 02, 2006 at 01:55:03AM -0500, Nicolas Fleury wrote: (...) A use case is not hard to imagine, especially a private static method called only to build a class attribute. Uh. I do this all the time, and the answer is simply: don't make that a staticmethod. Staticmethods are for the rare case where you need dynamic class-based dispatch but don't have an instance around. class A: def _myinitializer(): do strange stuff here _myinitializer() del _myinitializer # optional 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] Making staticmethod objects callable?
On 3/12/06, Armin Rigo [EMAIL PROTECTED] wrote: Staticmethods are for the rare case where you needdynamic class-based dispatch but don't have an instance around.Actually, I would argue that's what classmethods are for, not staticmethods. You may not envision a desire for having the class in the method right now, but it won't hurt, either. The only real use-case for staticmethods that I know of is one Jp Caldrone pointed out once: storing arbitrary callables as class attributes: class MailHandleThingy(object): sendmail = mymaillib.mailsend ...Without wrapping that in a staticmethod, 'sendmail' may or may not become a bound method -- and that might change without touching any of the MailHandleThingy code. All cases where the callable is under your direct control, it's more rewarding (same buck, way more bang) to use classmethods, IMHO.(And no, calling a function during class-definition isn't a usecase for staticmethods :) -- 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] PythonCore\CurrentVersion
Tim Peters wrote: I believe I documented it many moons ago. I don't think CurrentVersion was ever implemented (or possibly was for a very short time before being removed). The registered modules concept was misguided and AFAIK is not used by anyone - IMO it should be deprecated (if not just removed!). Further, I believe the documentation in the file for PYTHONPATH is, as said in those docs, out of date, but that the comments in getpathp.c are correct. It would be good to update that web page ;-) I have since done that: http://www.python.org/windows/registry.html Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Still looking for volunteer to run Windows buildbot
[Martin v. Löwis] It seems like the buildbot needs even more hand-holding on Windows: it apparently doesn't survive a master stop/start cycle. While the Unix buildbots reconnect, the Windows one doesn't. What makes us believe that? My box was hibernating from 03:12 to 11:54 EST today, and couldn't have responded to anything during that period. When I woke the box up, I was pleased to see that Twisted figured out that it hadn't heard from the master in 8+ hours, and established a new connection, all by itself. OTOH, I see the new connection soon got wedged all by itself too ;-), while running trunk tests just now. ___ 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] Still looking for volunteer to run Windows buildbot
Tim Peters wrote: It seems like the buildbot needs even more hand-holding on Windows: it apparently doesn't survive a master stop/start cycle. While the Unix buildbots reconnect, the Windows one doesn't. What makes us believe that? The slave was reported as idle just before I restarted the master, and offline after the restart. From that, I inferred that the restart broke the connection. My box was hibernating from 03:12 to 11:54 EST today, and couldn't have responded to anything during that period. I see. So it is rather that the master doesn't see the slaves go away. 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] decorator module patch
Georg Brandl wrote: Also, I thought we were trying to move away from modules that shared a name with one of their public functions or classes. As it is, I'm not even sure that a name like decorator gives the right emphasis. I thought about decorators too, that would make decorators.decorator. Hm. I personally like pluralized modules for exactly the reason that they don't clash as much with members or likely local variables. datetime.datetime frequently leads me to make mistakes. In general, decorators belong in the appropriate domain-specific module (similar to context managers). In this case, though, the domain is the manipulation of Python functions - maybe the module should be called metafunctions or functools to reflect its application domain, rather than the coincidental fact that its first member happens to be a decorator. Depends on what else will end up there. If it's memoize or deprecated then the name functools doesn't sound too good either. memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. -- Ian Bicking | [EMAIL PROTECTED] | http://blog.ianbicking.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] conditional expressions - add parens?
On 3/11/06, Joe Smith [EMAIL PROTECTED] wrote: Well the original was almost certainly a tongue-in-cheek reference to LISP. LISP was a disaster to use, so I doubt your language would have been any worse. The way one identifies a lisp programmer is to find the person whose paren keys have worn competely off their keyboard. :D Given how much Python is indebted to Lisp, digs at Lisp seem particularly off-topic for this list. Fully expecting this to bounce, -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module patch
On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... Alex ___ 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] decorator module patch
[Ian Bicking] memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. [Alex] Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... +1 on putting the tools all in one module. With respect to decorator entries, I would like to see python-dev collectively decide to show restraint. There are so many ways to write and use decorators that best-of-the-best are not yet obvious. Hopefully, collections of decorators will be allowed to grow-in-the-wild as recipes and as third-party modules before being put into the core. Georg's proposal seems like a good candidate for a first entry -- its chief virtue being that it may help people avoid writing crummy decorators. If his goes in, hopefully it will not fall down a slippery slope and trigger an avalance of immature decorators being added to the core. my-two-cents, Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module patch
Alex Martelli wrote: On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). On the question of whether or not deprecated fits in as a function tool, I know I'd tend to only use it on functions (to deprecate a class, I'd simply decorate the class's __init__ or __new__ method). Regards, 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] decorator module patch
[Nick Coghlan] I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). I like functools for a different reason -- the name is sufficiently broad so that we don't have fret about whether a particular tool fits within the module's scope. In contrast, a name like functional suggests that some of these tools don't quite fit. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Making builtins more efficient
Guido van Rossum wrote: I don't see why everything that doesn't make sense to be shadowed ought to become a keyword. That wasn't the reason. I was thinking it would be nice if one could use True and False instead of 1 and 0 in the knowledge that it wasn't costing a couple of dictionary lookups. However, if a more general way is found of optimising global lookups, this may become a non-issue. Greg ___ 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] Making builtins more efficient
Steven Elliott wrote: a pyc file referencing a global in a module may have been compiled with a different version of that module (that is some_module.some_global can't compiled to single fixed index since stuff may shift around in some_module). Not sure I quite follow that. Since the code in the .pyc file is what sets the module up in the first place, it can set up the array to suit its own use of global symbols. The only way this could go wrong was if you extracted the code out of a function compiled for one module and surgically implanted it in another, but if you're hacking at that level you deserve what you get. I think it's actually possible to combine all the ideas suggested so far. Builtins are assigned predefined indexes for a particular bytecode version, and each module assigns indexes its own way for other globals it uses. Builtins can have dedicated opcodes which perform a fast check for shadowing in the module and builtin arrays. Everything goes as fast as possible while still allowing anything to be overridden. Greg ___ 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] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] Setup is hellish, Agreed, though I have everything going with my own testing buildbot master (everything for the trunk build that is). My only remaining problem is that I can't connect to python.org's master. (Following up with Martin.) The second-worst part was figuring out which parts of various software docs could be ignored. :) Did you apply the Berkeley DB patches to your db-4.2.52 sources? I recorded all that remained here: http://wiki.python.org/moin/BuilbotOnWindows correction for others: http://wiki.python.org/moin/BuildbotOnWindows x86 XP-2 trunk. I'd still like to give it a go. The machine I'd use (initially at least) would be Win2k -- so not just a dupe of Tim's WinXP box. That would be great. A dupe of WinXP would also be great: I'm not going to keep my buildbot slave up all the time, or anywhere near all the time. I'm worried about the load this is going to cause on this machine with a new build for every checkin (granted they are serialized so not for *every* checkin). The full (doubled) test suite takes a *long* time to run on Windows. It looks like it took about 25 minutes on your box. It is taking over 40 minutes on one of my machines here. :( This Windows box needs an enema. Remaining TODOs: - get connection to python.org master working - make sure the python24-maint branch one works - see about the load issue - get the build slaves running as a Windows service - update PCbuild/readme.txt 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] conditional expressions - add parens?
Joe Smith wrote: LISP was a disaster to use, so I doubt your language would have been any worse. At least Lisp would let you say (* 4 a c) and not force you to write (* (* 4 a) c) My language would not have been so forgiving, unless you were willing to define a bunch of different * functions with different numbers of parameters. BTW, I did use Lisp and Scheme fairly heavily for a period, and didn't find them to be disasters -- at least not because of the parens. Greg ___ 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] decorator module patch
Nick Coghlan wrote: Alex Martelli wrote: On Mar 12, 2006, at 11:16 AM, Ian Bicking wrote: ... memoize seems to fit into functools fairly well, though deprecated not so much. functools is similarly named to itertools, another module that is kind of vague in scope (though functools is much more vague). partial would make just as much sense in functools as in functional. Couldn't we merge functools and functional into just one (user- visible) module? The distinction between what goes into one vs the other is exceedingly subtle and poor users will be guessing as to what's where. If we need a mixed module with something in C and something in Python, we can do it the usual way, func.py wrapping _func.pyd (or .so or whatever)... I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). +1 from me. I'll happily make the according changes if that reaches a consensus. On the question of whether or not deprecated fits in as a function tool, I know I'd tend to only use it on functions (to deprecate a class, I'd simply decorate the class's __init__ or __new__ method). I suppose it would be okay, since as a decorator it can only be applied to functions. In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Cheers, Georg ___ 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] decorator module patch
In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Restraint please. Go easy on the decorator additions. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] decorator module patch
On 3/12/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Nick Coghlan] I agree it makes sense to have decorator, memoize, deprecated and partial all being members of the same module, whether the name be functools or functional (although I have a slight preference for functools due to the parallel with itertools). I like functools for a different reason -- the name is sufficiently broad so that we don't have fret about whether a particular tool fits within the module's scope. In contrast, a name like functional suggests that some of these tools don't quite fit. FWIW, +1 here. Especially if we're only going to add two functions -- ``partial``, which is already accepted, and Georg's ``decorator`` -- it seems like overkill to introduce a module for each. I agree that functools is a better module name if both ``partial`` and ``decorator`` are going in there. STeVe -- Grammar am for people who can't think for myself. --- Bucky Katt, Get Fuzzy ___ 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] Still looking for volunteer to run Windows buildbot
[Tim Peters wrote] Setup is hellish Any objections to: Index: Tools/buildbot/build.bat === --- build.bat (revision 42982) +++ build.bat (working copy) @@ -1,3 +1,3 @@ @rem Used by the buildbot compile step. call %VS71COMNTOOLS%vsvars32.bat -devenv.com /build Debug PCbuild\pcbuild.sln +devenv.com /useenv /build Debug PCbuild\pcbuild.sln Adding the /useenv means that one's PATH actually gets through. This is important for the _ssl.vproj build. It calls build_ssl.py which tries to find a Perl to use. Without /useenv Visual Studio is getting a PATH from somewhere else (presumably from its internal environment configuration). The result is that build_ssl.py fallsback to its well-known locations for a Perl install. On one mahcine I was trying this on I didn't have Perl installed to C:\Perl but to C:\Perl58. People who install to an alternate drive might also get surprised. 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] Making builtins more efficient
Steven Elliott wrote: The important difference between builtins and globals is that with builtins both the compiler and the runtime can enumerate all references to builtins in a single consistent way. That is True can always be builtin #3 and len can always be builtin #17, or whatever. __slots__ for modules? Tim Delaney ___ 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] Still looking for volunteer to run Windows buildbot
Trent Mick wrote: Adding the /useenv means that one's PATH actually gets through. This is important for the _ssl.vproj build. It calls build_ssl.py which tries to find a Perl to use. Without /useenv Visual Studio is getting a PATH from somewhere else (presumably from its internal environment configuration). The result is that build_ssl.py fallsback to its well-known locations for a Perl install. Go ahead. The above makes a good check-in message. 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] Still looking for volunteer to run Windows buildbot
[Tim] Setup is hellish, [Trent] Agreed, though I have everything going with my own testing buildbot master (everything for the trunk build that is). My only remaining problem is that I can't connect to python.org's master. (Following up with Martin.) Looks like that got fixed. The second-worst part was figuring out which parts of various software docs could be ignored. :) Did you apply the Berkeley DB patches to your db-4.2.52 sources? Ah, _which_ patches? As with my buildbot Wiki page, I write down everything I do if there's a good chance I may need to do it again. So, e.g., these are my words in PCbuild\readme.txt: As of 11-Apr-2004, you also need to download and manually apply two patches before proceeding (and the sleepycat download page tells you about this). Cygwin patch worked for me. cd to dist\db-4.2.52 and use patch -p0 patchfile once for each downloaded patchfile. It's possible that there are more patches needed since then, but if so I wouldn't know about that (last time I built the externals in the _bsddb part was indeed 11-Apr-2004). This touches on something we (including Martin) should think about: it's very painful to build a full Python on Windows because of these external packages, each with its own unique and involved compile dance, and I expect it's a _huge_ barrier for getting Windows buildbot volunteers. You have to do real, messy, tedious work to get beyond this part. Something we might be able to do instead is have just one person per external project endure the pain of building it, and then have them check in the whole post-compilation post-test project directory tree. Everyone else (presumably including Windows buildbot slaves) using the same compiler could then just check out the result. I recorded all that remained here: http://wiki.python.org/moin/BuilbotOnWindows correction for others: http://wiki.python.org/moin/BuildbotOnWindows The URL I gave was correct at the time I sent it ;-) You're right that I renamed the page later, and good eye! I'm worried about the load this is going to cause on this machine with a new build for every checkin (granted they are serialized so not for *every* checkin). The full (doubled) test suite takes a *long* time to run on Windows. It looks like it took about 25 minutes on your box. It is taking over 40 minutes on one of my machines here. :( This Windows box needs an enema. Its current second test run is pretty pointless. Would be fine by me if we changed test.bat from call rt.bat -d -uall -rw to call rt.bat -d -q -uall -rw -q would cause it to run the tests only once. What's worse is when checkins cause both trunk and branch rebuilds. That can bring my zippy box to its knees, particularly when two of the disk-intensive tests (like test_largefile) run at the same time. Remaining TODOs: - get connection to python.org master working - make sure the python24-maint branch one works Works for me, although (as the Wiki page says) you also need to copy zlib-1.2.3 into the branch build area. - see about the load issue - get the build slaves running as a Windows service Mark Hammond has a patch to the buildbot project toward this end: http://sf.net/tracker/index.php?func=detailaid=1401121group_id=73177atid=537003 - update PCbuild/readme.txt Anything in particular need changing there? ___ 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] decorator module patch
Raymond Hettinger wrote: In PEP 356, there is even a suggestion to add builtin @deprecated decorator?. Restraint please. Well, that sentence wasn't meant in the sense of we should add it but in the sense of why shouldn't we put it in functools _if_ we add it, when it's even suggested as a builtin ;) Georg ___ 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
