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
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
Armin Rigo wrote:
What about having instead:
sys.build_info = (CPython, svn rev, 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
Armin What about having instead:
Armin sys.build_info = (CPython, svn rev, 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
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
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,
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
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
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.
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
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
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
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
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
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
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
[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
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
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
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.
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
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
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
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
24 matches
Mail list logo
