https://pypi.python.org/pypi/apipkg provides a much more effective way
to denote API than an _
On Wed, Jul 17, 2013 at 12:20 PM, R. David Murray wrote:
> On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy wrote:
>> On 7/16/2013 9:39 AM, R. David Murray wrote:
>> > On Tue, 16 Jul 2013 23:19:21 +1000
On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy wrote:
> On 7/16/2013 9:39 AM, R. David Murray wrote:
> > On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano
> > wrote:
>
> >> For example, pkgutil includes classes with single-underscore methods,
> >> which I take as private. It also has a func
On Jul 17, 2013, at 09:35 AM, Brett Cannon wrote:
>Or how about dropping the whole ``from ... import ...`` format entirely?
><0.5 wink; seriously, it's implementation is a pain and it has wonky
>semantics>
Yes, let's break *everything* :)
-Barry
signature.asc
Description: PGP signature
___
On Tue, Jul 16, 2013 at 9:07 PM, Barry Warsaw wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote:
>
> >On 07/16/2013 07:09 AM, Nick Coghlan wrote:
> >
> >> I did find it interesting that we *don't* explicitly advise against
> >> the use
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Jul 16, 2013, at 07:34 PM, Tres Seaver wrote:
>On 07/16/2013 07:09 AM, Nick Coghlan wrote:
>
>> I did find it interesting that we *don't* explicitly advise against
>> the use of "import *" for anything other than optional accelerator
>> modules
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/16/2013 07:09 AM, Nick Coghlan wrote:
> I did find it interesting that we *don't* explicitly advise against
> the use of "import *" for anything other than optional accelerator
> modules or republishing internal interfaces through a public API
On 7/16/2013 9:39 AM, R. David Murray wrote:
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano wrote:
For example, pkgutil includes classes with single-underscore methods, which I take as
private. It also has a function simplegeneric, which is undocumented and not listed in
__all__. In in
On Jul 16, 2013, at 04:10 PM, Nick Coghlan wrote:
>Yeah, we should probably be a bit more vocal in pointing out that PEP
>8 is something to be applied judiciously, *not* treated as "sacred
>writ, never to be questioned". It's very tempting to just sigh and
>ignore it, instead of explicitly pointin
On Jul 16, 2013, at 11:48 PM, Nick Coghlan wrote:
>For the general case, the patch I posted to the issue tracker sets the
>precedence as docs -> __all__ -> leading underscore.
+1
-Barry
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.pyth
On Jul 16, 2013, at 11:28 AM, Richard Oudkerk wrote:
>BTW, how does the use of __all__ effect things? Somewhere I got the idea
>that if a module uses __all__ then anything not listed is internal. I take
>it that is wrong?
Purely technically, __all__ is there to affect how from-import-* works.
On Jul 15, 2013, at 11:02 PM, Chris McDonough wrote:
>Given that misunderstanding, is there a way to divorce stdlib-centric
>guidelines like the one being discussed now from "PEP8"-ness? I don't
>think any amount of marketing effort or reasoned explanation is going to
>separate "PEP8" from "corre
On 16 July 2013 23:39, R. David Murray wrote:
> On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano
> wrote:
>> On 16/07/13 20:28, Richard Oudkerk wrote:
>> > On 16/07/2013 6:44am, Nick Coghlan wrote:
>> >> Clarifying what constitutes an internal interface in a way that
>> >> doesn't require ren
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano wrote:
> On 16/07/13 20:28, Richard Oudkerk wrote:
> > On 16/07/2013 6:44am, Nick Coghlan wrote:
> >> Clarifying what constitutes an internal interface in a way that
> >> doesn't require renaming anything is a necessary prerequisite for
> >> bund
On 16/07/13 20:28, Richard Oudkerk wrote:
On 16/07/2013 6:44am, Nick Coghlan wrote:
Clarifying what constitutes an internal interface in a way that
doesn't require renaming anything is a necessary prerequisite for
bundling or bootstrapping the pip CLI in Python 3.4 (as pip exposes
its internal i
On 16 July 2013 21:10, Nick Coghlan wrote:
> On 16 July 2013 20:28, Richard Oudkerk wrote:
>> On 16/07/2013 6:44am, Nick Coghlan wrote:
>>>
>>> Clarifying what constitutes an internal interface in a way that
>>> doesn't require renaming anything is a necessary prerequisite for
>>> bundling or boo
On 16 July 2013 20:28, Richard Oudkerk wrote:
> On 16/07/2013 6:44am, Nick Coghlan wrote:
>>
>> Clarifying what constitutes an internal interface in a way that
>> doesn't require renaming anything is a necessary prerequisite for
>> bundling or bootstrapping the pip CLI in Python 3.4 (as pip expose
On 16 July 2013 18:41, Terry Reedy wrote:
> On 7/15/2013 11:11 PM, Nick Coghlan wrote:
>
>> I'll look into adding some stronger wording at the top making it clear
>> that while PEP 8 is a useful starting point and a good default if a
>> project doesn't have a defined style guide of it's own, it is
On 16/07/2013 6:44am, Nick Coghlan wrote:
Clarifying what constitutes an internal interface in a way that
doesn't require renaming anything is a necessary prerequisite for
bundling or bootstrapping the pip CLI in Python 3.4 (as pip exposes
its internal implemetnation API as "import pip" rather th
On 7/15/2013 11:11 PM, Nick Coghlan wrote:
I'll look into adding some stronger wording at the top making it clear
that while PEP 8 is a useful starting point and a good default if a
project doesn't have a defined style guide of it's own, it is *not*
the be-all-and-end-all for Python style guides
On 16 July 2013 16:01, Chris McDonough wrote:
> Well, I know it's arguing with the umpire at this point, but PEP8
> prescriptionism (great word by the way!) is de rigeur these days. It's
> a python-dev perogative to ignore that, but it has consequences that
> reverberate further than this maillis
On Tue, 2013-07-16 at 15:44 +1000, Nick Coghlan wrote:
> On 16 July 2013 13:16, Chris McDonough wrote:
> > I understand that. Unfortunately the remainder of the world does not.
> > The same IDEs that would be helped via this proposed change have "PEP8
> > modes" turned on *by default*!
> > http:/
On 16 July 2013 13:16, Chris McDonough wrote:
> I understand that. Unfortunately the remainder of the world does not.
> The same IDEs that would be helped via this proposed change have "PEP8
> modes" turned on *by default*!
> http://blog.jetbrains.com/pycharm/2013/02/long-awaited-pep-8-checks-on-
On Tue, 2013-07-16 at 13:11 +1000, Nick Coghlan wrote:
> On 16 July 2013 13:02, Chris McDonough wrote:
> > OSS developers have spent many months jumping through bw incompat hoops
> > in Python over the last few years, and it has taken time away from doing
> > things that provide value. The less I
On 16 July 2013 13:02, Chris McDonough wrote:
> OSS developers have spent many months jumping through bw incompat hoops
> in Python over the last few years, and it has taken time away from doing
> things that provide value. The less I can do of that, the better, and
> Python gets more value too.
On Tue, 2013-07-16 at 12:34 +1000, Nick Coghlan wrote:
> How do get from "If this doesn't apply to a module, just add something
> like 'This is an internal API' or 'This module includes internal APIs,
> consult the documentation for the public API' to the module docstring"
> to "updating 500k line
On Jul 15, 2013, at 08:23 PM, Chris McDonough wrote:
>On Mon, 2013-07-15 at 18:40 -0400, Barry Warsaw wrote:
>> Working from what I think is the latest version.
>>
>> In general, i'd rather be prescriptive of future conventions than
>> descriptive of current conventions. It's okay to exempt exis
On 16 July 2013 12:20, Chris McDonough wrote:
> On Tue, 2013-07-16 at 11:25 +1000, Steven D'Aprano wrote:
>
>>
>> If your code has no obvious, documented convention at all for what's
>> internal and what is not, they are no worse off.
>>
>> If you do have a documented convention for internal impl
On Tue, 2013-07-16 at 11:25 +1000, Steven D'Aprano wrote:
>
> If your code has no obvious, documented convention at all for what's internal
> and what is not, they are no worse off.
>
> If you do have a documented convention for internal implementation details,
> then you are no worse off. "I
On 16 July 2013 10:23, Chris McDonough wrote:
> On Mon, 2013-07-15 at 18:40 -0400, Barry Warsaw wrote:
>> Working from what I think is the latest version.
>>
>> In general, i'd rather be prescriptive of future conventions than descriptive
>> of current conventions. It's okay to exempt existing co
On 16/07/13 10:23, Chris McDonough wrote:
If what's being described here does become a rule, there is reason to
believe that future users who treat this PEP as the word-of-god (and
there are a *lot* of them; I hear from people literally every week who
want to "PEP8-ify" my code in some limited-v
On Mon, 2013-07-15 at 18:40 -0400, Barry Warsaw wrote:
> Working from what I think is the latest version.
>
> In general, i'd rather be prescriptive of future conventions than descriptive
> of current conventions. It's okay to exempt existing code, and as a general
> rule we've never been fond of
Working from what I think is the latest version.
In general, i'd rather be prescriptive of future conventions than descriptive
of current conventions. It's okay to exempt existing code, and as a general
rule we've never been fond of rewriting existing code to update it to new
standards or APIs.
On 16 Jul 2013 06:13, "Barry Warsaw" wrote:
>
> On Jul 15, 2013, at 09:56 PM, Antoine Pitrou wrote:
>
> >If you really want another word (I am personally fine with "private"),
> >"internal" it should be.
>
> I would be fine with "internal", since that's how PEP 8 already classifies
> such names. :
On Jul 15, 2013, at 09:56 PM, Antoine Pitrou wrote:
>If you really want another word (I am personally fine with "private"),
>"internal" it should be.
I would be fine with "internal", since that's how PEP 8 already classifies
such names. :)
-Barry
___
P
On Mon, 15 Jul 2013 15:51:31 -0400
Barry Warsaw wrote:
> On Jul 14, 2013, at 06:11 PM, Nick Coghlan wrote:
>
> >Private interfaces
>
> PEP 8 does say:
>
> _single_leading_underscore: weak "internal use" indicator. E.g. from M
> import * does not import objects whose name starts with an
On Jul 14, 2013, at 06:11 PM, Nick Coghlan wrote:
>Private interfaces
PEP 8 does say:
_single_leading_underscore: weak "internal use" indicator. E.g. from M
import * does not import objects whose name starts with an underscore.
I'm in favor of making this a stronger recommendation, but
On 15 July 2013 17:31, Terry Reedy wrote:
> I do not think absence of documentation is a good signal. I would rather say
> that any private or partially private package that does not have a _ name
> *must* have a docstring saying that it is all or mostly private. (Or be a
> subpackage or module o
On 7/15/2013 12:17 AM, Nick Coghlan wrote:
You'd be surprised how many non-core devs react with astonishment
when I suggest that not documenting something isn't enough to avoid
having users consider it a supported public API - they usually get it
after I point out how far you can usually get ju
Nick Coghlan writes:
>> Of course private modules are sane. I never suggested "no new private
>> modules at all". But putting them in the same namespace as public
>> modules is not, just to save a leading underscore in the file name.
> It's not to save a leading underscore - it's to avoid ren
On Mon, Jul 15, 2013 at 6:17 AM, Nick Coghlan wrote:
> =
> Private interfaces
>
> Unless explicitly documented otherwise, a leading underscore on any
> name indicates that it is an internal implementation detail and any
> backwards compatibility guarantees do not apply. It is stron
On 15 July 2013 02:15, Gregory P. Smith wrote:
> On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote:
>> as Python users may rely on introspection to identify available
>> functionality and may be misled into believing an API without a leading
>> underscore is in fact a public API with the standa
On 15 Jul 2013 13:46, "Steven D'Aprano" wrote:
>
> On Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
> > On 15Jul2013 09:48, Steven D'Aprano wrote:
>
> > | I'd go further, and say that no more private modules should be
> > | accepted for the std lib unless they have a leading under
On 15 Jul 2013 13:43, "Steven D'Aprano" wrote:
>
> On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
> > On 15 July 2013 09:48, Steven D'Aprano wrote:
> > > On 14/07/13 21:09, Nick Coghlan wrote:
> > >
> > >> Slight adjustment to the proposed wording to ensure completely
> > >> undocu
On Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | I'd go further, and say that no more private modules should be
> | accepted for the std lib unless they have a leading underscore. I
> | suppose for backwards compatibility reasons,
On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
> On 15 July 2013 09:48, Steven D'Aprano wrote:
> > On 14/07/13 21:09, Nick Coghlan wrote:
> >
> >> Slight adjustment to the proposed wording to ensure completely
> >> undocumented
> >> modules are also considered private:
> >
> >
> > -
On 7/14/2013 7:09 AM, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure completely
undocumented modules are also considered private:
=
Private interfaces
Unless explicitly documented otherwise, a leading underscore on any name
indicates that it is an inter
On 15 July 2013 09:48, Steven D'Aprano wrote:
> On 14/07/13 21:09, Nick Coghlan wrote:
>
>> Slight adjustment to the proposed wording to ensure completely
>> undocumented
>> modules are also considered private:
>
>
> -1 on this adjustment. If somebody cannot be bothered writing a one-line doc
> st
On Sun, Jul 14, 2013 at 8:01 PM, Cameron Simpson wrote:
> On 15Jul2013 09:48, Steven D'Aprano wrote:
> | On 14/07/13 21:09, Nick Coghlan wrote:
> |
> | >Slight adjustment to the proposed wording to ensure completely
> undocumented
> | >modules are also considered private:
> |
> | -1 on this adju
On 15Jul2013 09:48, Steven D'Aprano wrote:
| On 14/07/13 21:09, Nick Coghlan wrote:
|
| >Slight adjustment to the proposed wording to ensure completely undocumented
| >modules are also considered private:
|
| -1 on this adjustment. If somebody cannot be bothered writing a one-line doc
string:
|
On 14/07/13 21:09, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure completely undocumented
modules are also considered private:
-1 on this adjustment. If somebody cannot be bothered writing a one-line doc
string:
"This module is private, don't touch."
then they certa
+1 This is already how we've been behaving for years.
On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote:
> On 14 July 2013 18:11, Nick Coghlan wrote:
>
>> Currently, the naming section of PEP 8 doesn't say very much about what a
>> leading underscore *means* in the Python standard library.
On Sun, Jul 14, 2013 at 7:09 AM, Nick Coghlan wrote:
> On 14 July 2013 18:11, Nick Coghlan wrote:
>
>> Currently, the naming section of PEP 8 doesn't say very much about what a
>> leading underscore *means* in the Python standard library.
>>
>> I would like to add a new "Private interfaces" subs
On 14 July 2013 18:11, Nick Coghlan wrote:
> Currently, the naming section of PEP 8 doesn't say very much about what a
> leading underscore *means* in the Python standard library.
>
> I would like to add a new "Private interfaces" subsection under "Naming
> Conventions" to say the following:
>
>
53 matches
Mail list logo
