You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@libcloud.apache.org by Tomaz Muraus <to...@apache.org> on 2016/07/04 13:26:13 UTC
Re: [dev] lazy entry
I personally don't see any value in that approach over the existing one,
but I won't block it :)
I would see some value if the APIs itself were changing frequently. In that
case you could potentially iterate over all the available APIs with this
proposed approach, but right now this is not really a big deal.
APIs don't change often and when you work with some API and driver you need
to explicitly select it (and need to be aware of the selection).
I guess you could argue that just doing "import libcloud" is a bit more
convenient, but then again what we are really doing is just moving that
logic from import line to the function name and function arguments so it's
not really reducing complexity or anything.
And then again I would argue Python already includes good support for
namespacing things called packages and that's what we use right now (with
the proposed approach we would replace that "Pythonic" thing with a thing
which would better be used in languages which don't have good native
support for namespacing things, imo).
On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <an...@gmail.com>
wrote:
> Hi,
>
> I've just created a PR, #822, proposing a slightly new API for 1.1, it
> is backward compatible but would form the new recommended entry path
> for instantiating drivers.
>
> I took a leaf out of requests book, (import requests; requests.get('
> goole.com'))
>
> Instead of the current
>
> from libcloud.compute.providers import Provider
> from libcloud.compute.providers import get_driver
>
> cls = get_driver(Provider.RACKSPACE)
>
> The new way is
>
> import libcloud
> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE,
> libcloud.DriverType.COMPUTE.RACKSPACE)
>
> OR
>
> import libcloud
> cls = libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE)
>
> Comments please.
>
> https://github.com/apache/libcloud/pull/822
>
> Ant
>
Re: [dev] lazy entry
Posted by Samuel Marks <sa...@gmail.com>.
Hmm, actually in my code I have this line:
self.provider_cls = (lambda driver: driver(
region=self.provider_dict['provider']['region'],
**self.provider_dict['auth']
))(get_driver(getattr(Provider, self.provider_dict['provider']['name'])))
And I also use DRIVERS. So these imports:
from libcloud.compute.providers import get_driver, DRIVERS
from libcloud.compute.types import Provider
Samuel Marks
http://linkedin.com/in/samuelmarks
On Tue, Jul 5, 2016 at 8:26 AM, Anthony Shaw <an...@gmail.com>
wrote:
> This is aimed at people who are new to the package. I feel like I’ve
> consulted the docs 50 times to remember which submodule contains the
> get_driver methods and which contains the Provider enum class. Maybe that’s
> just me, but I find it quite unintuitive.
>
> The change is really a shortcut, aimed at being a tad more obvious for
> people who don’t read documentation.
>
> The other thing you can’t do in the current system is programmatically
> instantiate a driver from each type without having to use __import__
>
> I’m not wedded to this, but it would be good to see what some newer users
> have to say. There might be a better solution to this.
>
>
> On 5/07/2016, 8:09 AM, "Samuel Marks" <sa...@gmail.com> wrote:
>
> Yeah I agree with you Tomaz, no advantage for me either (but no
> complaints!).
>
> In regards to your other line, I already iterate over all available
> providers in my code by importing+transforming a few dictionaries out of
> libcloud...
>
> So this change would at most save a line of Python for me
>
> On Monday, 4 July 2016, Tomaz Muraus <to...@apache.org> wrote:
>
> > And I forgot to say - if there is any other benefit or advantage of this
> > approach over the existing ones which I am missing, please speak up :)
> >
> > On Mon, Jul 4, 2016 at 3:26 PM, Tomaz Muraus <tomaz@apache.org
> > <javascript:;>> wrote:
> >
> > > I personally don't see any value in that approach over the existing
> one,
> > > but I won't block it :)
> > >
> > > I would see some value if the APIs itself were changing frequently. In
> > > that case you could potentially iterate over all the available APIs
> with
> > > this proposed approach, but right now this is not really a big deal.
> > >
> > > APIs don't change often and when you work with some API and driver you
> > > need to explicitly select it (and need to be aware of the selection).
> > >
> > > I guess you could argue that just doing "import libcloud" is a bit more
> > > convenient, but then again what we are really doing is just moving that
> > > logic from import line to the function name and function arguments so
> > it's
> > > not really reducing complexity or anything.
> > >
> > > And then again I would argue Python already includes good support for
> > > namespacing things called packages and that's what we use right now
> (with
> > > the proposed approach we would replace that "Pythonic" thing with a
> thing
> > > which would better be used in languages which don't have good native
> > > support for namespacing things, imo).
> > >
> > > On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <
> anthony.p.shaw@gmail.com
> > <javascript:;>>
> > > wrote:
> > >
> > >> Hi,
> > >>
> > >> I've just created a PR, #822, proposing a slightly new API for 1.1, it
> > >> is backward compatible but would form the new recommended entry path
> > >> for instantiating drivers.
> > >>
> > >> I took a leaf out of requests book, (import requests; requests.get('
> > >> goole.com'))
> > >>
> > >> Instead of the current
> > >>
> > >> from libcloud.compute.providers import Provider
> > >> from libcloud.compute.providers import get_driver
> > >>
> > >> cls = get_driver(Provider.RACKSPACE)
> > >>
> > >> The new way is
> > >>
> > >> import libcloud
> > >> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE,
> > >> libcloud.DriverType.COMPUTE.RACKSPACE)
> > >>
> > >> OR
> > >>
> > >> import libcloud
> > >> cls =
> libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE)
> > >>
> > >> Comments please.
> > >>
> > >> https://github.com/apache/libcloud/pull/822
> > >>
> > >> Ant
> > >>
> > >
> > >
> >
>
>
> --
>
> Samuel Marks
> http://linkedin.com/in/samuelmarks
>
>
>
>
Re: [dev] lazy entry
Posted by Anthony Shaw <an...@gmail.com>.
This is aimed at people who are new to the package. I feel like I’ve consulted the docs 50 times to remember which submodule contains the get_driver methods and which contains the Provider enum class. Maybe that’s just me, but I find it quite unintuitive.
The change is really a shortcut, aimed at being a tad more obvious for people who don’t read documentation.
The other thing you can’t do in the current system is programmatically instantiate a driver from each type without having to use __import__
I’m not wedded to this, but it would be good to see what some newer users have to say. There might be a better solution to this.
On 5/07/2016, 8:09 AM, "Samuel Marks" <sa...@gmail.com> wrote:
Yeah I agree with you Tomaz, no advantage for me either (but no
complaints!).
In regards to your other line, I already iterate over all available
providers in my code by importing+transforming a few dictionaries out of
libcloud...
So this change would at most save a line of Python for me
On Monday, 4 July 2016, Tomaz Muraus <to...@apache.org> wrote:
> And I forgot to say - if there is any other benefit or advantage of this
> approach over the existing ones which I am missing, please speak up :)
>
> On Mon, Jul 4, 2016 at 3:26 PM, Tomaz Muraus <tomaz@apache.org
> <javascript:;>> wrote:
>
> > I personally don't see any value in that approach over the existing one,
> > but I won't block it :)
> >
> > I would see some value if the APIs itself were changing frequently. In
> > that case you could potentially iterate over all the available APIs with
> > this proposed approach, but right now this is not really a big deal.
> >
> > APIs don't change often and when you work with some API and driver you
> > need to explicitly select it (and need to be aware of the selection).
> >
> > I guess you could argue that just doing "import libcloud" is a bit more
> > convenient, but then again what we are really doing is just moving that
> > logic from import line to the function name and function arguments so
> it's
> > not really reducing complexity or anything.
> >
> > And then again I would argue Python already includes good support for
> > namespacing things called packages and that's what we use right now (with
> > the proposed approach we would replace that "Pythonic" thing with a thing
> > which would better be used in languages which don't have good native
> > support for namespacing things, imo).
> >
> > On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <anthony.p.shaw@gmail.com
> <javascript:;>>
> > wrote:
> >
> >> Hi,
> >>
> >> I've just created a PR, #822, proposing a slightly new API for 1.1, it
> >> is backward compatible but would form the new recommended entry path
> >> for instantiating drivers.
> >>
> >> I took a leaf out of requests book, (import requests; requests.get('
> >> goole.com'))
> >>
> >> Instead of the current
> >>
> >> from libcloud.compute.providers import Provider
> >> from libcloud.compute.providers import get_driver
> >>
> >> cls = get_driver(Provider.RACKSPACE)
> >>
> >> The new way is
> >>
> >> import libcloud
> >> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE,
> >> libcloud.DriverType.COMPUTE.RACKSPACE)
> >>
> >> OR
> >>
> >> import libcloud
> >> cls = libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE)
> >>
> >> Comments please.
> >>
> >> https://github.com/apache/libcloud/pull/822
> >>
> >> Ant
> >>
> >
> >
>
--
Samuel Marks
http://linkedin.com/in/samuelmarks
Re: [dev] lazy entry
Posted by Samuel Marks <sa...@gmail.com>.
Yeah I agree with you Tomaz, no advantage for me either (but no
complaints!).
In regards to your other line, I already iterate over all available
providers in my code by importing+transforming a few dictionaries out of
libcloud...
So this change would at most save a line of Python for me
On Monday, 4 July 2016, Tomaz Muraus <to...@apache.org> wrote:
> And I forgot to say - if there is any other benefit or advantage of this
> approach over the existing ones which I am missing, please speak up :)
>
> On Mon, Jul 4, 2016 at 3:26 PM, Tomaz Muraus <tomaz@apache.org
> <javascript:;>> wrote:
>
> > I personally don't see any value in that approach over the existing one,
> > but I won't block it :)
> >
> > I would see some value if the APIs itself were changing frequently. In
> > that case you could potentially iterate over all the available APIs with
> > this proposed approach, but right now this is not really a big deal.
> >
> > APIs don't change often and when you work with some API and driver you
> > need to explicitly select it (and need to be aware of the selection).
> >
> > I guess you could argue that just doing "import libcloud" is a bit more
> > convenient, but then again what we are really doing is just moving that
> > logic from import line to the function name and function arguments so
> it's
> > not really reducing complexity or anything.
> >
> > And then again I would argue Python already includes good support for
> > namespacing things called packages and that's what we use right now (with
> > the proposed approach we would replace that "Pythonic" thing with a thing
> > which would better be used in languages which don't have good native
> > support for namespacing things, imo).
> >
> > On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <anthony.p.shaw@gmail.com
> <javascript:;>>
> > wrote:
> >
> >> Hi,
> >>
> >> I've just created a PR, #822, proposing a slightly new API for 1.1, it
> >> is backward compatible but would form the new recommended entry path
> >> for instantiating drivers.
> >>
> >> I took a leaf out of requests book, (import requests; requests.get('
> >> goole.com'))
> >>
> >> Instead of the current
> >>
> >> from libcloud.compute.providers import Provider
> >> from libcloud.compute.providers import get_driver
> >>
> >> cls = get_driver(Provider.RACKSPACE)
> >>
> >> The new way is
> >>
> >> import libcloud
> >> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE,
> >> libcloud.DriverType.COMPUTE.RACKSPACE)
> >>
> >> OR
> >>
> >> import libcloud
> >> cls = libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE)
> >>
> >> Comments please.
> >>
> >> https://github.com/apache/libcloud/pull/822
> >>
> >> Ant
> >>
> >
> >
>
--
Samuel Marks
http://linkedin.com/in/samuelmarks
Re: [dev] lazy entry
Posted by Tomaz Muraus <to...@apache.org>.
And I forgot to say - if there is any other benefit or advantage of this
approach over the existing ones which I am missing, please speak up :)
On Mon, Jul 4, 2016 at 3:26 PM, Tomaz Muraus <to...@apache.org> wrote:
> I personally don't see any value in that approach over the existing one,
> but I won't block it :)
>
> I would see some value if the APIs itself were changing frequently. In
> that case you could potentially iterate over all the available APIs with
> this proposed approach, but right now this is not really a big deal.
>
> APIs don't change often and when you work with some API and driver you
> need to explicitly select it (and need to be aware of the selection).
>
> I guess you could argue that just doing "import libcloud" is a bit more
> convenient, but then again what we are really doing is just moving that
> logic from import line to the function name and function arguments so it's
> not really reducing complexity or anything.
>
> And then again I would argue Python already includes good support for
> namespacing things called packages and that's what we use right now (with
> the proposed approach we would replace that "Pythonic" thing with a thing
> which would better be used in languages which don't have good native
> support for namespacing things, imo).
>
> On Sun, Jun 26, 2016 at 1:30 AM, anthony shaw <an...@gmail.com>
> wrote:
>
>> Hi,
>>
>> I've just created a PR, #822, proposing a slightly new API for 1.1, it
>> is backward compatible but would form the new recommended entry path
>> for instantiating drivers.
>>
>> I took a leaf out of requests book, (import requests; requests.get('
>> goole.com'))
>>
>> Instead of the current
>>
>> from libcloud.compute.providers import Provider
>> from libcloud.compute.providers import get_driver
>>
>> cls = get_driver(Provider.RACKSPACE)
>>
>> The new way is
>>
>> import libcloud
>> cls = libcloud.get_driver(libcloud.DriverType.COMPUTE,
>> libcloud.DriverType.COMPUTE.RACKSPACE)
>>
>> OR
>>
>> import libcloud
>> cls = libcloud.get_compute_driver(libcloud.DriverType.COMPUTE.RACKSPACE)
>>
>> Comments please.
>>
>> https://github.com/apache/libcloud/pull/822
>>
>> Ant
>>
>
>