I find myself agreeing with basically everything said here.
As for "There should be one-- and preferably only one --obvious way to do
it," Gaël, I feel there are times where the one obvious way to do it should
be conditioned on whether you're building an application or writing a quick
script / interactive play. That's why I think modules with scripting-only
functionality should carry a warning conditioned on the importing module,
even if that warning is mostly ignored.
On Tue, Dec 3, 2013 at 3:15 AM, Robert Kern <[email protected]> wrote:
> On Mon, Dec 2, 2013 at 3:21 PM, Nelle Varoquaux <[email protected]>
> wrote:
> >
> > On 2 December 2013 16:11, Gael Varoquaux <[email protected]>
> wrote:
> > > On Mon, Dec 02, 2013 at 02:50:45PM +0000, Robert Kern wrote:
> > >> > +1. "Import *" is a really really bad habit. And hacked up
> interactive
> > >> > environments (with crazy start up scripts) make it really hard to
> teach,
> > >> > because beginners don't make the difference between a hack and
> Python
> > >> > proper and find that Python is not very systematic in what it does.
> > >
> > >> I know you are addressing a comment from the original proposal, but I
> > >> think these arguments are in *favor* of the proposal, in general.
> "api"
> > >> modules are very useful without "import *". Proper use of the "api"
> > >> module gives all of the convenience of "import *" without any of these
> > >> drawbacks.
> > >
> > > Yes. I am somewhat wondering if it's a good thing to have a
> 'sklearn.api'
> > > or not. I don't really like the flat API, as it means that there is a
> big
> > > namespace where everything is mixed, but aaybe it is a good thing, as
> > > currently it's hard to understand the logic (and sometimes there isn't
> > > one).
> >
> > FYI, matplotlib is trying to move away from the "pyplot" api. It's a mess
> > to maintain, the implementation is a mess, and we (developpers) feel
> > users should learn how to use the Object oriented API which is more
> > flexible.
> > Of course, sklearn is not matplotlib on many many levels.
>
> The pyplot API is also not the same thing as the "api" modules being
> discussed. It is designed significantly differently from matplotlib's OO
> API, and that seems to be the motivating driver for moving away from it,
> not just the flatness of the namespace. The OO API is still superior to the
> pyplot API whether or not you import the OO classes from a flat namespace
> or from their implementation modules.
>
> --
> Robert Kern
>
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics
> Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
> _______________________________________________
> Scikit-learn-general mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
>
>
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Scikit-learn-general mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/scikit-learn-general
