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
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
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
On Thu, Nov 18, 2010 at 7:22 AM, Georg Brandl g.bra...@gmx.net 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
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 for example
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
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
On Thu, Nov 18, 2010 at 6:41 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Wed, Nov 17, 2010 at 2:34 AM, exar...@twistedmatrix.com 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
On 17/11/2010 11:45, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 2:34 AM,exar...@twistedmatrix.com 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
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
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
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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.
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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
On 17/11/2010 13:21, Fred Drake wrote:
2010/11/17 Michael Foordfuzzy...@voidspace.org.uk:
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
On Wed, Nov 17, 2010 at 11:21 PM, Fred Drake fdr...@acm.org wrote:
2010/11/17 Michael Foord fuzzy...@voidspace.org.uk:
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
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 8:30 AM, Nick Coghlan ncogh...@gmail.com 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,
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
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
Ł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
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drake fdr...@acm.org wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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
On 17/11/2010 14:19, Nick Coghlan wrote:
On Wed, Nov 17, 2010 at 11:45 PM, Fred Drakefdr...@acm.org wrote:
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlanncogh...@gmail.com wrote:
The library documentation is *not* the right place for quibbling about
what constitutes a public API when using
On Thu, Nov 18, 2010 at 12:25 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
-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't want
On Wed, Nov 17, 2010 at 9:19 AM, Nick Coghlan ncogh...@gmail.com 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
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 7:24 AM, James Y Knight f...@fuhm.net 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
On Tue, Nov 16, 2010 at 1:31 PM, Ben Finney ben+pyt...@benfinney.id.au 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
On Nov 17, 2010, at 10:30 AM, Guido van Rossum wrote:
On Wed, Nov 17, 2010 at 7:24 AM, James Y Knight f...@fuhm.net 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
On Wed, Nov 17, 2010 at 8:23 AM, James Y Knight f...@fuhm.net 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 f...@fuhm.net wrote:
On Nov 17, 2010, at 9:19 AM, Nick Coghlan wrote:
(and is a little trickier in the case of module level
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 better
On Wed, Nov 17, 2010 at 8:30 AM, Nick Coghlan ncogh...@gmail.com 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
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
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
On Thu, Nov 18, 2010 at 7:08 AM, Éric Araujo mer...@netwok.org 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
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
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 miss open.
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl g.bra...@gmx.net 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
Am 17.11.2010 22:39, schrieb Fred Drake:
On Wed, Nov 17, 2010 at 4:22 PM, Georg Brandl g.bra...@gmx.net 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
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
Steven D'Aprano st...@pearwood.info 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)
On Wed, Nov 17, 2010 at 5:08 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Steven D'Aprano st...@pearwood.info 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
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
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
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 to
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On 03:48 pm, gu...@python.org wrote:
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
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
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg m...@egenix.com 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()?
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 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
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
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 10:38 AM, M.-A. Lemburg m...@egenix.com 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.
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
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg m...@egenix.com 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
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg m...@egenix.com 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
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:06 PM, M.-A. Lemburg m...@egenix.com 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
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg m...@egenix.com 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:
Alexander Belopolsky wrote:
On Tue, Nov 16, 2010 at 1:57 PM, M.-A. Lemburg m...@egenix.com 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:
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 belongs
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney ben+pyt...@benfinney.id.au 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
On Tue, Nov 16, 2010 at 8:34 AM, exar...@twistedmatrix.com wrote:
On 03:48 pm, gu...@python.org wrote:
On Tue, Nov 16, 2010 at 7:16 AM, Alexander Belopolsky
alexander.belopol...@gmail.com wrote:
What this thread has shown is that there is no consensus on what
public names are and what
On Tue, Nov 16, 2010 at 4:31 PM, Ben Finney ben+pyt...@benfinney.id.au 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
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 m...@egenix.com 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
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 the
On Fri, 12 Nov 2010 20:38:16 -0800
Guido van Rossum gu...@python.org 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
+1 on everything.
2010/11/11 Alexander Belopolsky alexander.belopol...@gmail.com:
2010/11/11 Michael Foord fuzzy...@voidspace.org.uk:
..
You mean runtime automation, e.g. creating __all__ on the fly omitting
underscored names?
Writing code to generate a __all__ that duplicates the default
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
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
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
On Fri, Nov 12, 2010 at 1:49 AM, Hrvoje Niksic hrvoje.nik...@avl.com 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
On 10/11/2010 15:48, R. David Murray wrote:
On Wed, 10 Nov 2010 13:12:09 +0900, Stephen J. Turnbullstep...@xemacs.org
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
On 11/11/2010 05:41, Alexander Belopolsky wrote:
On Wed, Nov 10, 2010 at 6:10 PM, Ron Adamr...@ronadam.com 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
On Thu, Nov 11, 2010 at 6:51 AM, Michael Foord fuzzy...@voidspace.org.ukwrote:
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 'fromme
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
fuzzy...@voidspace.org.uk 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,
-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
fuzzy...@voidspace.org.uk wrote:
..
Is it OK to add __all__ to such modules that does not include all
names not starting with an underscore? Is it
On Thu, Nov 11, 2010 at 8:23 AM, Alexander Belopolsky
alexander.belopol...@gmail.com 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
On Thu, Nov 11, 2010 at 8:43 AM, Fred Drake fdr...@acm.org 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
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
fuzzy...@voidspace.org.uk wrote:
..
Is it OK to add __all__ to such modules that does not include all
names
On 11/11/2010 13:51, Alexander Belopolsky wrote:
On Thu, Nov 11, 2010 at 8:43 AM, Fred Drakefdr...@acm.org 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
On Thu, Nov 11, 2010 at 11:39 PM, Tres Seaver tsea...@palladion.com 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
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 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
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__ definition
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
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
On Thu, 11 Nov 2010 15:18:40 +
Michael Foord fuzzy...@voidspace.org.uk 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.
2010/11/11 Michael Foord fuzzy...@voidspace.org.uk:
..
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
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
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
fuzzy...@voidspace.org.uk 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
On Thu, 11 Nov 2010 13:40:36 -0500
Alexander Belopolsky alexander.belopol...@gmail.com wrote:
On Thu, Nov 11, 2010 at 7:01 AM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
..
I don't understand why everyone seem to have accepted Michael's
premise that we don't have a clearly stated policy
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 for
On Fri, Nov 12, 2010 at 4:16 AM, Steven D'Aprano st...@pearwood.info 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
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
On Wed, Nov 10, 2010 at 10:23 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
On 09/11/2010 22:09, Nick Coghlan wrote:
The new unittest package in 2.7 and 3.2 also uses it in the module
__init__ to present the old flat namespace despite become a package
under the hood.
Look again. :-)
On 10 November 2010 04:12, Stephen J. Turnbull step...@xemacs.org 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, should be fish-slapped. ;)
Be prepared to
On 11/10/2010 05:12 AM, Stephen J. Turnbull wrote:
But these identifiers will appear at the module level, not global, no?
Otherwise this technique couldn't be used. I don't really understand
what Tres is talking about when he writes modules that expect to be
imported this way. The *imported*
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):
I believe the point of Guido's email was that
On 09/11/2010 22:09, Nick Coghlan wrote:
On Wed, Nov 10, 2010 at 4:49 AM, Tres Seavertsea...@palladion.com wrote:
Outside an interactive prompt, anyone using from foo import * has set
themselves and their users up to lose anyway.
That syntax is the single worst misfeature in all of Python.
1 - 100 of 152 matches
Mail list logo
