Re: [Python-Dev] Should we drop active support of OSF/1?
Jesus Cea jcea.es> writes: > > Would be enough to raise an "ERROR" at configure time if OSF test is > positive?. To delete that intentional "ERROR" would be trivial. I think it's ok. Noone will probably notice anyway. Regards Antoine. ___ 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 1:36 PM, Tarek Ziadé wrote: > 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, > http://bugs.python.org/issue8604 -- Regards, Olemis. Blog ES: http://simelo-es.blogspot.com/ Blog EN: http://simelo-en.blogspot.com/ Featured article: ___ 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 May 01, 2010, at 08:58 AM, Dirkjan Ochtman wrote: >On Fri, Apr 30, 2010 at 21:09, Barry Warsaw wrote: >>>Though maybe it should be called Conclusion instead of Accepted and >>>used for Rejected PEPs, as well? >> >> Good point. What do you think about 'Resolution'? > >Fine with me. I've updated PEP 1 and the supporting scripts to accept a Resolution: header. Note that in PEP 1 I wrote: *Note: The Resolution header is required for Standards Track PEPs only. It contains a URL that should point to an email message or other web resource where the pronouncement about the PEP is made.* but in fact, the scripts make Resolution optional (it's kind of a pain to make it required just for Standards Track PEPs - contributions welcome). -Barry signature.asc Description: 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] Two small PEP ideas
On Mon, May 3, 2010 at 11:30 AM, Barry Warsaw wrote: > but in fact, the scripts make Resolution optional (it's kind of a pain to make > it required just for Standards Track PEPs - contributions welcome). It will also be a pain to retroactively update older PEPs with the newly-required metadata; leaving it optional (in practice) seems acceptable. It should only apply to newly-resolved PEPs, which is also likely a pain to build into the script. -Fred -- Fred L. Drake, Jr. "Chaos is the score upon which reality is written." --Henry Miller ___ 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 Apr 30, 2010, at 04:28 PM, Steve Holden wrote: >Martin v. Löwis wrote: >>> As to Guido's point about the decision making process, Nick's right. I just >>> want to make sure we can capture the resolution in the PEP, be it by BDFL >>> pronouncement or "hey, silence is acceptance" email. >> >> I don't think "silence is acceptance" will work out in practice. For >> issues where a PEP was written in the first place, somebody will >> *always* object, and forever so, hoping that what he considers a mistake >> will not be done. The advantage of Guido acting as BDFL was that >> somebody would make an decision ultimately, one which both proponents >> and opponents of the PEP would accept. >> >> 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? We could of course, and I would serve honorably . But Guido's not *that* much older than me, so you'd probably only get a few useful years out of me before I start getting increasingly eccentric, re-opening and approving PEPs like 313, 336, and 666. In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing the Gamut of Language Evolution. -Barry signature.asc Description: 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] Two small PEP ideas
On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote: >> 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. > >It then seems that this role should go to the release manager of the >upcoming feature release. Assuming Georg can accept this additional >responsibility. I do think it makes sense for the RM to assume these responsibilities where Guido either can't or doesn't want to make the final decision. I think it will fairly substantially increase the workload on the RM, so perhaps there are ways to off-load some of the current responsibilities (e.g. updating the website for each release). I also think that RMs should be term-limited so that we can spread more experience within the community. And past-RMs can provide a sort of consultation group where contentious decisions can be discussed and advice gathered. -Barry signature.asc Description: 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] Two small PEP ideas
On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw wrote: > On May 01, 2010, at 07:12 AM, Martin v. Löwis wrote: > >>> 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. >> >>It then seems that this role should go to the release manager of the >>upcoming feature release. Assuming Georg can accept this additional >>responsibility. > > I do think it makes sense for the RM to assume these responsibilities where > Guido either can't or doesn't want to make the final decision. I think it > will fairly substantially increase the workload on the RM, so perhaps there > are ways to off-load some of the current responsibilities (e.g. updating the > website for each release). I also think that RMs should be term-limited so > that we can spread more experience within the community. And past-RMs can > provide a sort of consultation group where contentious decisions can be > discussed and advice gathered. While I certainly won't object if a release manager volunteers to also be the final PEP arbiter, I don't want to make it a job requirement (or even an implied expectation). The responsibility of a release manager is very much in the here and now and the near future -- stability and consistency of the current release. Being PEP arbiter requires a somewhat different mindset, more focused on the long-term health of the language and its community. -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Two small PEP ideas
> In the meantime, let's groom Benjamin to be the Sacred Next Uncle Galvanizing > the Gamut of Language Evolution. I don't think anybody having such a position permanently can really work. 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] Should we drop active support of OSF/1?
Jesus Cea wrote: > 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. That's actually what the PEP suggests (or means to suggest). Users willing to take over maintenance would, at a minimum, know how to remove that error. If a user doesn't know how to remove it, they can ask for help, but more importantly, they probably consider it already unsupported - which is exactly the desired effect. Just to rephrase: the point of this deprecation cycle is to give users a chance to take over maintenance, and to declare, in public, that they are interested in that port. If nobody steps forward, we can safely assume that nobody cares. 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
2010/5/3 Guido van Rossum : > On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw wrote: >> I do think it makes sense for the RM to assume these responsibilities where >> Guido either can't or doesn't want to make the final decision. I think it >> will fairly substantially increase the workload on the RM, so perhaps there >> are ways to off-load some of the current responsibilities (e.g. updating the >> website for each release). I also think that RMs should be term-limited so >> that we can spread more experience within the community. And past-RMs can >> provide a sort of consultation group where contentious decisions can be >> discussed and advice gathered. I'm very -1 on the release manager making decisions on PEPs. The RM right now basically makes a release schedule and cuts releases. The little power he has is mostly used for rejecting features in the beta period. This task should not be politicized. -- Regards, Benjamin ___ 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
Benjamin Peterson wrote: > 2010/5/3 Guido van Rossum : >> On Mon, May 3, 2010 at 8:57 AM, Barry Warsaw wrote: >>> I do think it makes sense for the RM to assume these responsibilities where >>> Guido either can't or doesn't want to make the final decision. I think it >>> will fairly substantially increase the workload on the RM, so perhaps there >>> are ways to off-load some of the current responsibilities (e.g. updating the >>> website for each release). I also think that RMs should be term-limited so >>> that we can spread more experience within the community. And past-RMs can >>> provide a sort of consultation group where contentious decisions can be >>> discussed and advice gathered. > > I'm very -1 on the release manager making decisions on PEPs. The RM > right now basically makes a release schedule and cuts releases. The > little power he has is mostly used for rejecting features in the beta > period. This task should not be politicized. > That seems reasonable, but it also seems reasonable to try and simplify the task of updating the web site for each release. There's plenty to do without having to fight that issue too. I'm copying this message to Rich Leland, who is currently making a study of the PSF's web requirements, to make sure this gets folded in. Many of the tasks are essentially macrogeneration, and unless automated will remain error-prone. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.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] Should we drop active support of OSF/1?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/05/10 21:55, "Martin v. Löwis" wrote: > Just to rephrase: the point of this deprecation cycle is to give users a > chance to take over maintenance, and to declare, in public, that they > are interested in that port. If nobody steps forward, we can safely > assume that nobody cares. http://bugs.python.org/issue8606 . I will take care of the final cleanup in 3.3, if nobody stands up to keep OSF* alive. I am deprecating OSF*. If it is "too much", we can change it to "OSF1". - -- 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/ iQCVAwUBS99CoJlgi5GaxT1NAQLSygQAiYD0UQAKl2vv1alwmMSP02AgHxN9e3Le bfMqysr2BE9fnG3WQlUKFn6pjbnnANFU2HRhTUJkaCNslewnUeg6pQ/s0xu321GL HQ6v6JHSOXxRoyyZ21Wq2ECNg+tYWGkM7Eohsif8XMjTeL0lP7ddYZSFaJbK0PfM BSK6DAV93/o= =nlYU -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
[Python-Dev] Running Clang 2.7's static analyzer over the code base
Since 2.7 is probably going to exist for a while, I am running Clang 2.7's static analyzer (``clang --static``) over trunk. It's mostly just finding stuff like unneeded variable initialization or variables that are never used (compilation is picking up unused returned values, almost all from PyObject_INIT). When I check in these changes I will do it file by file, but my question is how to handle Misc/NEWS. I have gone through the underscores and the 'a's in Modules and already have six modified files, so the final count might be a little high. Do people want individual entries per file, or simply a single entry that lists each file modified? We should probably go through the C code and fix the whitespace before we hit 2.7 final (there is a ton of lines with extraneous spaces). -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] Running Clang 2.7's static analyzer over the code base
2010/5/3 Brett Cannon : > Since 2.7 is probably going to exist for a while, I am running Clang 2.7's > static analyzer (``clang --static``) over trunk. It's mostly just finding > stuff like unneeded variable initialization or variables that are never used > (compilation is picking up unused returned values, almost all from > PyObject_INIT). > When I check in these changes I will do it file by file, but my question is > how to handle Misc/NEWS. I have gone through the underscores and the 'a's in > Modules and already have six modified files, so the final count might be a > little high. Do people want individual entries per file, or simply a single > entry that lists each file modified? Do these changes even warrant a NEWS entry? NEWS is more for user facing changes. > We should probably go through the C code and fix the whitespace before we > hit 2.7 final (there is a ton of lines with extraneous spaces). Why? > -Brett -- Regards, Benjamin ___ 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] Running Clang 2.7's static analyzer over the code base
Benjamin Peterson python.org> writes: > > 2010/5/3 Brett Cannon python.org>: > > When I check in these changes I will do it file by file, but my question is > > how to handle Misc/NEWS. I have gone through the underscores and the 'a's in > > Modules and already have six modified files, so the final count might be a > > little high. Do people want individual entries per file, or simply a single > > entry that lists each file modified? > > Do these changes even warrant a NEWS entry? NEWS is more for user > facing changes. Indeed. At most a single NEWS entry sounds sufficient. Regards Antoine. ___ 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] Running Clang 2.7's static analyzer over the code base
I'll just do a single entry saying that the static analyzer was used and not list the files. And in reply to Benjamin's question about the whitespace, I guess it actually doesn't matter. More important to clean up in py3k. On May 3, 2010 4:00 PM, "Antoine Pitrou" wrote: Benjamin Peterson python.org> writes: > > 2010/5/3 Brett Cannon python.org>: > > When I check in these changes I will do it file by file, but my question is > > how to handle M... Indeed. At most a single NEWS entry sounds sufficient. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/brett%40python.org ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Running Clang 2.7's static analyzer over the code base
Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit : > > And in reply to Benjamin's question about the whitespace, I guess it > actually doesn't matter. More important to clean up in py3k. Would it be finally time to standardize all C files on a 4-spaces indentation rule? I understand the "svn annotate" argument, but we edit code far more often than we annotate it. Also, it seems "svn ann -x -w" would ignore whitespace changes. Regards Antoine. ___ 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] Running Clang 2.7's static analyzer over the code base
Antoine Pitrou wrote: > Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit : >> And in reply to Benjamin's question about the whitespace, I guess it >> actually doesn't matter. More important to clean up in py3k. > > Would it be finally time to standardize all C files on a 4-spaces > indentation rule? > > I understand the "svn annotate" argument, but we edit code far more often > than we annotate it. Also, it seems "svn ann -x -w" would ignore > whitespace changes. > Let's not forget to consider what Hg can do, since that represents the future. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 See PyCon Talks from Atlanta 2010 http://pycon.blip.tv/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS:http://holdenweb.eventbrite.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] Running Clang 2.7's static analyzer over the code base
On May 03, 2010, at 10:12 PM, Steve Holden wrote: >Antoine Pitrou wrote: >> Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit : >>> And in reply to Benjamin's question about the whitespace, I guess it >>> actually doesn't matter. More important to clean up in py3k. >> >> Would it be finally time to standardize all C files on a 4-spaces >> indentation rule? >> >> I understand the "svn annotate" argument, but we edit code far more often >> than we annotate it. Also, it seems "svn ann -x -w" would ignore >> whitespace changes. >> >Let's not forget to consider what Hg can do, since that represents the >future. Now would be a good time to convert the C files to 4 space indents. We've only been talking about it for a decade at least. While I'm sure history can be preserved across the svn->hg import, it's enough of a break to bite the bullet and fix the code. I think we only need to convert the py3k branch though. -Barry signature.asc Description: 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] Running Clang 2.7's static analyzer over the code base
On Mon, May 3, 2010 at 7:34 PM, Barry Warsaw wrote: > Now would be a good time to convert the C files to 4 space indents. We've > only been talking about it for a decade at least. Will changing the indentation of source files to 4 space indents break patches on the bug tracker? -- Alexandre ___ 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] Running Clang 2.7's static analyzer over the code base
> Will changing the indentation of source files to 4 space indents break > patches on the bug tracker? Plain patch will choke, but "patch -l" might accept them. I have only read the documentation, though, and don't know whether it does in practice. 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] Running Clang 2.7's static analyzer over the code base
Steve Holden wrote: > Antoine Pitrou wrote: >> Le Mon, 03 May 2010 16:11:53 -0700, Brett Cannon a écrit : >>> And in reply to Benjamin's question about the whitespace, I guess it >>> actually doesn't matter. More important to clean up in py3k. >> Would it be finally time to standardize all C files on a 4-spaces >> indentation rule? >> >> I understand the "svn annotate" argument, but we edit code far more often >> than we annotate it. Also, it seems "svn ann -x -w" would ignore >> whitespace changes. >> > Let's not forget to consider what Hg can do, since that represents the > future. I think Mercurial chokes in the light of white space inconsistencies just as much as Subversion. One reason for not converting in the past was also that it would break merging, unless that whitespace normalization is applied to all these branches. 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
[Python-Dev] Daily DMGs
David Bolen and I started producing daily OSX installers, at http://www.python.org/dev/daily-dmg/ If you find problems with these, please report them to bugs.python.org. 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
