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
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-recen
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: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 "
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
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
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 bas
[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 Works
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 br
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 S
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 revis
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
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
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.
>
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 bu
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
Python-Dev@
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
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 seve
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 k
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,
in
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
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
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
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
> attrib
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 librar
25 matches
Mail list logo
