On Tue, Jul 16, 2013 at 9:07 PM, Barry Warsaw ba...@python.org 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
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, 16 Jul 2013 17:46:34 -0400, Terry Reedy tjre...@udel.edu wrote:
On 7/16/2013 9:39 AM, R. David Murray wrote:
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano st...@pearwood.info
wrote:
For example, pkgutil includes classes with single-underscore methods,
which I take as
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 rdmur...@bitdance.com wrote:
On Tue, 16 Jul 2013 17:46:34 -0400, Terry Reedy tjre...@udel.edu wrote:
On 7/16/2013 9:39 AM, R. David Murray wrote:
On
On Tue, 2013-07-16 at 15:44 +1000, Nick Coghlan wrote:
On 16 July 2013 13:16, Chris McDonough chr...@plope.com 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*!
On 16 July 2013 16:01, Chris McDonough chr...@plope.com 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
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
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
On 16 July 2013 18:41, Terry Reedy tjre...@udel.edu 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
On 16 July 2013 20:28, Richard Oudkerk shibt...@gmail.com 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
On 16 July 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
On 16 July 2013 20:28, Richard Oudkerk shibt...@gmail.com 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
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
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano st...@pearwood.info 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
On 16 July 2013 23:39, R. David Murray rdmur...@bitdance.com wrote:
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano st...@pearwood.info
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
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 correct code
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. I
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
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 pointing out
On 7/16/2013 9:39 AM, R. David Murray wrote:
On Tue, 16 Jul 2013 23:19:21 +1000, Steven D'Aprano st...@pearwood.info 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
-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,
-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 or
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
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 I
On Mon, 15 Jul 2013 15:51:31 -0400
Barry Warsaw ba...@python.org 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
On 16 Jul 2013 06:13, Barry Warsaw ba...@python.org 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. :)
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 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
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
On 16 July 2013 10:23, Chris McDonough chr...@plope.com 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
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 have
On 16 July 2013 12:20, Chris McDonough chr...@plope.com 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
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 existing
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 lines of
On 16 July 2013 13:02, Chris McDonough chr...@plope.com 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
On Tue, 2013-07-16 at 13:11 +1000, Nick Coghlan wrote:
On 16 July 2013 13:02, Chris McDonough chr...@plope.com 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.
On 16 July 2013 13:16, Chris McDonough chr...@plope.com 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*!
On 14 July 2013 18:11, Nick Coghlan ncogh...@gmail.com 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
+1 This is already how we've been behaving for years.
On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2013 18:11, Nick Coghlan ncogh...@gmail.com wrote:
Currently, the naming section of PEP 8 doesn't say very much about what a
leading underscore *means*
On 15Jul2013 09:48, Steven D'Aprano st...@pearwood.info 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
On Sun, Jul 14, 2013 at 8:01 PM, Cameron Simpson c...@zip.com.au wrote:
On 15Jul2013 09:48, Steven D'Aprano st...@pearwood.info wrote:
| On 14/07/13 21:09, Nick Coghlan wrote:
|
| Slight adjustment to the proposed wording to ensure completely
undocumented
| modules are also considered
On 15 July 2013 09:48, Steven D'Aprano st...@pearwood.info 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
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
On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
On 15 July 2013 09:48, Steven D'Aprano st...@pearwood.info 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 Mon, Jul 15, 2013 at 10:01:17AM +1000, Cameron Simpson wrote:
On 15Jul2013 09:48, Steven D'Aprano st...@pearwood.info 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
On 15 Jul 2013 13:43, Steven D'Aprano st...@pearwood.info wrote:
On Mon, Jul 15, 2013 at 10:30:02AM +1000, Nick Coghlan wrote:
On 15 July 2013 09:48, Steven D'Aprano st...@pearwood.info wrote:
On 14/07/13 21:09, Nick Coghlan wrote:
Slight adjustment to the proposed wording to ensure
On 15 July 2013 02:15, Gregory P. Smith g...@krypto.org wrote:
On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan ncogh...@gmail.com 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
On Mon, Jul 15, 2013 at 6:17 AM, Nick Coghlan ncogh...@gmail.com 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
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 renaming
48 matches
Mail list logo
