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

[Daniel Narvaez]

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

> 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).
>

Uff I read too quickly

"Even with __all__ set appropriately, internal interfaces (packages,
modules, classes, functions, attributes or other names) should still be
prefixed with a single leading underscore."

So we could use underscored modules.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140114/6140b833/attachment.html>