[Python-Dev] Fwd: broken mailing list links in PEP(s?)
Hello all, It looks like the changes to the python-dev mailman archives broke some of the links in PEPs. All the best, Michael Foord Original Message Subject:broken mailing list links in PEP(s?) Date: Tue, 4 May 2010 20:22:57 -0700 From: Bayle Shanks To: [email protected] On http://www.python.org/dev/peps/pep-0225/ , in the section "Credits and archives", there are a bunch of links like http://mail.python.org/pipermail/python-list/2000-July/108893.html which are broken thanks, bayle ___ 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] Fwd: broken mailing list links in PEP(s?)
On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote: > http://mail.python.org/pipermail/python-list/2000-July/108893.html > > which are broken Pipermail's links aren't stable AFAIU. The numbering is changing over time. 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] Two small PEP ideas
Georg Brandl wrote: > I agree, and I wouldn't want to make these decisions. That person (or > group) needs to have some weight in the community, or there will be a > feeling of "... and who is he to decide anyway". We haven't emphasized > RMship in the past; it's not a special position, except when something > about a release goes wrong and blame must be placed ;) I think, being > Guido, you are still the best single person to do this job. Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a..."). I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in. That said, this is hopefully something that we won't have to worry about for real until some time well into the future when Guido decides he wants to retire. Regards, 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] Fwd: broken mailing list links in PEP(s?)
Oleg Broytman wrote: > On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote: >> http://mail.python.org/pipermail/python-list/2000-July/108893.html >> >> which are broken > >Pipermail's links aren't stable AFAIU. The numbering is changing over > time. I don't think that's true in general. I do recall the archive getting FUBARed a few months back, and one of the consequences of fixing it was that some old messages were renumbered (since the whole archive basically had to be reindexed or something like that). 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] Two small PEP ideas
On 05/05/2010 12:15, Nick Coghlan wrote: Georg Brandl wrote: I agree, and I wouldn't want to make these decisions. That person (or group) needs to have some weight in the community, or there will be a feeling of "... and who is he to decide anyway". We haven't emphasized RMship in the past; it's not a special position, except when something about a release goes wrong and blame must be placed ;) I think, being Guido, you are still the best single person to do this job. Not to wish anything bad on Guido, but I think it does behoove us as responsible stewards of the reference interpreter to at least consider the "bus" factor (as in "hit by a..."). I suspect Martin is right that some form of committee (at least initially) would be inevitable. While I doubt that we could find any one person that everyone would agree to defer to, I suspect we could find a small group of 3 or 4 people who's consensus everyone else would respect. And if that small group couldn't agree on whether or not something was a good idea, then the old "status quo wins a stalemate" would kick in. Sounds like a sensible arrangement. That said, this is hopefully something that we won't have to worry about for real until some time well into the future when Guido decides he wants to retire. Well, we (or more specifically Guido) may want to transition to some system where Guido doesn't have to make *every* decision. We only need this for PEPs where there isn't a community consensus. Michael Regards, Nick. -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog READ CAREFULLY. By accepting and reading this email you agree, on behalf of your employer, to release me from all obligations and waivers arising from any and all NON-NEGOTIATED agreements, licenses, terms-of-service, shrinkwrap, clickwrap, browsewrap, confidentiality, non-disclosure, non-compete and acceptable use policies (”BOGUS AGREEMENTS”) that I have entered into with your employer, its partners, licensors, agents and assigns, in perpetuity, without prejudice to my ongoing rights and privileges. You further represent that you have the authority to release me from any BOGUS AGREEMENTS on behalf of your employer. ___ 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
Am 05.05.2010 13:24, schrieb Michael Foord: > On 05/05/2010 12:15, Nick Coghlan wrote: >> Georg Brandl wrote: >> >>> I agree, and I wouldn't want to make these decisions. That person (or >>> group) needs to have some weight in the community, or there will be a >>> feeling of "... and who is he to decide anyway". We haven't emphasized >>> RMship in the past; it's not a special position, except when something >>> about a release goes wrong and blame must be placed ;) I think, being >>> Guido, you are still the best single person to do this job. >>> >> Not to wish anything bad on Guido, but I think it does behoove us as >> responsible stewards of the reference interpreter to at least consider >> the "bus" factor (as in "hit by a..."). Sure, but I think we wouldn't have too much trouble finding a replacement if and when that happens. (Let's hope it doesn't.) This is not something that requires weeks of preparation, and even if it did, no pronouncement on a PEP for a few weeks isn't the doom of Python. >> I suspect Martin is right that some form of committee (at least >> initially) would be inevitable. While I doubt that we could find any one >> person that everyone would agree to defer to, I suspect we could find a >> small group of 3 or 4 people who's consensus everyone else would >> respect. And if that small group couldn't agree on whether or not >> something was a good idea, then the old "status quo wins a stalemate" >> would kick in. > > Sounds like a sensible arrangement. Yes, I could imagine that too. Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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] Fwd: broken mailing list links in PEP(s?)
On May 5, 2010, at 7:09 AM, Oleg Broytman wrote: > On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote: >> http://mail.python.org/pipermail/python-list/2000-July/108893.html >> >> which are broken > > Pipermail's links aren't stable AFAIU. The numbering is changing over > time. They're only unstable if you regenerate the archives and the mbox file is old enough to have been a victim of a long-fixed delimiter bug. Which is true for python-dev. -Barry ___ 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] Reindenting patches
Nick Coghlan gmail.com> writes:
>
> Howver, if we delay fixing the C file indentation until we're already on
> hg, the merge tools should offer the best chance of being able to apply
> pre-fix patches and have the software figure out where the whitespace
> changes need to be accounted for.
For the record, I've added to the untabify script a patch rewriting option
("-p") which reindents all patch hunks for C files containing tabs. It should
minimize manual reformatting work with existing patches.
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] Fwd: broken mailing list links in PEP(s?)
On May 5, 2010, at 8:22 AM, Barry Warsaw wrote: On May 5, 2010, at 7:09 AM, Oleg Broytman wrote: On Wed, May 05, 2010 at 11:43:45AM +0100, Michael Foord wrote: http://mail.python.org/pipermail/python-list/2000-July/108893.html which are broken Pipermail's links aren't stable AFAIU. The numbering is changing over time. They're only unstable if you regenerate the archives and the mbox file is old enough to have been a victim of a long-fixed delimiter bug. Which is true for python-dev. And of course if you're paying attention, you can fix the mbox file (quoting "From" etc) such that it generates the same numbers as it did the first time. James ___ 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 am done running the analysis over trunk. I will not svnmerge these changes into py3k as the amount of time and effort that would take equates to running the static analyzer again just before 3.2 is released and possibly catching more changes (and maybe even a newer version of Clang at that point). On Mon, May 3, 2010 at 15:37, Brett Cannon wrote: > 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
Le mardi 04 mai 2010 00:37:22, Brett Cannon a écrit : > 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, ... Do you plan to port the changes to py3k? and what about 2.6 and 3.1? -- Please don't change whitespaces in the same commit. I think that we should fix the whitespaces of the whole project in one unique commit. Well, or least don't fix whitespaces file by file... -- Victor Stinner http://www.haypocalc.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 Wed, May 5, 2010 at 14:01, Victor Stinner wrote: > Le mardi 04 mai 2010 00:37:22, Brett Cannon a écrit : > > 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, ... > > Do you plan to port the changes to py3k? In case you didn't see my follow-up email that I sent just before this email, I will most likely do py3k when 3.2 is closer. > and what about 2.6 and 3.1? Not doing 2.6 as almost all changes are too minor bother. I think I found like two potential Py_DECREF/Py_XDECREF changes, but that's about it. And 3.1 would require py3k which I am not planning on doing in the near future. -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
[Python-Dev] Did I miss the decision to untabify all of the C code?
It looks like we're moving ahead with removing tabs. Was there consensus on this? Last I saw Antoine had written a script that might do what we want, but hadn't been thoroughly tested. Now I've seen a few checkins for files that have been run through the script. What gives? And why do this so close to 2.7? I don't think it will cause any problems, but it's hard to review commits to ensure they have no changes when there's a rush of large commits near a release. Eric. ___ 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] Did I miss the decision to untabify all of the C code?
2010/5/5 Eric Smith : > It looks like we're moving ahead with removing tabs. Was there consensus on > this? > > Last I saw Antoine had written a script that might do what we want, but > hadn't been thoroughly tested. Now I've seen a few checkins for files that > have been run through the script. > > What gives? And why do this so close to 2.7? I don't think it will cause any > problems, but it's hard to review commits to ensure they have no changes > when there's a rush of large commits near a release. I presume Victor was acting on an older decision that said that files mixed with tabs and spaces can be reindented for consistency. -- 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] Did I miss the decision to untabify all of the C code?
Eric Smith trueblade.com> writes: > > Last I saw Antoine had written a script that might do what we want, but > hadn't been thoroughly tested. Now I've seen a few checkins for files > that have been run through the script. As far as I'm concerned, it was a case of eating my own dog food: running the script over a couple of files I'm interested in (_ssl.c, _fileio.c). I believe Victor processed posixmodule.c for the same reasons. > What gives? And why do this so close to 2.7? I don't think it will cause > any problems, but it's hard to review commits to ensure they have no > changes when there's a rush of large commits near a release. Well, however soon or late we do this, good luck reviewing multi-thousand line commits to check no mistake sneaked in :) By construction, these commits only adjust whitespace in some C files, which means the risk of breakage is very close to zero. (I guess you could do a "svn diff -x -w" between each two revisions to expose any potential non-whitespace changes) Really 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] Did I miss the decision to untabify all of the C code?
Antoine Pitrou wrote: Eric Smith trueblade.com> writes: Last I saw Antoine had written a script that might do what we want, but hadn't been thoroughly tested. Now I've seen a few checkins for files that have been run through the script. As far as I'm concerned, it was a case of eating my own dog food: running the script over a couple of files I'm interested in (_ssl.c, _fileio.c). I believe Victor processed posixmodule.c for the same reasons. What gives? And why do this so close to 2.7? I don't think it will cause any problems, but it's hard to review commits to ensure they have no changes when there's a rush of large commits near a release. Well, however soon or late we do this, good luck reviewing multi-thousand line commits to check no mistake sneaked in :) That's my point. Since it's basically unreviewable, is it smart to do it during a beta? I grant you that it's a largely a mechanized change (except for the "a posteriori manual intervention" part), but still. Eric. ___ 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] Did I miss the decision to untabify all of the C code?
On Wed, May 5, 2010 at 9:59 PM, Eric Smith wrote: > Antoine Pitrou wrote: >> >> Eric Smith trueblade.com> writes: >>> >>> Last I saw Antoine had written a script that might do what we want, but >>> hadn't been thoroughly tested. Now I've seen a few checkins for files that >>> have been run through the script. >> >> As far as I'm concerned, it was a case of eating my own dog food: running >> the >> script over a couple of files I'm interested in (_ssl.c, _fileio.c). I >> believe >> Victor processed posixmodule.c for the same reasons. >> >>> What gives? And why do this so close to 2.7? I don't think it will cause >>> any problems, but it's hard to review commits to ensure they have no changes >>> when there's a rush of large commits near a release. >> >> Well, however soon or late we do this, good luck reviewing multi-thousand >> line >> commits to check no mistake sneaked in :) > > That's my point. Since it's basically unreviewable, is it smart to do it > during a beta? Hello folks - I don't think these modifications are that "unreviewable": the generated binaries have to be exactly the same with the untabified files don't they? So is a matter of stashing the binaries, applying the patches, rebuild and check to see if the binaries match. Any possible script defects undetected by this would be only (C code) indentation, which could be fixed later. Python 2.7 is in beta, but not applying such a fix now would probably mean that python 2.x would forever remain with the mixed tabs, since it would make much less sense for such a change in a minor revision (although I'd favor it even there). js -><- > > I grant you that it's a largely a mechanized change (except for the "a > posteriori manual intervention" part), but still. > > Eric. ___ 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] Did I miss the decision to untabify all of the C code?
On Wed, May 5, 2010 at 8:52 PM, Joao S. O. Bueno wrote: > Python 2.7 is in beta, but not applying such a fix now would probably > mean that python 2.x would forever remain with the mixed tabs, since > it would make much less sense for such a change in a minor revision > (although I'd favor it even there). > Since 2.7 is likely the last release of the 2.x series, wouldn't it more productive to spend time improving it instead of wasting time on minor details like indentation? -- 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
