Open Stack

On 02/07/2014 08:57 PM, Joe Gordon wrote:
> On Fri, Feb 7, 2014 at 6:40 AM, Jay Pipes <jaypipes at gmail.com> wrote:
>> On Fri, 2014-02-07 at 15:36 +0100, Julien Danjou wrote:
>>> On Fri, Feb 07 2014, Jay Pipes wrote:
>>>
>>>> On Fri, 2014-02-07 at 14:25 +0000, Matthew Booth wrote:
>>>>> I have a comment which references a long URL. The URL itself is longer
>>>>> than 80 characters. Jenkins has flagged this as a pep8 failure, because
>>>>> the line is longer than 80 characters.
>>>>>
>>>>> This is an instance where in the past I have always applied common sense
>>>>> to the line length limit. You either have a long line or a broken URL.
>>>>> As the long line is more usable in this instance, it's the lesser of 2
>>>>> evils.
>>>>>
>>>>> Is there a mechanism to to coerce Jenkins to allow it? Failing that, is
>>>>> there a mechanism to manually ignore a specific Jenkins failure? Failing
>>>>> that, is there a project convention for broken URLs?
>>>>
>>>> How about using a service like bit.ly to shorten the URL? Would that be
>>>> acceptable?
>>>
>>> This would be ridiculous. :-/
>>
>> ? Why would that be ridiculous? I'm not talking about having pep8 use
>> bit.ly. I'm talking about Matthew just shortening the URL with bit.ly
>> and putting the shortened URL in the comment.
>>
>>> Isn't #noqa working on such error?
>>
>> Yes, as I mentioned in a follow up...
> 
> E501 (line too long) can be disabled at the line level using the #
> noqa special comment
> 
> Source:  http://pep8.readthedocs.org/en/latest/intro.html#error-codes

Sure, but honestly, putting a random url from the internet in source
code seems largely not useful. Because how long do we expect that url to
be valid? A month, a year?

The summary rationale for that should be pulled in, feel free to put
something in a review comment or the commit on upstream reference, but
having urls for external url in source code is just debt.

	-Sean

-- 
Sean Dague
Samsung Research America
sean at dague.net / sean.dague at samsung.com
http://dague.net

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140208/e0677815/attachment.pgp>