Re: [Python-Dev] Looking after the buildbots (in general)
On Wed, Aug 04, 2010 at 07:26:06PM -0400, Barry Warsaw wrote: > On Aug 04, 2010, at 06:39 PM, Steve Holden wrote: > >I'll see if I can get God to extend it for you. > > No need to involve the supernatural Steve! Just approve that PSF grant I > submitted so I can finish my (Python powered of course!) clone army. Someone else got there ahead of you... http://en.wikipedia.org/wiki/MASSIVE_%28software%29 ___ 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] barry_as_FLUFL
Barry Warsaw wrote: Wait. It's a joke?! Probably, but it's also useful behaviour -- I hope it stays! (Not that I would ever presume to use it in any code inflicted on anyone else, but it's nice to know I have a choice in the privacy of my own computer.) Heil-the-FLUFl-ly, Greg ___ 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] Looking after the buildbots (in general)
On 8/5/2010 2:19 AM, Georg Brandl wrote: > Am 05.08.2010 01:26, schrieb Barry Warsaw: >> On Aug 04, 2010, at 06:39 PM, Steve Holden wrote: >> >>> I'll see if I can get God to extend it for you. >> >> No need to involve the supernatural Steve! Just approve that PSF grant I >> submitted so I can finish my (Python powered of course!) clone army. > > *Now* I know why the PSU abducted all these developers! To assemble > a sufficient gene pool... > >>> I honestly do understand that everyone else works under the same >>> restrictions >>> of time that I do ... and I appreciate all the hard work the release >>> managers >>> continue to put in. >> >> We know you love us Steve. :) > > In a PHBy way, it seems :) > I'd have thought a pre-requisite for being a PHB was having hair. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] OT: PHB (was: Looking after the buildbots)
On Thu, Aug 05, 2010 at 07:49:31AM -0400, Steve Holden wrote: > I'd have thought a pre-requisite for being a PHB was having hair. Not at all, not at all - being a PHB is a style of thinking, not hairdressing. ;) Oleg. -- Oleg Broytmanhttp://phd.pp.ru/[email protected] Programmers don't die, they just GOSUB without RETURN. ___ 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] OT: PHB
On 8/5/2010 8:12 AM, Oleg Broytman wrote: > On Thu, Aug 05, 2010 at 07:49:31AM -0400, Steve Holden wrote: >> I'd have thought a pre-requisite for being a PHB was having hair. > >Not at all, not at all - being a PHB is a style of thinking, not > hairdressing. ;) > I was simply trying to avoid becoming "The Python PHB" in the folklore. Sadly I see it is now inevitable - thanks, Georg ;-) regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 DjangoCon US September 7-9, 2010http://djangocon.us/ See Python Video! http://python.mirocommunity.org/ Holden Web LLC http://www.holdenweb.com/ ___ 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] #2651 - KeyError does not round trip strings
2010/8/5 Fred Drake : > 2010/8/4 Łukasz Langa : >> Shall we do an e.index for IndexErrors as well? > > I don't recall stumbling over that need, but the parallel makes it > tempting. I expect is should be a separate patch, though. > > Antoine's right about using keyword args from C, though. I'd expect a > new helper function that handles this specific case, since it's likely > to be common. Whether it used a keyword are or just performed a > setattr after the exception is created doesn't really matter. Yeah, helper functions for C code that accepted the extra arguments would do the trick. I actually had a look to see what IOError does with its attributes and I think it qualifies as being a little on the special side (replicated in both 2.6 and the py3k branch): >>> io1 = IOError(1) >>> io2 = IOError(1, 2) >>> io3 = IOError(1, 2, 3) >>> io4 = IOError(1, 2, 3, 4) >>> io1, io2, io3, io4 (IOError(1,), IOError(1, 2), IOError(1, 2), IOError(1, 2, 3, 4)) >>> io1.errno, io2.errno, io3.errno, io4.errno (None, 1, 1, None) >>> io1.strerror, io2.strerror, io3.strerror, io4.strerror (None, 2, 2, None) >>> io1.filename, io2.filename, io3.filename, io4.filename (None, None, 3, None) One argument = no attributes set Two arguments = errno, strerror set (including if second argument is explicitly None) Three arguments = errno, strerror, filename set Four or more arguments = no attributes set Keyword arguments are not supported by IOError (or EnvironmentError, which is where the above behaviour is actually implemented). That precedent would deem it acceptable to adopt a backwards compatible protocol that still allowed arbitrary positional arguments for Key/Attribute/IndexError, but treated the 2 argument case specially. However, the IOError behaviour really doesn't strike me as a particularly good example for us to be following, so PEP 3151 may want to consider the issue of tidying up those exception signatures. The "right" way to go still appears to be to allow arbitrary positional arguments (which go into .args) for backwards compatibility, then add appropriate keyword-only arguments. IOError could get some keyword only arguments as well, retaining the somewhat odd behaviour above for backwards compatibility reasons (although the repr in the 3 argument case should be fixed). Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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] PEP 376 proposed changes for basic plugins support
Hello Le 03/08/2010 13:09, Michael Foord a écrit : > On 03/08/2010 09:28, M.-A. Lemburg wrote: >> P.J. Eby wrote: >>> At 10:37 PM 8/2/2010 +0200, M.-A. Lemburg wrote: > [idea about sqlite3 db for caching] [distros won’t like it, the filesystem is the db] >>> [the db is a cache, it does not replace the files] >> [advantages of sqlite3 db] > Sounds good as an "optional extra" (i.e. it should be safe to completely > delete the cache file and still have everything work) to me. If the API > for using the feature is worked out well first this could be done as a > behind the scenes optimisation... FYI, the current implementation in the distutils2-augmented pkgutil uses a cache (a function call memo) for functions that e.g. iterate over dist-info directories (and optionally egg-info directories too) or get a Distribution object representing an installed project. Tools that modify the state of the installation can call a function to clear this cache. A sqlite db would certainly speed things up; it could replace the existing caching in distutils2 or be left to other tools. Regards ___ 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] barry_as_FLUFL
Hi, I just read an interesting article (interview with Fred Brooks). See: http://www.informit.com/articles/article.aspx?p=1600886 Eoin: The book contains a lot of explicit and implicit advice for those who must manage design projects. What would your top three pieces of advice for such managers be? Fred: 1. Choose a chief designer separate from the manager and give him authority over the design and your trust. 2. Plan for the iterative discovery and screening of requirements. 3. Prototype (or simulate with models, etc.) early and get real user feedback on real use scenarios early and often. I immediately thought of the Python "process" as a real life example of this working! Fortunately too, the "crop" of "manager"s is also growing! Congratulations to all that have been part of this process!! Cheers, --ldl On Thu, Aug 5, 2010 at 4:22 AM, Greg Ewing wrote: > Barry Warsaw wrote: > >> Wait. It's a joke?! > > Probably, but it's also useful behaviour -- I hope > it stays! > > (Not that I would ever presume to use it in any > code inflicted on anyone else, but it's nice to > know I have a choice in the privacy of my own > computer.) > > Heil-the-FLUFl-ly, > Greg > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/ldlandis%40gmail.com > -- --- NOTE: If it is important CALL ME - I may miss email, which I do NOT normally check on weekends nor on a regular basis during any other day. --- LD Landis - N0YRQ - de la tierra del encanto 3960 Schooner Loop, Las Cruces, NM 88012 575-448-1763 N32 21'48.28" W106 46'5.80" ___ 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] barry_as_FLUFL
On Fri, Aug 6, 2010 at 2:25 AM, LD 'Gus' Landis wrote: > Hi, > > I just read an interesting article (interview with Fred Brooks). > See: http://www.informit.com/articles/article.aspx?p=1600886 > > Eoin: The book contains a lot of explicit and implicit advice for those > who must manage design projects. What would your top three pieces > of advice for such managers be? > > Fred: > 1. Choose a chief designer separate from the manager and give him > authority over the design and your trust. > 2. Plan for the iterative discovery and screening of requirements. > 3. Prototype (or simulate with models, etc.) early and get real user > feedback on real use scenarios early and often. > > I immediately thought of the Python "process" as a real life example > of this working! Fortunately too, the "crop" of "manager"s is also > growing! There's actually quite a lot open source and proprietary development in general can learn from each other, but the fact that so many open source developers *aren'* getting paid means that garbage that is tolerated in a proprietary setting doesn't happen as much in open source. One random thing: the knowledge that your commits are going to be broadcast immediately to anyone that is interested, as well as archived permanently on the world wide web is a powerful incentive to: a) write good code b) comment anything that is hackish/tremendously complicated c) write decent checkin messages Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ 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
