On Thu, Nov 18, 2010 at 4:16 AM, Nick Coghlan wrote:
> On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote:
>> So it comes down again to what we'd like __all__ to mean foremost:
>> public API, or just a list for "import *"?
>
> It's the list for star imports. This intended use case is borne out b
On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord
wrote:
> Along with the others +1
I agree with keeping these distinct and orthogonal as well.
> What is more important is that we have a clearly stated policy for new
> modules and adding names to existing modules so that we don't have to repeat
> t
Am 18.11.2010 13:48, schrieb Michael Foord:
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly
sensible
idea, so even if it wasn't deliberate, I'd say it qua
On 18/11/2010 12:37, Georg Brandl wrote:
Am 18.11.2010 11:47, schrieb Michael Foord:
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that
Am 18.11.2010 11:47, schrieb Michael Foord:
> On 17/11/2010 21:16, Éric Araujo wrote:
>>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>>> fortuitous :)
>> But then, a tool that looks into __all__ to find f
On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl wrote:
> Am 17.11.2010 22:16, schrieb Éric Araujo:
>>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>>> fortuitous :)
>>
>> But then, a tool that looks into __
On 17/11/2010 21:57, Steven D'Aprano wrote:
Nick Coghlan wrote:
The policy we're aiming to clarify here is what we should do when we
come across standard library APIs that land in the grey area, with
there being two appropriate ways to deal with them:
1. Document them and make them officially p
On 17/11/2010 21:22, Georg Brandl wrote:
Am 17.11.2010 22:16, schrieb Éric Araujo:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example wha
On 17/11/2010 21:16, Éric Araujo wrote:
Excluding a builtin name from __all__ sounds like a perfectly sensible
idea, so even if it wasn't deliberate, I'd say it qualifies as
fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d p
On Wed, Nov 17, 2010 at 5:08 PM, Ben Finney wrote:
> Steven D'Aprano writes:
>
>> 3. Treat "documented" and "public" as orthogonal, not synonymous:
>> undocumented public API is not an oxymoron, and neither is documented
>> private API.
>
> +1
>
>> The use of imported modules is possibly an excep
Steven D'Aprano writes:
> 3. Treat "documented" and "public" as orthogonal, not synonymous:
> undocumented public API is not an oxymoron, and neither is documented
> private API.
+1
> The use of imported modules is possibly an exception. If a user is
> writing something like (say) getopt.os.get
Nick Coghlan wrote:
The policy we're aiming to clarify here is what we should do when we
come across standard library APIs that land in the grey area, with
there being two appropriate ways to deal with them:
1. Document them and make them officially public
2. Deprecate the public names and make
Am 17.11.2010 22:39, schrieb Fred Drake:
> On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
>> So it comes down again to what we'd like __all__ to mean foremost:
>> public API, or just a list for "import *"?
>
> It is and has been since its inception *the* list for "import *".
>
> Any additi
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl wrote:
> So it comes down again to what we'd like __all__ to mean foremost:
> public API, or just a list for "import *"?
It is and has been since its inception *the* list for "import *".
Any additional meaning will have to accommodate that usage as w
Am 17.11.2010 22:16, schrieb Éric Araujo:
>> Excluding a builtin name from __all__ sounds like a perfectly sensible
>> idea, so even if it wasn't deliberate, I'd say it qualifies as
>> fortuitous :)
>
> But then, a tool that looks into __all__ to find for example what
> objects to document will mi
> Excluding a builtin name from __all__ sounds like a perfectly sensible
> idea, so even if it wasn't deliberate, I'd say it qualifies as
> fortuitous :)
But then, a tool that looks into __all__ to find for example what
objects to document will miss open. I’d put open in __all__.
Regards
__
On Thu, Nov 18, 2010 at 7:08 AM, Éric Araujo wrote:
>> We may also revisit the rules used by help() to decide what to include
>> on the auto-generated module implementation. Note that currently
>> help() output excludes names not in __all__ is the module has __all__
>> defined. While I advocated
> We may also revisit the rules used by help() to decide what to include
> on the auto-generated module implementation. Note that currently
> help() output excludes names not in __all__ is the module has __all__
> defined. While I advocated this rule earlier in this thread, I now
> Consider the r
On 11/17/2010 10:52 AM, Guido van Rossum wrote:
That's not what I meant. In the case of style guides I think it is
totally appropriate to update the PEP as new rules are developed or
existing ones are clarified (or even changed).
Revising style guides is standard practice. The Chicago Manual o
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
..
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
>
+1
People who bother to read the Library Reference most
On Nov 17, 2010, at 11:38 AM, Guido van Rossum wrote:
> Deprecation doesn't *require* logging a warning or raising an
> exception. You can also add a note to the docs, or if it is
> undocumented, just add a comment to the code. (Though if it is in
> widespread use despite being undocumented, a bett
On Wed, Nov 17, 2010 at 8:23 AM, James Y Knight wrote:
> On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
>> On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
>>> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
(and is a little trickier in the case of module level globals, since t
On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
> On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
>> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
>>> (and is a little trickier in the case of module level globals, since those
>>> can't be deprecated properly)
>>
>> People keep sa
On Tue, Nov 16, 2010 at 1:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight wrote:
> On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
>> (and is a little trickier in the case of module level globals, since those
>> can't be deprecated properly)
>
> People keep saying this, but there have already been examples shown of how t
On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
> (and is a little trickier in the case of module level globals, since those
> can't be deprecated properly)
People keep saying this, but there have already been examples shown of how to
do it. I actually think that python should include a way to
On Wed, Nov 17, 2010 at 9:19 AM, Nick Coghlan wrote:
..
> The standard library documentation should say that the public API is
> what the documentation says it is. Officially, anyone going outside
> those documented APIs should not be surprised if things get removed or
> changed arbitrarily withou
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/17/2010 09:16 AM, Steven D'Aprano wrote:
> Ben Finney wrote:
>
>> I don't know about Guido, but I'd be −1 on suggestions to add more
>> normative information to PEP 7, PEP 8, PEP 257, or any other established
>> style guide PEP. I certainly don'
On Thu, Nov 18, 2010 at 12:25 AM, Michael Foord
wrote:
> We're *also* discussing codifying the naming conventions (or using __all__)
> within the standard library, so it isn't just about deprecations (which is
> why I think PEP 8 rather than PEP 5). This is so that in the future if a
> name looks
On 17/11/2010 14:19, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
The library documentation is *not* the right place for quibbling about
what constitutes a public API when using other means than the library
docume
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake wrote:
> On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
>> The library documentation is *not* the right place for quibbling about
>> what constitutes a public API when using other means than the library
>> documentation to find APIs to call.
>
>
Łukasz Langa wrote:
Mutating PEP8 is bad form. We fight mercilessly over source code
backwards compatibility so I think PEPs should be taken just as
seriously in that regard.
There's no comparison between the two.
If you change your library's API -- not "source code", it doesn't matter
if t
Ben Finney wrote:
I don't know about Guido, but I'd be −1 on suggestions to add more
normative information to PEP 7, PEP 8, PEP 257, or any other established
style guide PEP. I certainly don't want to have to keep going back to
the same documents frequently just to see if the set of recommendati
On 17/11/2010 13:31, Łukasz Langa wrote:
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are
higher. (They run the risk of contradicting each other, if you want
to find a
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan wrote:
> The library documentation is *not* the right place for quibbling about
> what constitutes a public API when using other means than the library
> documentation to find APIs to call.
Quibbling can happen on the mailing list, where it can be ign
Am 17.11.2010 14:11, schrieb Michael Foord:
I don't think those reasons are compelling and the cost of splitting
the Python development style guide into multiple documents are higher.
(They run the risk of contradicting each other, if you want to find a
particular rule you have multiple places
On Wed, Nov 17, 2010 at 11:21 PM, Fred Drake wrote:
> 2010/11/17 Michael Foord :
>> So -1 on splitting Python development style guide into multiple documents.
>
> I don't think that the publicness or API stability promises of the
> standard library are part of a style guide. They're an essential
On 17/11/2010 13:21, Fred Drake wrote:
2010/11/17 Michael Foord:
So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library do
2010/11/17 Michael Foord :
> I don't think those reasons are compelling and the cost of splitting the
> Python development style guide into multiple documents are higher. (They run
> the risk of contradicting each other, if you want to find a particular rule
> you have multiple places to check, the
2010/11/17 Michael Foord :
> So -1 on splitting Python development style guide into multiple documents.
I don't think that the publicness or API stability promises of the
standard library are part of a style guide. They're an essential part
of the library documentation. They aren't a guide for 3
On 17/11/2010 12:37, Łukasz Langa wrote:
Am 17.11.2010 12:57, schrieb Michael Foord:
On 17/11/2010 11:45, Nick Coghlan wrote:
The definition of the public/private policy in all its gory detail
should be in PEP 8 as Guido suggests.
+1
Guido did not said that, though.
I think that is a re
Am 17.11.2010 12:57, schrieb Michael Foord:
On 17/11/2010 11:45, Nick Coghlan wrote:
The definition of the public/private policy in all its gory detail
should be in PEP 8 as Guido suggests.
+1
Guido did not said that, though. I'm with Fred and other people that
agree that PEPs should be mo
On 17/11/2010 11:45, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 2:34 AM, wrote:
I don't think it belongs only in PEP 8 (that's "a style guide" you're
referring to, correct?). It needs to be front and center. This is
information that every single user of the stdlib needs in order to use the
s
On Wed, Nov 17, 2010 at 2:34 AM, wrote:
> I don't think it belongs only in PEP 8 (that's "a style guide" you're
> referring to, correct?). It needs to be front and center. This is
> information that every single user of the stdlib needs in order to use the
> stdlib correctly.
>
> Imagine trying
On Nov 16, 2010, at 4:49 PM, Guido van Rossum wrote:
>> PEP 8 isn't nearly visible enough, either. Whatever the rule is, it needs
>> to be presented with the information itself. If the rule is that things not
>> documented in the library manual have no compatibility guarantees, then all
>> of t
I created http://bugs.python.org/issue10435 to follow up on unicode C
API issues.
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
> Alexander Belopolsky wrote:
>> What this thread has shown is that there is no consensus on what
>> public names are and what rules should be followed when cha
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
..
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequen
On Tue, Nov 16, 2010 at 8:34 AM, wrote:
> On 03:48 pm, gu...@python.org wrote:
>>
>> On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
>> wrote:
>>>
>>> What this thread has shown is that there is no consensus on what
>>> public names are and what rules should be followed when changing names
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney wrote:
> I don't know about Guido, but I'd be -1 on suggestions to add more
> normative information to PEP 7, PEP 8, PEP 257, or any other established
> style guide PEP. I certainly don't want to have to keep going back to
> the same documents frequently
exar...@twistedmatrix.com writes:
> On 03:48 pm, gu...@python.org wrote:
> >Hm. Apart from the specific semantics assigned by the language to
> >single and double leading (and trailing) underscores, I still think
> >this belongs in a style guide, not in the library manual.
>
> I don't think it bel
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
> ..
>>> Note that we can have both a macro and a function
>>> version. This is fairly standard practice in Python C-API.
>>
>> Sure, but what for ?
>>
>
> Mostly just for consistency with the other macros:
>
>
On 11/16/2010 10:16 AM, Alexander Belopolsky wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module.
Nor is their any consensus on the use of __all__ in the stdlib, with
o
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg wrote:
..
>> Note that we can have both a macro and a function
>> version. This is fairly standard practice in Python C-API.
>
> Sure, but what for ?
>
Mostly just for consistency with the other macros:
http://docs.python.org/dev/py3k/c-api/unicode
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
> ..
>> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
>> to be available as callable in order to applications or extensions
>> to use it (without recompile).
>>
>
> .. but it *is* a
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
..
> BTW: I'm not really happy about the Py_UNICODE_ prefix for functions
> in unicodeobject.h, but I guess it's too late to change those.
> It would be better to stick to one prefix for Unicode related
> APIs, i.e. "PyUnicode_".
I don't have
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg wrote:
..
> Now, we can't use a macro for [PyUnicode_GetMax()], since the information has
> to be available as callable in order to applications or extensions
> to use it (without recompile).
>
.. but it *is* a macro resolving to either PyUnicodeUCS2
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
> On Tue, 16 Nov 2010 16:34:54 -
> exar...@twistedmatrix.com wrote:
>>
>> Imagine trying to use a dictionary without knowing about alphabetical
>> ordering.
>
> You mean an ordered dictionary, right?
That one's a sorted dictionary, though.
Georg
Alexander Belopolsky wrote:
> On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
> ..
>> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
>> obscure and given that we already have PyUnicode_Concat(), I think
>> it should be made private and eventually dropped.
>>
>
> What
On 05:21 pm, fuzzy...@voidspace.org.uk wrote:
On 16/11/2010 17:16, 1ukasz Langa wrote:
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about
alphabetical
ordering.
You mean an
On 16/11/2010 17:16, Łukasz Langa wrote:
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about alphabetical
ordering.
You mean an ordered dictionary, right?
He meant the ones w
Am 16.11.2010 18:06, schrieb Antoine Pitrou:
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
Imagine trying to use a dictionary without knowing about alphabetical
ordering.
You mean an ordered dictionary, right?
He meant the ones with actual paper pages.
__
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg wrote:
..
> One API I'm not sure about is PyUnicode_AppendAndDel(). It's somewhat
> obscure and given that we already have PyUnicode_Concat(), I think
> it should be made private and eventually dropped.
>
What about PyUnicode_GetMax()? Isn't that s
On Tue, 16 Nov 2010 16:34:54 -
exar...@twistedmatrix.com wrote:
>
> Imagine trying to use a dictionary without knowing about alphabetical
> ordering.
You mean an ordered dictionary, right?
___
Python-Dev mailing list
Python-Dev@python.org
http:/
On 03:48 pm, gu...@python.org wrote:
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. �I have opened an issue a
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module. I have opened an issue at
> http://bugs.python.org/issue10
Alexander Belopolsky wrote:
> What this thread has shown is that there is no consensus on what
> public names are and what rules should be followed when changing names
> that can be imported from a module. I have opened an issue at
> http://bugs.python.org/issue10434 to address this. My vote is t
On 16/11/2010 15:16, Alexander Belopolsky wrote:
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. I have opened an issue at
http://bugs.python.org/issue10434 to address this
What this thread has shown is that there is no consensus on what
public names are and what rules should be followed when changing names
that can be imported from a module. I have opened an issue at
http://bugs.python.org/issue10434 to address this. My vote is to
adopt the definition spelled out i
+1 on everything.
2010/11/11 Alexander Belopolsky :
> 2010/11/11 Michael Foord :
> ..
>>> You mean runtime automation, e.g. creating __all__ on the fly omitting
>>> underscored names?
>>>
>> Writing code to generate a __all__ that duplicates the default behaviour
>> seems redundant to me.
>>
>
> F
On Fri, 12 Nov 2010 20:38:16 -0800
Guido van Rossum wrote:
>
> Note that __all__ was originally invented to give "from package import
> *" a well-defined meaning when the package included submodules that
> might not have been loaded yet. Using it for other export control
> (while a good idea) cou
On Fri, Nov 12, 2010 at 1:49 AM, Hrvoje Niksic wrote:
> On 11/11/2010 11:24 PM, Greg Ewing wrote:
>>
>> Nick Coghlan wrote:
>>
>>> My personal opinion is that we should be trying to get the standard
>>> library to the point where __all__ definitions are unnecessary - if a
>>> name isn't in __al
Steven D'Aprano wrote:
By the way, did you intend to send this off-list?
No, I didn't realise I hadn't sent it to the list.
If you don't document them, I won't use them, because I won't
know if it's one of these don't-ask-don't-tell pseudo-public
functions or something private that's accidenta
Am 11.11.2010 23:15, schrieb Nick Coghlan:
If we instead adopt the explicit policy that private APIs are:
- imported modules (with the exception of os.path)
- any names starting with a leading underscore
Then we get the 3 API tiers you describe: core public API in __all__,
other public functions
On 11/11/2010 11:24 PM, Greg Ewing wrote:
Nick Coghlan wrote:
My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __
Nick Coghlan wrote:
My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant)
On Fri, Nov 12, 2010 at 4:16 AM, Steven D'Aprano wrote:
> Another couple of objections to getting rid of __all__:
>
> If you're proxying modules or built-ins, you may not be able to use a
> _private name, but you may not want import * to pick up your proxies.
>
> I find it annoying to see this:
>
On 11/10/2010 11:58 AM, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/2010 11:12 PM, Stephen J. Turnbull wrote:
Nick Coghlan writes:
> > Module writers who compound the error by expecting to be imported
> > this way, thereby bogarting the global namespace fo
On Thu, 11 Nov 2010 13:40:36 -0500
Alexander Belopolsky wrote:
> On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
> wrote:
> ..
> >> I don't understand why everyone seem to have accepted Michael's
> >> premise that "we don't have a clearly stated policy for what defines
> >> the public API of stand
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
wrote:
..
>> I don't understand why everyone seem to have accepted Michael's
>> premise that "we don't have a clearly stated policy for what defines
>> the public API of standard library modules." We do have such a policy
>> and it is well known (whi
Nick Coghlan wrote:
My personal opinion is that we should be trying to get the standard
library to the point where __all__ definitions are unnecessary - if a
name isn't in __all__, it should start with an underscore (and if that
is true, then the __all__ definition becomes effectively redundant)
2010/11/11 Michael Foord :
..
>> You mean runtime automation, e.g. creating __all__ on the fly omitting
>> underscored names?
>>
> Writing code to generate a __all__ that duplicates the default behaviour
> seems redundant to me.
>
FWIW, I like having __all__ at the top of the module. It feels lik
On Thu, 11 Nov 2010 15:18:40 +
Michael Foord wrote:
> On 11/11/2010 15:17, Łukasz Langa wrote:
> > Am 11.11.2010 16:05, schrieb Barry Warsaw:
> >> Agreed, though I wouldn't *remove* __all__'s, I would establish a
> >> convention
> >> where they can be generated programmatically. Keeping __al
On 11/11/2010 15:17, Łukasz Langa wrote:
Am 11.11.2010 16:05, schrieb Barry Warsaw:
Agreed, though I wouldn't *remove* __all__'s, I would establish a
convention
where they can be generated programmatically. Keeping __all__ in
sync with
the code is a PITA. It screams for automation.
You mea
Am 11.11.2010 16:05, schrieb Barry Warsaw:
Agreed, though I wouldn't *remove* __all__'s, I would establish a
convention
where they can be generated programmatically. Keeping __all__ in sync with
the code is a PITA. It screams for automation.
You mean runtime automation, e.g. creating __all__
On Nov 12, 2010, at 12:02 AM, Nick Coghlan wrote:
>My personal opinion is that we should be trying to get the standard
>library to the point where __all__ definitions are unnecessary - if a
>name isn't in __all__, it should start with an underscore (and if that
>is true, then the __all__ definitio
On Nov 11, 2010, at 12:41 AM, Alexander Belopolsky wrote:
>Is it OK to add __all__ to such modules that does not include all
>names not starting with an underscore? Is it OK to then remove names
>that clearly were not intended to be public?
I would say in general, yes. It's a good small moderni
Am 08.11.2010 23:07, schrieb Raymond Hettinger:
Some sense needs to be applied to the decision. Google's code search
is great for showing how people actually have used a module in real
world code. If that shows that people are accessing and/or changing an
attribute, it probably needs to remain
On Thu, Nov 11, 2010 at 11:39 PM, Tres Seaver wrote:
> I would argue that the narrative documentation for the module is
> normative for defining "public API", trumping even a pre-existing
> '__all__'. Given that all non-private stdlib modules have such docs,
> nobody should be relying on '__all__
On 11/11/2010 13:51, Alexander Belopolsky wrote:
On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake wrote:
..
Since trace is documented and rx_blank isn't covered, I think it's
pretty clear it was never intended as API. I'd be fine with changing
the visibility of rx_blank, and see no need to change i
On 11/11/2010 13:39, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2010 08:23 AM, Alexander Belopolsky wrote:
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
wrote:
..
Is it OK to add __all__ to such modules that does not include all
names not starting with an unde
On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake wrote:
..
> Since trace is documented and rx_blank isn't covered, I think it's
> pretty clear it was never intended as API. I'd be fine with changing
> the visibility of rx_blank, and see no need to change its name.
While I obviously agree with your co
On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky
wrote:
> I don't dispute that these are *the* rules, but my question was
> whether it is ok to break them in specific cases such as
> trace.rx_blank. If not, how can we deprecate trace.rx_blank which is
> a regex constant?
Since trace is docu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/11/2010 08:23 AM, Alexander Belopolsky wrote:
> On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
> wrote:
> ..
>>> Is it OK to add __all__ to such modules that does not include all
>>> names not starting with an underscore? Is it OK to then remov
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
wrote:
..
>> Is it OK to add __all__ to such modules that does not include all
>> names not starting with an underscore? Is it OK to then remove names
>> that clearly were not intended to be public?
>
> Given the rules I suggested, which are basicall
On Thu, Nov 11, 2010 at 6:51 AM, Michael Foord wrote:
> On 10/11/2010 15:48, R. David Murray wrote:
>
>> I think Tres was referring to certain packages (which shall remain
>> nameless since I don't feel like googling to find one) whose
>> documentation recommends the 'from import *' methodology.
On 11/11/2010 05:41, Alexander Belopolsky wrote:
On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam wrote:
..
On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
So it is obvious that we don't have a clearly stated policy for what
defines the public API of standard library modules.
How about making this
On 10/11/2010 15:48, R. David Murray wrote:
On Wed, 10 Nov 2010 13:12:09 +0900, "Stephen J. Turnbull"
wrote:
Nick Coghlan writes:
> > Module writers who compound the error by expecting to be imported
> > this way, thereby bogarting the global namespace for their own
> > purposes,
On Wed, Nov 10, 2010 at 6:10 PM, Ron Adam wrote:
..
>> On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
>>>
>>> So it is obvious that we don't have a clearly stated policy for what
>>> defines the public API of standard library modules.
>>>
>>> How about making this explicit (either pep 8 or our
On Nov 10, 2010, at 2:21 PM, James Y Knight wrote:
> On the other hand, if you make the primary mechanism to indicate privateness
> be a leading underscore, that's obvious to everyone.
+1.
One of the best features of Python is the ability to make a conscious decision
to break the interface of
On 11/10/2010 01:33 PM, Raymond Hettinger wrote:
On Nov 10, 2010, at 5:47 AM, Michael Foord wrote:
So it is obvious that we don't have a clearly stated policy for what defines
the public API of standard library modules.
How about making this explicit (either pep 8 or our developer docs):
1 - 100 of 155 matches
Mail list logo
