Re: [Python-Dev] PEP 8 updates/clarifications, function/method style
Hi, >> I hope new stuff will follow only one naming style. And now we should >> (or one person :-) should) decide which one. > > I guess my point boils down to, we already did decide 4 years ago. > Let's stick with what we've got. Ok, then let's stick with lower_case and check this if new libraries were added to std lib. Possible add a note to not forbid the use of cameCase in external libraries ? bye by Wolfgang ___ 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] Expose Subversion revision number to Python
Hi Barry,
On Fri, Dec 16, 2005 at 12:16:49AM -0500, Barry Warsaw wrote:
> SF patch # 1382163 is a fairly simple patch to expose the Subversion
> revision number to Python, both in the Py_GetBuildInfo() text, and in a
> new Py_GetBuildNumber() C API function, and via a new sys.build_number
> attribute.
I have a minor concern about people starting to use sys.build_number to
check for features in their programs, instead of using sys.version_info
or hasattr() or whatever is relevant -- e.g. because it seems to them
that comparing a single number is easier than a tuple. The problem is
that this build number would most likely have no meaning in non-CPython
implementations.
What about having instead:
sys.build_info = ("CPython", , "trunk")
This would make it clear that it's the CPython svn rev number, and it
could possibly be used to distinguish between branches, too, which the
revision number alone cannot do. ("trunk" is the last part of the path
returned by "svn info".)
Of course, what I'm trying to sneak in here is that it may be a good
occasion to introduce an official way to determine which Python
implementation the program is running on top of -- something more
immediate than the sys.platform=="java" occasionally used in the test
suite to look for Jython. (I know programs should not depend on this in
general; I'm more thinking about places like the test suite.)
A bientot,
Armin
___
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] Expose Subversion revision number to Python
Armin Rigo wrote:
> What about having instead:
>
> sys.build_info = ("CPython", , "trunk")
>
> This would make it clear that it's the CPython svn rev number, and it
> could possibly be used to distinguish between branches, too, which the
> revision number alone cannot do. ("trunk" is the last part of the path
> returned by "svn info".)
+1
___
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] Expose Subversion revision number to Python
Armin> What about having instead:
Armin> sys.build_info = ("CPython", , "trunk")
Armin> This would make it clear that it's the CPython svn rev number,
Armin> and it could possibly be used to distinguish between branches,
Armin> too, which the revision number alone cannot do. ("trunk" is the
Armin> last part of the path returned by "svn info".)
What was your directory path when you got "trunk" from "svn info"? In my
sandbox I get this:
% pwd
/Users/skip/src/python-svn/trunk
% svn info
Path: .
URL: svn+ssh://[EMAIL PROTECTED]/python/trunk
Repository UUID: 6015fed2-1504-0410-9fe1-9d1591cc4771
Revision: 41708
Node Kind: directory
Schedule: normal
Last Changed Author: trent.mick
Last Changed Rev: 41708
Last Changed Date: 2005-12-15 16:16:49 -0600 (Thu, 15 Dec 2005)
Properties Last Updated: 2005-12-15 20:45:15 -0600 (Thu, 15 Dec 2005)
Did you mean the last part of the URL?
Skip
___
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] Expose Subversion revision number to Python
On Thu, 2005-12-15 at 22:13 -0800, Brett Cannon wrote: > +0 > > It makes it easy to request the revision number from people who submit > patches and bugs. But I also don't find it vital since running ``svn > info .``. That's really more the point, that you can talk about a specific svn revision easily from a built Python, even if that's installed and moved to a location apart from the svn working directory. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Expose Subversion revision number to Python
On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote: > FYI, this is not the true revision number; it's only the revision number in > which the directory was last modified, not the latest revision number > within the tree. Yep, I know. At work, we've gone through many iterations of this, including essentially what you do in setuptools. I opted against that for several reasons. First, I wanted to keep the patch as simple as possible. Second, I didn't want to depend on Python already being built (i.e. write a Python script to do this). Third, I think most Python developers will just svn up at the top of the source tree, then rebuild, rather than svn up some buried sub-tree, cd back to the top and rebuild from there. At least, that's how I generally work with the Python tree. -Barry signature.asc Description: This is a digitally signed message part ___ 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] Expose Subversion revision number to Python
At 08:35 AM 12/16/2005 -0500, Barry Warsaw wrote: >On Fri, 2005-12-16 at 01:38 -0500, Phillip J. Eby wrote: > > > FYI, this is not the true revision number; it's only the revision > number in > > which the directory was last modified, not the latest revision number > > within the tree. > >Yep, I know. At work, we've gone through many iterations of this, >including essentially what you do in setuptools. > >I opted against that for several reasons. First, I wanted to keep the >patch as simple as possible. Second, I didn't want to depend on Python >already being built (i.e. write a Python script to do this). Third, I >think most Python developers will just svn up at the top of the source >tree, then rebuild, rather than svn up some buried sub-tree, cd back to >the top and rebuild from there. At least, that's how I generally work >with the Python tree. Actually, the issue I was concerned about was that when you make a change to some file and commit it, the build number won't change unless you also svn up, and maybe not even then. I never figured out how to get a good answer without reading the full "svn info -R" or the .svn/entries files. Note that you can just use: svn info -R|grep '^Last Changed Rev'|sort -nr|head -1|cut -f 4 -d" " To get the highest-numbered revision. However, both this approach and yours will not deal with Subversion messages in non-English locales. I discovered this with setuptools when I was using "svn info" when somebody reported that the text before the numbers is different in non-English locales. After a bit of experimentation, here's a pipeline that gets the info directly from the entries files, without reliance on the language of svn info's output: find . -name entries | grep '\.svn/entries$' | xargs grep -h committed-rev \ | cut -f2 -d'"' | sort -nr |head -1 ___ 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] Expose Subversion revision number to Python
At 07:42 AM 12/16/2005 -0800, Michael Chermside wrote: >Phillip writes: > > FYI, this is not the true revision number; it's only the revision number in > > which the directory was last modified, not the latest revision number > > within the tree. > >Barry responds: > > I opted against that for several reasons. First, I wanted to keep the > > patch as simple as possible. Second, I didn't want to depend on Python > > already being built [...] Third, I > > think most Python developers will just svn up at the top of the source > > tree, then rebuild, rather than svn up some buried sub-tree, cd back to > > the top and rebuild from there. > >I agree with Barry. If you have done your "svn up" from anywhere other >than the root, then you are building Python with a mix of revisions. I >think that sys.build_number should produce undefined behavior when >executing in a Python built from mixed revisions -- anyone doing this >gets what they deserve. The "Revision" from "svn info" isn't reliable; it doesn't actually relate to what version of code is in the subtree. It can change when nothing has changed. For example, in my setuptools checkout, I just did an "svn up", and the "Revision" is now 41708. But *nothing* in the tree has changed since 41701; this is simply the current highest SVN revision, repository wide. When people change things in branches, the sandbox, PEPs, etc. - that number will change, even though nothing changed in the trunk. I suggest that having an SVN revision number that changes when no code has actually changed is confusing and unreliable. SVN does track the actual *changed* revision, it just takes a little more work to get it. ___ 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] Expose Subversion revision number to Python
Hi Phillip, On Fri, Dec 16, 2005 at 10:51:33AM -0500, Phillip J. Eby wrote: > svn info -R|grep '^Last Changed Rev'|sort -nr|head -1|cut -f 4 -d" " > > To get the highest-numbered revision. However, both this approach and > yours will not deal with Subversion messages in non-English locales. The 'py' lib works around this problem by running "LC_ALL=C svn info". A bientot, Armin ___ 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] Expose Subversion revision number to Python
Hi Skip,
On Fri, Dec 16, 2005 at 05:02:19AM -0600, [EMAIL PROTECTED] wrote:
> Armin> ("trunk" is the last part of the path returned by "svn info".)
> Did you mean the last part of the URL?
Yes, sorry.
Armin
___
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] Expose Subversion revision number to Python
Hi Phillip, On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote: > The "Revision" from "svn info" isn't reliable; it doesn't actually relate > to what version of code is in the subtree. It can change when nothing has > changed. Indeed, the patch should not use the "Revision" line but the "Last Changed Rev" one. > SVN does track the actual > *changed* revision, it just takes a little more work to get it. Not if you're happy with "Last Changed Rev": LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " " A bientot, Armin ___ 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] Expose Subversion revision number to Python
At 05:17 PM 12/16/2005 +0100, Armin Rigo wrote: >Hi Phillip, > >On Fri, Dec 16, 2005 at 10:59:23AM -0500, Phillip J. Eby wrote: > > The "Revision" from "svn info" isn't reliable; it doesn't actually relate > > to what version of code is in the subtree. It can change when nothing has > > changed. > >Indeed, the patch should not use the "Revision" line but the "Last >Changed Rev" one. > > > SVN does track the actual > > *changed* revision, it just takes a little more work to get it. > >Not if you're happy with "Last Changed Rev": > > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " " You left off the all-important "-R" from "svn info", and the "sort -nr | head -1" at the end. The "Last Changed Rev" of the root is not necessarily the highest "Last Changed Rev", no matter how or where you update or check out. Try it and see. ___ 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] Expose Subversion revision number to Python
On Fri, 16 Dec 2005, Phillip J. Eby wrote: [...to-and-fro re magic required to get a good SVN revision...] Shouldn't the command 'svnversion' be used instead? - http://svnbook.red-bean.com/en/1.1/re57.html It's true that the output of this command does change with 'svn up', even if the update makes no changes to files under version control in your working copy. It *seems* to be sane & reproducible once you've done a single svn up, though (and if there are no locally modified files, mixed checkouts etc., the version it reports will be a single revision number with no non-numeric characters). John ___ 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] Expose Subversion revision number to Python
Phillip J. Eby wrote: > The "Revision" from "svn info" isn't reliable; it doesn't actually relate > to what version of code is in the subtree. It can change when nothing has > changed. That is not true. It does relate - it is the revision that was current when "svn up" was last done. This *does* allow you to tell what changed last, and it *does* allow to restore the precise sources (unless the user only made a partial "svn up"). If some person tells you this revision R, and you do 'svn up -rR', then you have precisely the same sources as that person. 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] Expose Subversion revision number to Python
At 08:30 PM 12/16/2005 +0100, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > The "Revision" from "svn info" isn't reliable; it doesn't actually relate > > to what version of code is in the subtree. It can change when nothing has > > changed. > >That is not true. It does relate - it is the revision that was current >when "svn up" was last done. But you can also have more than one revision number that represents the *exact same code*, with no changes at all. > This *does* allow you to tell what changed >last, It can also give you a false indicator of change, when nothing has in fact changed. Don't believe me? Check in a change to a sandbox project or a branch, and go see if the Python trunk still has the same "revision" afterwards. I'm rather baffled as to why everyone seems so insistent on not using "Last Changed Rev" and "-R", given that the information is demonstrably a 1:1 mapping with actual changes to the project, while "Revision" without -R is demonstrably *not* a 1:1 mapping with actual changes to the project. ___ 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] hashlib - faster md5/sha, adds sha256/512 support
Hi -- I'm curious as to the status of upgrading cryptographic hash function support in Python, now that md5 and sha1 are both clearly broken (in terms of collision-resistance). The consensus of researchers in this area (at least as expressed at the NIST Hash Function Workshop 10/31/05), is that SHA-256 is a good choice for the time being, but that research should continue, and other alternatives may arise from this research. The larger SHA's also seem OK, but I think will have less demand... I'd like to see sha-256 supported in Python. Has this already happened (and I didn't notice) and/or will it be happening soon? Thanks! Cheers, Ron Rivest P.S. Please cc your reply to me at [EMAIL PROTECTED] as well Thanks! Ronald L. Rivest Room 32-G692, Stata Center, MIT, Cambridge MA 02139 Tel 617-253-5880, Email <[EMAIL PROTECTED]> ___ 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] hashlib - faster md5/sha, adds sha256/512 support
Python 2.5 will include sha-256 and sha-512. It will be released sometime next year. Jeremy On 12/16/05, Ronald L. Rivest <[EMAIL PROTECTED]> wrote: > Hi -- > > I'm curious as to the status of upgrading cryptographic > hash function support in Python, now that md5 and sha1 are > both clearly broken (in terms of collision-resistance). > > The consensus of researchers in this area (at least as > expressed at the NIST Hash Function Workshop 10/31/05), > is that SHA-256 is a good choice for the time being, but > that research should continue, and other alternatives may > arise from this research. The larger SHA's also seem OK, > but I think will have less demand... > > I'd like to see sha-256 supported in Python. Has this > already happened (and I didn't notice) and/or will it > be happening soon? > > Thanks! > > Cheers, > Ron Rivest > > P.S. Please cc your reply to me at [EMAIL PROTECTED] as well > Thanks! > > > Ronald L. Rivest > Room 32-G692, Stata Center, MIT, Cambridge MA 02139 > Tel 617-253-5880, Email <[EMAIL PROTECTED]> > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/jeremy%40alum.mit.edu > ___ 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] hashlib - faster md5/sha, adds sha256/512 support
[Ronald L. Rivest] > I'm curious as to the status of upgrading cryptographic > hash function support in Python, now that md5 and sha1 are > both clearly broken (in terms of collision-resistance). > > The consensus of researchers in this area (at least as > expressed at the NIST Hash Function Workshop 10/31/05), > is that SHA-256 is a good choice for the time being, but > that research should continue, and other alternatives may > arise from this research. The larger SHA's also seem OK, > but I think will have less demand... > > I'd like to see sha-256 supported in Python. Has this > already happened (and I didn't notice) and/or will it > be happening soon? I'm gratified that you think highly enough of Python to ask ;-) A new core `hashlib` module will be included in Python 2.5, but will not be backported to older Python versions. It includes new implementations for SHA-224, -256, -384 and -512. The code and tests are already written, and can be gotten from Python's SVN trunk. python-dev'ers: I failed to find anything in the trunk's NEWS file about this (neither about `hashlib`, nor about any of the specific new hash functions). It's not like it isn't newsworthy ;-) ___ 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] Expose Subversion revision number to Python
Phillip J. Eby wrote: > But you can also have more than one revision number that represents the > *exact same code*, with no changes at all. That's correct. I don't see this as a problem - in particular not in the context of the proposed patch. The idea is that you can reliably tell what code base a certain executable image originates from. With that patch, you can > It can also give you a false indicator of change, when nothing has in > fact changed. Don't believe me? I believe that the version number changes. It is a false indicator only if you are unaware of that fact. To me, different version numbers don't indicate different code bases, because I know how subversion works. > I'm rather baffled as to why everyone seems so insistent on not using > "Last Changed Rev" and "-R" That's easy to tell: because it is expensive. 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] Expose Subversion revision number to Python
Hi Phillip, On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote: > >Not if you're happy with "Last Changed Rev": > > > > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " " > > You left off the all-important "-R" from "svn info", and the "sort -nr | > head -1" at the end. The "Last Changed Rev" of the root is not necessarily > the highest "Last Changed Rev", no matter how or where you update or check > out. Try it and see. I was proposing this line as a slight extension of the one currently in the SF patch. In accordance with Martin I am still unconvinced that 'svn info -R' or more fancy tools are really useful here. If you meant that the following situation is possible: trunk$ svn up At revision xxx. trunk$ svn info Last Changed Rev: 1 trunk$ cd Python trunk/python$ svn info Last Changed Rev: 10001 then I object. As far as I can tell this is not possible. A bientot, Armin ___ 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] Expose Subversion revision number to Python
At 10:03 PM 12/16/2005 +0100, Martin v. Löwis wrote: >Phillip J. Eby wrote: > > But you can also have more than one revision number that represents the > > *exact same code*, with no changes at all. > >That's correct. I don't see this as a problem - in particular not in >the context of the proposed patch. > >The idea is that you can reliably tell what code base a certain >executable image originates from. With that patch, you can Only if you do an "svn update" immediately after *every* "svn commit". Otherwise, the code base reflected will be a version *before* your changes. This is fragile, since not everyone will know (or remember!) to do this. > > It can also give you a false indicator of change, when nothing has in > > fact changed. Don't believe me? > >I believe that the version number changes. It is a false indicator only >if you are unaware of that fact. To me, different version numbers don't >indicate different code bases, because I know how subversion works. ^^^ Exactly my point. The proposed mechanism relies on an intimate understanding of how subversion and its revision numbers work, making it unnecessarily fragile when used by Python developers and the community at large. > > I'm rather baffled as to why everyone seems so insistent on not using > > "Last Changed Rev" and "-R" > >That's easy to tell: because it is expensive. I doubt that's the actual reason, but it seems like a bad reason in any case; it seems to me the applicable Zen should be "never is often better than *right* now". :) That is, if you're going to rely on a number that can be falsely high or falsely low depending on the detailed development practices of developers working on the trunk or anywhere else, it seems like wasted effort. Trying to diagnose a problem with wrong information is worse than having *no* information. Thus, I'm -1 on including a revision number that will be frequently wrong (high *or* low) in practice. If it's too "expensive" to do it right, it's *definitely* too expensive to do it wrong. :) ___ 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] Expose Subversion revision number to Python
At 10:16 PM 12/16/2005 +0100, Armin Rigo wrote: >Hi Phillip, > >On Fri, Dec 16, 2005 at 11:33:00AM -0500, Phillip J. Eby wrote: > > >Not if you're happy with "Last Changed Rev": > > > > > > LC_ALL=C svn info | grep -i "last changed rev" | cut -f 4 -d " " > > > > You left off the all-important "-R" from "svn info", and the "sort -nr | > > head -1" at the end. The "Last Changed Rev" of the root is not > necessarily > > the highest "Last Changed Rev", no matter how or where you update or check > > out. Try it and see. > >I was proposing this line as a slight extension of the one currently in >the SF patch. In accordance with Martin I am still unconvinced that >'svn info -R' or more fancy tools are really useful here. > >If you meant that the following situation is possible: > > trunk$ svn up > At revision xxx. > trunk$ svn info > Last Changed Rev: 1 > trunk$ cd Python > trunk/python$ svn info > Last Changed Rev: 10001 > >then I object. As far as I can tell this is not possible. It is indeed possible for a file's "Last Changed Rev" to exceed that of the directory that contains it. I'm not sure what you object to, though. These are simply the facts of how Subversion operates, so objecting to anybody but the Subversion developers won't help. ;) I have not found any way to establish a stable "revision number" for a directory tree in Subversion except by using -R and "Last Changed Rev" (or the equivalent scanning of .svn/entries files). Through my experience working on setuptools in the sandbox, it is clearly possible to *commit* changes without affecting a directory's "Revision" number, and updating a directory can cause its "Revision" to advance even when there has been no change to the source. ___ 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] Expose Subversion revision number to Python
Phillip J. Eby wrote: > I have not found any way to establish a stable "revision number" for a > directory tree in Subversion except by using -R and "Last Changed Rev" (or > the equivalent scanning of .svn/entries files). Through my experience > working on setuptools in the sandbox, it is clearly possible to *commit* > changes without affecting a directory's "Revision" number it's also possible to modify files and rebuild. your approach doesn't address that. > and updating a directory can cause its "Revision" to advance even when > there has been no change to the source. sure, but is that really relevant? checking out that revision will give you the same code base, and it's not exactly difficult to figure out what's changed be- tween two given versions... fwiw, the official way to do this is to use svnversion: http://subversion.tigris.org/faq.html#version-value-in-source (this also looks for local changes). ___ 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] Expose Subversion revision number to Python
At 10:53 PM 12/16/2005 +0100, Fredrik Lundh wrote: >fwiw, the official way to do this is to use svnversion: > > http://subversion.tigris.org/faq.html#version-value-in-source > >(this also looks for local changes). It looks like using 'svnversion -c . | cut -f2 -d":"' would get the most-recent committed version, plus the letter "M" if there are local changes. That sounds like what we should be using. That way, a build with local revisions would include "M", thus nicely addressing that issue as well. ___ 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] hashlib - faster md5/sha, adds sha256/512 support
On 12/16/05, Tim Peters <[EMAIL PROTECTED]> wrote: [SNIP] > python-dev'ers: I failed to find anything in the trunk's NEWS file > about this (neither about `hashlib`, nor about any of the specific new > hash functions). It's not like it isn't newsworthy ;-) I have fixed the faux pas and added an entry. -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
