PS: in terms of any conflicting names, I've only encountered
sklearn.hmm.normalize and sklearn.preprocessing.normalize at master...
On Tue, Dec 3, 2013 at 6:56 AM, Joel Nothman <[email protected]> wrote:
> 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
