prepending underscores to private module names

Hi, A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936. I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst that states which modules are public (up for discussion of course). With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in. Before going further I'd like to check that this looks okay to people. What do you think? Cheers, Ralf <https://github.com/rgommers/scipy/tree/underscores>

On Fri, Jun 3, 2011 at 14:57, Ralf Gommers <ralf.gommers@googlemail.com> wrote:
Hi,
A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936.
I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst that states which modules are public (up for discussion of course).
With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in.
Before going further I'd like to check that this looks okay to people. What do you think?
I'm still -1 on it. I think it's unnecessary and potentially disruptive. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco

On Fri, Jun 3, 2011 at 10:05 PM, Robert Kern <robert.kern@gmail.com> wrote:
Hi,
A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936.
I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst
On Fri, Jun 3, 2011 at 14:57, Ralf Gommers <ralf.gommers@googlemail.com> wrote: that
states which modules are public (up for discussion of course).
With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in.
Before going further I'd like to check that this looks okay to people. What do you think?
I'm still -1 on it. I think it's unnecessary and potentially disruptive.
It will indeed be disruptive for those users who imported from private modules, they will get deprecation warnings and would need to update their code. Those same users can run into trouble anyway though unless we treat everything that is now ambiguous as public.
Unnecessary, I disagree. Even among developers it is not clear what the public API is. This is the clearest way to solve it. An alternative would be to just document very clearly what the API is. Just saying "The public API of a package is determined by any number of conventions which may or may not be documented explicitly." doesn't help much. Ralf

Hi, Le vendredi 03 juin 2011 à 21:57 +0200, Ralf Gommers a écrit :
A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936.
I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst that states which modules are public (up for discussion of course).
With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in.
Before going further I'd like to check that this looks okay to people. What do you think?
What is the status of this refactoring work? I think it is an interesting move. -- Denis

On Wed, May 16, 2012 at 9:32 AM, Denis Laxalde <denis@laxalde.org> wrote:
Hi,
Le vendredi 03 juin 2011 à 21:57 +0200, Ralf Gommers a écrit :
A while ago we discussed making a clear distinction between public and private modules by using underscores consistently, see http://thread.gmane.org/gmane.comp.python.scientific.devel/14936.
I've done this for a few modules now, see https://github.com/rgommers/scipy/tree/underscores. Most files could simply be underscored, some other would conflict with extension modules so I also had to append _py to the name. Also I added a file doc/source/api.rst that states which modules are public (up for discussion of course).
With google code search I checked how common it is to import from modules that are supposed to be private, for example "from scipy.optimize.optimize import fmin". It's not very common but does happen, so deprecation warnings should be put in.
Before going further I'd like to check that this looks okay to people. What do you think?
What is the status of this refactoring work? I think it is an interesting move.
I think, dormant for renaming existing modules until or unless it finds more support. recommended for new modules Josef
-- Denis
_______________________________________________ SciPy-Dev mailing list SciPy-Dev@scipy.org http://mail.scipy.org/mailman/listinfo/scipy-dev
participants (4)
-
Denis Laxalde
-
josef.pktd@gmail.com
-
Ralf Gommers
-
Robert Kern