On 08/11/2010 22:07, Raymond Hettinger wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented APIs, or are they private regardless and
On Wed, 10 Nov 2010 13:12:09 +0900, 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
-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 their own
purposes, should be fish-slapped.
Stephen J. Turnbull wrote:
I don't really understand
what Tres is talking about when he writes modules that expect to be
imported this way. The *imported* module shouldn't care, no? This
is an issue for the *importing* code to deal with.
I think he's talking about modules that add a prefix
On Wed, Nov 10, 2010 at 05:47, Michael Foord fuzzy...@voidspace.org.uk wrote:
On 08/11/2010 22:07, Raymond Hettinger wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get
On Nov 10, 2010, at 8:47 AM, Michael Foord wrote:
How about making this explicit (either pep 8 or our developer docs):
If a module or package defines __all__ that authoritatively defines the
public interface. Modules with __all__ SHOULD still respect the naming
conventions (leading
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):
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 Wed, Nov 10, 2010 at 6:10 PM, Ron Adam r...@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 about making this explicit (either pep 8 or our
On Tue, 09 Nov 2010 02:03:23 -
exar...@twistedmatrix.com wrote:
I wonder if there are any actual technical arguments to be made against
something like `deprecatedModuleAttribute`?
For example, does it work well with import hacks such as Mercurial's
demandimport?
Regards
Antoine.
On 11:53 am, solip...@pitrou.net wrote:
On Tue, 09 Nov 2010 02:03:23 -
exar...@twistedmatrix.com wrote:
I wonder if there are any actual technical arguments to be made
against
something like `deprecatedModuleAttribute`?
For example, does it work well with import hacks such as
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2010 06:26 PM, Bobby Impollonia wrote:
This does hurt because anyone who was relying on import * to get a
name which is now omitted from __all__ is going to upgrade and find
their program failing with NameErrors. This is a backwards
On Nov 8, 2010, at 4:50 PM, Guido van Rossum wrote:
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz gl...@twistedmatrix.com
wrote:
This seems like a pretty clear case of practicality beats purity. Not
only has nobody complained about deprecatedModuleAttribute, but there are
tons of
On Tue, Nov 09, 2010 at 01:49:01PM -0500, Tres Seaver wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/08/2010 06:26 PM, Bobby Impollonia wrote:
This does hurt because anyone who was relying on import * to get a
name which is now omitted from __all__ is going to upgrade and
On Wed, Nov 10, 2010 at 4:49 AM, Tres Seaver tsea...@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. It impairs
readability and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/09/2010 03:48 PM, Toshio Kuratomi wrote:
I think there's a valid case for bogarting the namespace in this instance,
but let me know if there's a better way to do it::
# Method to use system libraries if available, otherwise use a bundled
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 fish-slap all of python-dev then - we use precisely
this technique to support
Was: [issue2001] Pydoc interactive browsing enhancement
[snip...]
This suggests that trace.find_strings() should probably be preserved
or properly deprecated. If this is the case, should we fix bugs in
it? Note that it currently has a bug because it ignores the coding
cookie when opening
Was: [issue2001] Pydoc interactive browsing enhancement
[snip...]
This suggests that trace.find_strings() should probably be preserved
or properly deprecated. If this is the case, should we fix bugs in
it? Note that it currently has a bug because it ignores the coding
cookie when opening
On 11/8/2010 12:20 PM, Alexander Belopolsky wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlanrep...@bugs.python.org wrote:
..
I'd actually started typing out the command to commit this before it finally
clicked that the patch changes
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
..
If you deprecate it then you don't *have* to fix bugs in it. If we know it
is used then we can't remove it without deprecation.
What about the maintenance branch?
___
On Mon, Nov 8, 2010 at 12:35 PM, Michael Foord
fuzzy...@voidspace.org.uk wrote:
..
If you deprecate it then you don't *have* to fix bugs in it. If we know it
is used then we can't remove it without deprecation.
What about the maintenance branch?
So you have a bug in the module that can only
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foord fuzzy...@voidspace.org.uk wrote:
..
So you have a bug in the module that can only be fixed in a function you
want to deprecate?
No, I have a bug in a function that I want to deprecate. You said I
don't need to fix it if I add a deprecation warning.
On Mon, Nov 8, 2010 at 1:39 PM, Michael Foordfuzzy...@voidspace.org.uk wrote:
..
So you have a bug in the module that can only be fixed in a function you
want to deprecate?
No, I have a bug in a function that I want to deprecate. You said I
don't need to fix it if I add a deprecation
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlan rep...@bugs.python.org wrote:
..
I'd actually started typing out the command to commit this before
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. �For example, is trace.rx_blank constant part of the trace
module API that needs to be preserved indefinitely? �I don't even know
if it is possible to add a deprecation warning to it,
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. For example, is trace.rx_blank constant part of the trace
module API that needs to be preserved indefinitely? I
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. �For example, is trace.rx_blank constant part of the trace
module API that
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM, Nick Coghlanrep...@bugs.python.org wrote:
..
I'd actually started
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without deprecation policy is
workable. For
On Mon, Nov 8, 2010 at 13:36, Ron Adam r...@ronadam.com wrote:
On 11/08/2010 01:58 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 09:20, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
Was: [issue2001] Pydoc interactive browsing enhancement
On Sun, Nov 7, 2010 at 9:17 AM,
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented APIs, or are they private regardless and thus we can
change them at our whim?
To
Ron Adam wrote:
My understanding is that anything with an actual docstring is part of
the public API.
I frequently add docstrings to _private functions. Just because it is
private doesn't mean I don't want documentation for it, and it is very
handy for running doctests.
Yes, I test my
On 09:57 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, �exar...@twistedmatrix.com wrote:
On 07:58 pm, br...@python.org wrote:
I don't think a strict don't remove without
On 11/8/2010 4:36 PM, Ron Adam wrote:
My understanding is that anything with an actual docstring is part of
the public API. Any thing with a leading underscore is private.
When the trace module was written, the rule seems to have been more
like: docs (but no docstrings) for public API,
On 11/8/2010 2:58 PM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented APIs, or are they private regardless and thus we can
change them at our whim?
How about in
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't have a leading underscore: they get treated just the same
as the documented
On Nov 8, 2010, at 2:35 PM, exar...@twistedmatrix.com wrote:
On 09:57 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:45, exar...@twistedmatrix.com wrote:
On 09:25 pm, br...@python.org wrote:
On Mon, Nov 8, 2010 at 13:03, exar...@twistedmatrix.com wrote:
On 07:58 pm,
On 11/08/2010 04:01 PM, Brett Cannon wrote:
My understanding is that anything with an actual docstring is part of the
public API. Any thing with a leading underscore is private.
That's a bad rule. Why shouldn't I be able to document something that
is not meant for the public so that fellow
On Mon, Nov 8, 2010 at 3:26 PM, Bobby Impollonia bob...@gmail.com wrote:
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
On Nov 8, 2010, at 11:58 AM, Brett Cannon wrote:
I think we need to, as a group, decide how to handle undocumented APIs
that don't
Bobby Impollonia bob...@gmail.com writes:
On Mon, Nov 8, 2010 at 2:07 PM, Raymond Hettinger
raymond.hettin...@gmail.com wrote:
To start with, it doesn't hurt for a maintainer to add an __all__
entry and to only document the parts of the API we think need to be
exposed. That way, we can
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the interpreter via ‘help()’, and
because it's automatically available to ‘doctest’,
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz gl...@twistedmatrix.com wrote:
This seems like a pretty clear case of practicality beats purity. Not only
has nobody complained about deprecatedModuleAttribute, but there are tons of
things which show up in sys.modules that aren't modules in
On Mon, Nov 8, 2010 at 16:10, Ron Adam r...@ronadam.com wrote:
On 11/08/2010 04:01 PM, Brett Cannon wrote:
My understanding is that anything with an actual docstring is part of the
public API. Any thing with a leading underscore is private.
That's a bad rule. Why shouldn't I be able to
On Mon, Nov 8, 2010 at 4:46 PM, Ben Finney ben+pyt...@benfinney.id.au wrote:
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the
On Tue, Nov 09, 2010 at 11:46:59AM +1100, Ben Finney wrote:
Ron Adam r...@ronadam.com writes:
def _publicly_documented_private_api():
Not sure why you would want to do this
instead of using comments.
...
Because the docstring is available at the interpreter
On 12:50 am, gu...@python.org wrote:
On Mon, Nov 8, 2010 at 3:55 PM, Glyph Lefkowitz
gl...@twistedmatrix.com wrote:
This seems like a pretty clear case of practicality beats purity.
Not only has nobody complained about deprecatedModuleAttribute, but
there are tons of things which show up in
On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam r...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
IMO, no.
--
R. David Murray www.bitdance.com
On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon br...@python.org wrote:
..
But that doesn't mean we can't go through, fix up our names, and
deprecate the old public names; that's fair game in my book.
+1
See http://bugs.python.org/issue10371
___
On 11/08/2010 07:18 PM, Brett Cannon wrote:
On Mon, Nov 8, 2010 at 16:10, Ron Adamr...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
That is ugly. I already hate doing that for unittest, I'm not about to
champion that for
On Tue, Nov 9, 2010 at 1:28 PM, Alexander Belopolsky
belopol...@users.sourceforge.net wrote:
On Mon, Nov 8, 2010 at 2:58 PM, Brett Cannon br...@python.org wrote:
..
But that doesn't mean we can't go through, fix up our names, and
deprecate the old public names; that's fair game in my book.
On Tue, Nov 9, 2010 at 04:07, R. David Murray rdmur...@bitdance.com wrote:
On Mon, 08 Nov 2010 18:10:17 -0600, Ron Adam r...@ronadam.com wrote:
def _private_api():
#
# Isn't it a good practice to use comments here?
#
...
IMO, no.
FWIW, I agree completely.
101 - 152 of 152 matches
Mail list logo
