Kyle Stanley wrote:
> It would also be appropriate to provide any user attempting to import
> a module that is going to be prepended with an underscore with
> warnings, and at least a couple of versions to update their code.
Clarification: When I mentioned prepending a module with an
underscore,
Nick Coghlan wrote:
> It's not an unwritten rule, as it already has its own subsection in
> PEP 8:
> https://www.python.org/dev/peps/pep-0008/#public-and-internal-interfaces
> The main question in this thread is what to do about standard library
> modules that were written before those documented
Interesting idea!
https://gitlab.com/warsaw/public/issues/3
-Barry
> On Aug 9, 2019, at 09:55, Christian Tismer wrote:
>
> Signed PGP part
> On 16.07.19 00:32, Barry Warsaw wrote:
>> On Jul 13, 2019, at 19:09, Raymond Hettinger
>> wrote:
>>>
>>> In some modules, we've been careful to use
On 16.07.19 00:32, Barry Warsaw wrote:
> On Jul 13, 2019, at 19:09, Raymond Hettinger
> wrote:
>>
>> In some modules, we've been careful to use both __all__ and to use an
>> underscore prefix to indicate private variables and helper functions
>> (collections and random for example). IMO, when
On Wed, 24 Jul 2019 at 06:32, Kyle Stanley wrote:
>
> Steve Dower wrote:
> > So I apologise for mentioning that people care about import performance.
> > Let's ignore them/that issue for now and worry instead about making sure
> > people (including us!) know what the canonical reference for
> >
> On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
>
> I thought that the name in a module is in the public interface if:
>
> * It doesn't start with an underscore and the module does not have __all__.
> * It is included in the module's __all__ list.
> * It is explicitly documented as a
Barry Warsaw wrote:
> On Jul 23, 2019, at 12:02, Steve Dower steve.do...@python.org wrote:
> > Even if the performance impact is zero, commits that
> > span the entire codebase for not-very-impactful changes have a negative
> > impact on
> > readability (for example, someone will suddenly become
On Jul 23, 2019, at 12:02, Steve Dower wrote:
>
> Even if the performance impact is zero, commits that span the entire codebase
> for not-very-impactful changes have a negative impact on readability (for
> example, someone will suddenly become responsible for every single module as
> far as
Steve Dower wrote:
> So I apologise for mentioning that people care about import performance.
> Let's ignore them/that issue for now and worry instead about making sure
> people (including us!) know what the canonical reference for
> public/internal is.
Good point, the discussion about
On 23Jul2019 1128, Kyle Stanley wrote:
Barry Warsaw wrote:
My package has a C version. If public() were a builtin (which I’ve implemented)
it wouldn’t have that much import time overhead.
Is there a way we could estimate the approximate difference in overhead this
would add using
Barry Warsaw wrote:
> This leads to the second problem, which is that it’s too easy for the __all__
> to get
> out of sync with the module’s contents. Often a function or class is renamed,
> removed, or
> added without the __all__ being updated.
IMO, this seems to be the best part of the
FWIW, I actually like the idea - though not strongly enough to really
campaign for it.
My reasoning is that I think that both the current "consenting adults"
policy and possibly more importantly the fact that we are implicitly
supporting private interfaces by our reluctance to changing them has
On 07/23/2019 10:21 AM, Barry Warsaw wrote:
On Jul 23, 2019, at 09:20, Ethan Furman wrote:
On 07/23/2019 08:44 AM, Steve Dower wrote:
It's trivial, but it adds a runtime overhead that is also trivially avoided by
putting the name in __all__ manually. And once it's public API, we shouldn't
On Jul 23, 2019, at 09:20, Ethan Furman wrote:
>
> On 07/23/2019 08:44 AM, Steve Dower wrote:
>
>> The @public decorator is basically:
>> def public(fn):
>> __all__.append(fn.__name__)
>> return fn
>> It's trivial, but it adds a runtime overhead that is also trivially avoided
>> by
On 07/23/2019 08:44 AM, Steve Dower wrote:
The @public decorator is basically:
def public(fn):
__all__.append(fn.__name__)
return fn
It's trivial, but it adds a runtime overhead that is also trivially avoided by
putting the name in __all__ manually. And once it's public API, we
On Jul 23, 2019, at 08:44, Steve Dower wrote:
> The @public decorator is basically:
>
> def public(fn):
>__all__.append(fn.__name__)
>return fn
>
> It's trivial, but it adds a runtime overhead that is also trivially avoided
> by putting the name in __all__ manually. And once it's
On 22Jul2019 2051, Kyle Stanley wrote:
Also, is the rule "unless explicitly documented public, all
imports are private even if not prefixed with an underscore" officially stated
anywhere, or is it mostly implied? Personally, I think that it should be explicitly
stated in a public manner if
On Tue, 23 Jul 2019 at 04:58, Kyle Stanley wrote:
>
> My primary motivation was to provide more explicit declaration of public vs
> private, not only for the purpose of shifting the responsibility to the
> authors, but also to shift the liability of using private members to the user.
My view
Upon further consideration and reading your response, I'm starting to think
that the proposal to perform a mass renaming across stdlib might have been a
bit too drastic, even if it was done over a longer period of time. Thanks for
the detailed explanation of the costs, that significantly
On Mon, Jul 22, 2019 at 10:02:12PM -, Kyle Stanley wrote about
renaming non-public names with a leading underscore:
> Good point, this would probably have to be a gradual change if it did
> happen, rather than being at all once. If it were to happen with a
> proper deprecation cycle and
Brett Cannon wrote:
> Same would happen with a rename where people's code suddenly broke. We
> don't do renames on purpose without a proper deprecation cycle and doing that
> en-mass would be extremely disruptive.
Good point, this would probably have to be a gradual change if it did happen,
Kyle Stanley wrote:
> Serhiy Storchaka wrote:
> > Either we establish the rule that all non-public
> > names must be
> > underscored, and do mass renaming through the whole stdlib. Or allow to
> > use non-underscored names for internal things and leave the sources in
> > Personally, I would be
On Sat, Jul 20, 2019 at 06:03:39AM -, Kyle Stanley wrote:
> Rather than it being on a case-by-case basis, would it be reasonable
> to establish a universal standard across stdlib for defining modules
> as public to apply to older modules as well?
No, I don't think so. That would require
Serhiy Storchaka wrote:
> Either we establish the rule that all non-public names must be
> underscored, and do mass renaming through the whole stdlib. Or allow to
> use non-underscored names for internal things and leave the sources in
Personally, I would be the most in favor of doing a mass
20.07.19 09:03, Kyle Stanley пише:
Rather than it being on a case-by-case basis, would it be reasonable to
establish a universal standard across stdlib for defining modules as public to
apply to older modules as well? I think that it would prove to be quite
beneficial to create an explicit
Brett Cannon wrote:
> I agree with Raymond that if the calendar module was following the leading
> underscore practice (which we should probably encourage all new modules to
> follow for
> consistency going forward) then I think the module should be updated to keep
> the practice
> going.
>
17.07.19 03:26, Brett Cannon пише:
I agree with Raymond that if the calendar module was following the leading
underscore practice (which we should probably encourage all new modules to
follow for consistency going forward) then I think the module should be updated
to keep the practice going.
14.07.19 05:09, Raymond Hettinger пише:
On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
Could we strictly define what is considered a public module interface in Python?
The RealDefinition™ is that whatever we include in the docs is public,
otherwise not.
Beyond that, there is a
PEP 8 would concur, whatever the current preferred style was. Under "Naming
Conventions":
"""New modules and packages (including third party frameworks) should be
written to these standards, but where an existing library has a different
style, internal consistency is preferred."""
The
Raymond Hettinger wrote:
> > On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka storch...@gmail.com... wrote:
> > Could we strictly define what is considered a public module interface in
> > Python?
> > The RealDefinition™ is that whatever we include in the docs is public,
> > otherwise
> not.
>
On Jul 13, 2019, at 19:09, Raymond Hettinger
wrote:
>
> In some modules, we've been careful to use both __all__ and to use an
> underscore prefix to indicate private variables and helper functions
> (collections and random for example). IMO, when a module has shown that
> care, future
> On Jul 13, 2019, at 1:56 PM, Serhiy Storchaka wrote:
>
> Could we strictly define what is considered a public module interface in
> Python?
The RealDefinition™ is that whatever we include in the docs is public,
otherwise not.
Beyond that, there is a question of how users can deduce what
On 13.07.2019 23:56, Serhiy Storchaka wrote:
I thought that the name in a module is in the public interface if:
* It doesn't start with an underscore and the module does not have __all__.
* It is included in the module's __all__ list.
* It is explicitly documented as a part of the public
33 matches
Mail list logo
