[Sugar-devel] Deprecation policy - was: About show-launcher option

[Daniel Narvaez]

On 14 January 2014 01:33, Daniel Narvaez <dwnarvaez at gmail.com> wrote:

> On 14 January 2014 01:06, Daniel Narvaez <dwnarvaez at gmail.com> wrote:
>
>> On 14 January 2014 00:44, Manuel Quiñones <manuq at laptop.org> wrote:
>>
>>> > We just need a way to know what is public API and what is not. Maybe,
>>> for
>>> > new code, everything is public unless it has the usual underscore or
>>> there
>>> > are inline docs mentioning it's not public. For old code well... I
>>> guess we
>>> > just decide case by case.
>>>
>>> Yes, I think that's valid for old code too.  If you can import a
>>> class, function or constant variable from the toolkit, its public.
>>>
>>
>> Trying to make sure we are on the same page here, the devil is in details
>> on this kind of stuff :)
>>
>> * I think stuff prefix with _ is private, even if you can import it.
>> * I think it should be possible to mark stuff private by documentation.
>> Maybe we should use a PRIVATE "keyword" so that it's more human and machine
>> greppable. That's because sometimes you have modules that are only used
>> internally, but you don't want to put _ everywhere.
>>
>
> I suppose you could prefix the module with _, but I don't I've seen it
> done by other projects.
>


This is the PEP8 suggestion

http://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces

And I think it's also what python projects are usually doing. Problem is...
we don't really write much documentation. I suppose we could enforce at
least a single doc string explaining what the module does, for new code.
But what about old code?

If there is agreement to follow PEP8 on this, I guess I could volunteer to
write a quick description doc string for existing modules (other volunteers
to do that are very welcome though :P).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140114/f629770d/attachment.html>