Re: [Python-Dev] [PEP 3148] futures - execute computations asynchronously
I've updated the PEP to include: - completion callbacks (for interoperability with Twisted Deferreds) - a pointer to the discussion on stdlig-sig See: http://svn.python.org/view/peps/trunk/pep-3148.txt?r1=78618&r2=80679 Rejected ideas: - Having a registration system for executors Not yet addressed: - where the package should live (someone in a "concurrent" package seems fine) - having global executors with unbounded worker counts as a convenience [1] [1] There are a few issues with global executors that need to be thought thought through i.e. when should workers be created and when should they be terminated. I'd be happy to defer this idea unless someone is passionate about it (in which case it would be great if they'd step in with concrete ideas). Cheers, Brian___ 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] Enhanced tracker privileges for dangerjim to do triage.
>> Yes, in the last year in particular there has been some excellent effort >> of maintaining the issue tracker content. But the question still remains >> - who are we worried about offending? > The people who are potential new contributors but don't currently know > anyone in the Python community. By definition these 'potential new and unknown contributors' are discrete and probably can't be characterized as a whole. However, seeing myself as one of the discrete elements in that group, I think it's worthwhile for me to pipe in here and say that I won't be 'offended' or think of it as nepotism if someone gets foo-privilege before I do because he happens to know core developer (some other 'potential new contributer' lurking here feels otherwise? - speak up!). I don't know the community (yet) and I can't say this for sure, but my current gut feeling about the Python community (and pretty much any OSS I can think of) is that in the long run, I'll be judged on merit just like any other guy, no matter who they know. - Yaniv ___ 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] PEP or issue recording rationale for allowing multiple context managers?
I was looking for a reference for the addition of multiple context manager support to with statements in 3.1 and 2.7 and came up empty (aside from the initial python-ideas thread [1] that I linked to from PEP 377). I was hoping to find something that clearly spelled out: - the two major flaws in contextlib.nested* - the parallel with import statements for the precise chosen syntax - Guido's blessing to go ahead and do it *Those flaws being - that __init__/__new__ methods of inner context managers aren't covered by outer context managers - that outer context managers can't suppress exceptions from inner __enter__ methods Note that I'm not complaining about the decision itself (that would be silly, since I agree with the outcome), I'm just trying to find something to point to about it that is a little more concrete than a python-ideas thread. Cheers, Nick. [1] http://mail.python.org/pipermail/python-ideas/2009-March/003188.html -- 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
[Python-Dev] Alias for distutils.file_util.write_file in e.g. shutils
Hello ! Often I have the contents to be written in a file at a given path that I know as well. I recently tried to find a function in stdlib to do that and to my surprise this is what I found : - Such function exists - It's `distutils.file_util.write_file` IMO the last place where people'd look for such a function is inside `distutils` package. Besides I reviewed modules listed under `File and directory access` category in `Library Reference` and found nothing even similar. Q: - Is it a good idea to provide a similar function in e.g. shutils module ? Probably there's already a better way to do this and my comment is just irrelevant . Anyway is just a suggestion ;o) -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: Soporte para AMF (RPC) en Trac - http://feedproxy.google.com/~r/simelo-es/~3/9dYgHeK5Be8/soporte-para-amf-rpc-en-trac.html ___ 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] Alias for distutils.file_util.write_file in e.g. shutils
On Sun, May 2, 2010 at 8:15 PM, Olemis Lang wrote: > Hello ! > > Often I have the contents to be written in a file at a given path that > I know as well. I recently tried to find a function in stdlib to do > that and to my surprise this is what I found : > > - Such function exists > - It's `distutils.file_util.write_file` > > IMO the last place where people'd look for such a function is inside > `distutils` package. Besides I reviewed modules listed under `File and > directory access` category in `Library Reference` and found nothing > even similar. > > Q: > - Is it a good idea to provide a similar function in > e.g. shutils module ? A: Yes :) Basically, anything useful in distutils.file_util and distutils.dir_util can maove in Shutil. That's why I added make_archive (and unpack_archive) Please add an issue, I'll work on adding this function, Thanks Tarek -- Tarek Ziadé | http://ziade.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] Enhanced tracker privileges for dangerjim to do triage.
On Sun, 02 May 2010 22:39:01 +1000, Yaniv Aknin wrote: > >> Yes, in the last year in particular there has been some excellent effort > >> of maintaining the issue tracker content. But the question still remains > >> - who are we worried about offending? > > > The people who are potential new contributors but don't currently know > > anyone in the Python community. > > By definition these 'potential new and unknown contributors' are discrete > and probably can't be characterized as a whole. However, seeing myself > as one of the discrete elements in that group, I think it's worthwhile for me > to pipe in here and say that I won't be 'offended' or think of it as nepotism > if someone gets foo-privilege before I do because he happens to know core > developer (some other 'potential new contributer' lurking here feels > otherwise? > - speak up!). > > I don't know the community (yet) and I can't say this for sure, but my current > gut feeling about the Python community (and pretty much any OSS I can think > of) is that in the long run, I'll be judged on merit just like any other guy, > no > matter who they know. Thank you very much for this feedback. -- R. David Murray www.bitdance.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] Frequency of the dev docs autobuild
On Sun, 02 May 2010 00:44:22 +0200, =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: > R. David Murray wrote: > > On Sat, 01 May 2010 16:18:19 +0100, Paul Moore wrote: > >> On 1 May 2010 15:28, R. David Murray wrote: > >>> Unless I'm missing something, I don't see any docs there about the > >>> automated build process and when and where it runs. > >> I assume Georg was referring to "Development versions of the Python > >> documentation are available on-line and updated daily". > > > > Yes, most likely. I think I am asking for more documentation than you > > were :) > > Then I think you have to propose specific wording. It runs on > www.python.org (why would you expect it to run elsewhere???), I had in fact overlooked the indicated sentence when reading the page. It's not that I expect it to run somewhere else, but that it did indeed used to run somewhere else (if I'm reading the build.sh script correctly), so I think it is worth making it explicit. Also note that it isn't obvious (without resolving the host names) that docs.python.org and www.python.org are the same machine. > and what about "daily" do you consider imprecise? Do you really need > exact hour, minute, and second? What for? I wasn't asking for more precision than daily (I just hadn't seen it), but now that I think about it it would indeed be nice to know when the cron job starts, so that we know that if the checkin didn't happen before then, it won't show up in the online docs until the next day. I don't think this is particularly *important* to know, it would just be nice to know. Is it only the development versions that get updated, or do our updates to the next bug fix release also get posted daily (and those are the docs web site visitors normally see, I believe)? I was under the impression that it was the latter, but that Georg had also changed things so that a reference to a particular dot release got the snapshot of the docs that were shipped with that dot release. This impression seems to be confirmed by examination of the various pages involved. To answer your question about what wording I'd like, I think that it would be worthwhile to say somewhere (not necessarily on that page...maybe in the doc README.txt?...but it could be ont that page...) that the docs are auto-built by a cron job on the server hosting docs.python.org running 'make dist' in the doc directory of a freshly updated checkout and thendoing something with the resulting files? Or maybe the apache URLs point right at the dist directory in that autobuild checkout? Anyway, exactly how it all works is what I would like to see documented. Background: one of my tasks for one of my customers is helping them try to make it so that an outsider coming in could learn everything they needed to know to operate the system from the available docs...a goal that they are nowhere near achieving, but which I think is a worthwhile goal for which to strive. -- R. David Murray www.bitdance.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] Frequency of the dev docs autobuild
> I wasn't asking for more precision than daily (I just hadn't seen it), but > now that I think about it it would indeed be nice to know when the cron > job starts, so that we know that if the checkin didn't happen before then, > it won't show up in the online docs until the next day. I don't think > this is particularly *important* to know, it would just be nice to know. That's different from asking that it be documented, though. I don't mind you knowing (it's at 15:00 local time for the build machine, which sits in the Europe/Amsterdam timezone). Just ask specific questions, and people may give specific answers. Now that you know, I still don't think it needs to be documented (else: where would that end? Would you want to know account name and uid of the build also, and the partition of the hard disk where the files are stored? Not even I know the rack slot in which the machine sits). > > Is it only the development versions that get updated, or do our updates > to the next bug fix release also get posted daily (and those are the docs > web site visitors normally see, I believe)? That's what the documentation claims, yes. The build script currently has these targets: BRANCHES = [ # checkout, target, isdev (BUILDROOT + '/python26', WWWROOT, False), (BUILDROOT + '/python31', WWWROOT + '/py3k', False), (BUILDROOT + '/python27', WWWROOT + '/dev', True), (BUILDROOT + '/python32', WWWROOT + '/dev/py3k', True), ] > To answer your question about what wording I'd like, I think that it would > be worthwhile to say somewhere (not necessarily on that page...maybe in > the doc README.txt?...but it could be ont that page...) that the docs are > auto-built by a cron job on the server hosting docs.python.org running > 'make dist' in the doc directory of a freshly updated checkout and > thendoing something with the resulting files? Actually, the command is rather like this: 'cd Doc; make autobuild-%s' % (isdev and 'dev' or 'stable') > Background: one of my tasks for one of my customers is helping them try to > make it so that an outsider coming in could learn everything they needed > to know to operate the system from the available docs...a goal that they > are nowhere near achieving, but which I think is a worthwhile goal for > which to strive. For this kind of work, I think looking at the actual installation is more productive to learn how things are done (perhaps opposed to how they were originally planned to be done). I didn't know how this all worked myself, either, but, using the root account, it took me only a minute to find out - much faster than finding the documentation that may have explained it in detail. The only starting point that you need is the machine that you know it runs on. 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] Two small PEP ideas
On Sat, May 1, 2010 at 02:00, Tarek Ziadé wrote: > On Fri, Apr 30, 2010 at 11:25 PM, Guido van Rossum > wrote: > [..] > >>> > >>> Without a BDFL, I think we need a committee to make decisions, e.g. by > >>> majority vote amongst committers. > >> > >> Couldn't we just go with the FLUFL? > > > > IIRC in the IETF this is done by the committee chair. I think it's a > > good idea to have this be a single person to avoid endless indecision. > > BPD = Benevolent Pep Dictator > BPC = Benevolent Pep Caliph (sounds good in French, not sure in English > ;) ) > > What about naming several BPD + and have one BPC elected each year by > all the core devs ? > > == BPD == > > I am not sure if this would work for all areas in Python-core, but > looking at the maintainers.rst file, it looks like we could name for > example Brett for all the import machinery things, Marc-André for all > the unicode things, I could be the one about packaging, etc. > > If we could manage to split the python-core development into > categories, and add these categories in the PEP metadata, that would > define who takes the final decision in case we can't reach consensus. > This sounds like the lieutenant setup they have for the Linux kernel. I have no clue how that works out for them. > > == BPC == > > Of course some PEPs could concern several categories, so we would > still need some kind of Pep dictator if there's no consensus. So what > about electing a BPC every year ? > So there is a "single voice" issue here (that also applies to Martin's idea of having the release manager make the call as that is a rotating position). One of the reasons, I think, the BDFL style of decision making has worked out is that it lets Guido keep Python consistent; the language is always striving to meet his mental model of the language more and more. Having this rotate amongst us will not allow us to have this benefit. It also raises the chance of arguing over who takes over the rotating position and that just falls down into the hellish hole of politics that I don't think any of us want to see happen. But even ignoring my worry/point, what are we even discussing here? Guido has said multiple time he is not retiring, simply scaling back his involvement. So are we trying to figure out how to make our own decisions about Python when Guido is not available to make one or simply doesn't care enough to pronounce? If that's the case then we should probably choose a vice BDFL (sort of a Benevolent Dicatator at Guido's Discretion) to keep the voice of Python as uniform as possible. I guess this person would become the assumed successor of the BDFL title if Guido ever does retire and the decision is made to continue on with active development of the language instead of just going into maintenance mode, but hopefully that problem will be a long ways off. If we are discussing something else, then I don't know what we are all talking about here other than measurements of standard pieces of wood. =) -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] Frequency of the dev docs autobuild
Am 02.05.2010 22:21, schrieb R. David Murray: > On Sun, 02 May 2010 00:44:22 +0200, > =?ISO-8859-1?Q?=22Martin_v=2E_L=F6wis=22?= wrote: >> R. David Murray wrote: >> > On Sat, 01 May 2010 16:18:19 +0100, Paul Moore wrote: >> >> On 1 May 2010 15:28, R. David Murray wrote: >> >>> Unless I'm missing something, I don't see any docs there about the >> >>> automated build process and when and where it runs. >> >> I assume Georg was referring to "Development versions of the Python >> >> documentation are available on-line and updated daily". >> > >> > Yes, most likely. I think I am asking for more documentation than you >> > were :) >> >> Then I think you have to propose specific wording. It runs on >> www.python.org (why would you expect it to run elsewhere???), > > I had in fact overlooked the indicated sentence when reading the page. And I realize it's less than you wanted to see :) But I also realized it's very easy to give more detail without crowding that page; since the script used for the daily build is in SVN under Doc/tools/dailybuild.py; and that also contains the hostname. I've updated the dev/doc/ page to include a link to the script text. cheers, Georg ___ 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] Should we drop active support of OSF/1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 26/04/10 22:00, "Martin v. Löwis" wrote: >> Maybe we can drop OSF/1 safely supporting Tru64 yet, but we don't have >> any buildbot running any of this systems... > > Dropping support is fine with me, in the long term. If PEP 11 is truly > followed, we should deprecate support in one version, and drop it in the > next one. This would mean we add a easy-to-remove configure error in > 3.2, and remove the support in 3.3. Would be enough to raise an "ERROR" at configure time if OSF test is positive?. To delete that intentional "ERROR" would be trivial. In 3.3 I would remove the configure tests and the "#if" conditional compilation related to them. - -- Jesus Cea Avion _/_/ _/_/_/_/_/_/ [email protected] - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/ jabber / xmpp:[email protected] _/_/_/_/ _/_/_/_/_/ . _/_/ _/_/_/_/ _/_/ _/_/ "Things are not so easy" _/_/ _/_/_/_/ _/_/_/_/ _/_/ "My name is Dump, Core Dump" _/_/_/_/_/_/ _/_/ _/_/ "El amor es poner tu felicidad en la felicidad de otro" - Leibniz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQCVAwUBS95XyJlgi5GaxT1NAQLQLQP/cE2E27g8hSAbH7XzewDDYzx1AZ11ja55 xuR0PLTg/yQgE+4oifMa56Rs54YVRtRkh+i7B5yR5+lcI2DJgfqiu2Q9Of8KbwHp SQ2BVlshUmjhImWh486Qj6aQ9sF3xMdaxOGVLG+SJOBAEVw4UWEkZYPpQOuKRTfG K0SYYLhERoY= =CUNo -END PGP SIGNATURE- ___ 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] Should we drop active support of OSF/1?
On Mon, May 3, 2010 at 06:57, Jesus Cea wrote: > Would be enough to raise an "ERROR" at configure time if OSF test is > positive?. To delete that intentional "ERROR" would be trivial. Oh really? I have no clue of how to do that. Doesn't like like a good deprecation to me. :) Is printing a warning not easily feasible in ./configure? -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ 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
