> be32850b093f is listed
> as having a child revision, 52b0a279fec6, and ISTM that *this*
> should be the revision that got tagged.
I think the tag is correct. Note that the concept of tagging is
different in Mercurial, where a tag can only refer to a revision
previous to the one where it is inser
According to
http://hg.python.org/cpython/tags?revcount=50
the tag r301 belongs to revision be32850b093f. However, this
is really r69557, which was not tagged. be32850b093f is listed
as having a child revision, 52b0a279fec6, and ISTM that *this*
should be the revision that got tagged.
Regards,
M
Martin v. Löwis wrote:
Terry Reedy wrote:
Before posting http://bugs.python.org/issue6453
I searched the tracker for 'bool TypeError' to avoid making a duplicate
report. A few irrelevant hits were return but not the important one
http://bugs.python.org/issue6428
which was the one I needed to fin
At 03:31 PM 7/10/2009 +0200, Tarek Ziadé wrote:
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>> Also,
>> >>> why should the RECORD file be
ACTIVITY SUMMARY (07/03/09 - 07/10/09)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue
number. Do NOT respond to this message.
2245 open (+32) / 16035 closed (+17) / 18280 total (+49)
Open issues with patches: 894
Average
-On [20090710 15:32], Tarek Ziadé (ziade.ta...@gmail.com) wrote:
>setup(
>...
>data_files={'i18n': ['en.po', 'fr.po']},
>extra_prefixes={'i18n': {'unix_prefix': '/somewhere',
>
On Thu, Jul 9, 2009 at 9:09 PM, P.J. Eby wrote:
> At 02:46 PM 7/9/2009 -0400, Tres Seaver wrote:
>>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA1
>>
>> Nick Coghlan wrote:
>> > P.J. Eby wrote:
>> >>> Also,
>> >>> why should the RECORD file be generated at all by bdist* commands?
>> >> bdist
2009/7/9 Nick Coghlan :
> Paul Moore wrote:
>> - some cases are not simple, and it's not clear to me how useful
>> "nearly always accurate" data will be
>
> Since the accuracy can always be checked against the filesystem, I think
> the metadata is useful even if not 100% reliable. Applications that
