Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #43116 > unrolled thread

classes and sub classes?

Back to article view | Back to comp.lang.python

Contents

  classes and sub classes? Morten Guldager <morten.guldager@gmail.com> - 2013-04-09 07:50 +0200
    Re: classes and sub classes? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2013-04-09 07:08 +0000
      Re: classes and sub classes? Morten Guldager <morten.guldager@gmail.com> - 2013-04-09 09:38 +0200
      Re: classes and sub classes? Jason Friedman <jsf80238@gmail.com> - 2013-04-14 19:38 -0600
      Re: classes and sub classes? MRAB <python@mrabarnett.plus.com> - 2013-04-15 03:07 +0100
      Re: classes and sub classes? Dennis Lee Bieber <wlfraed@ix.netcom.com> - 2013-04-14 22:35 -0400
      Re: classes and sub classes? Peter Otten <__peter__@web.de> - 2013-04-15 09:21 +0200
        Re: classes and sub classes? Neil Cerutti <neilc@norwich.edu> - 2013-04-15 12:22 +0000

#43116 — classes and sub classes?

[Multipart message — attachments visible in raw view] — view raw

'Aloha Friends!

I'm about to write an API against a huge propitiatory Oracle based network
inventory database. The database have many different concepts stored in
it's tables, can one concept can span over multiple tables.

I would like to write a class for accessing each concept, but only have a
single database connection throughout the whole program.

I imagine some code along these lines, but cant figure out how to declare
the classes that will make it work:

# create a connection to the database and perform come basic login and
initialization
nib = NwInvDb("scott/tiger@ora")
# find a device by ip
interesting_device = nib.Device.lookup_by_ip("192.168.1.1")

In this example I access the concept Device.

Should I make the Device class inherit from NwInvDb? Or should I keep them
separate? Later on I think I will even have to make some sort of
sub-concepts, but lets postpone that game until I really have really seen
the need!


-- 
/Morten %-)

[toc] | [next] | [standalone]

#43126

On Tue, 09 Apr 2013 07:50:11 +0200, Morten Guldager wrote:

> 'Aloha Friends!
> 
> I'm about to write an API against a huge propitiatory Oracle based
> network inventory database. The database have many different concepts
> stored in it's tables, can one concept can span over multiple tables.
> 
> I would like to write a class for accessing each concept, but only have
> a single database connection throughout the whole program.

Sounds reasonable.


> I imagine some code along these lines, but cant figure out how to
> declare the classes that will make it work:
> 
> # create a connection to the database and perform come basic login and
> initialization
> nib = NwInvDb("scott/tiger@ora")
> # find a device by ip
> interesting_device = nib.Device.lookup_by_ip("192.168.1.1")

What's "nib" mean? And "NwInvDb"? I can imagine that the "Db" at the end 
stands for Database, but the rest is just word-salad. I can guess that 
NwInvDb is some sort of database connection. Am I close?


> In this example I access the concept Device.
> 
> Should I make the Device class inherit from NwInvDb? Or should I keep
> them separate? 

Why are you asking us? We don't know what functionality you expect NwInvDb 
and Device to have, what they represent, or whether a Device can be 
meaningfully considered an instance of a NwInvDb, whatever that is.

But given my *guess* that NwInvDb represents a database connection, and 
that Device represents data fetched from that database, then no of course 
you should not inherit. Inheritance implies an "is-a" relationship. If 
you inherit from NwInvDb for Device, that implies:

- interesting_device Is-A database;

- anywhere you can use a NwInvDb database object, you can use 
  a Device object.

And the same would apply to every other concept in the database.

That does not sound like a clean and useful design to me.


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#43131

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 9, 2013 at 9:08 AM, Steven D'Aprano <
steve+comp.lang.python@pearwood.info> wrote:

> On Tue, 09 Apr 2013 07:50:11 +0200, Morten Guldager wrote:
>
> > I'm about to write an API against a huge propitiatory Oracle based
> > network inventory database. The database have many different concepts
> > stored in it's tables, can one concept can span over multiple tables.
> >
> > I would like to write a class for accessing each concept, but only have
> > a single database connection throughout the whole program.
>
> Sounds reasonable.
>
> > I imagine some code along these lines, but cant figure out how to
> > declare the classes that will make it work:
> >
> > # create a connection to the database and perform come basic login and
> > initialization
> > nib = NwInvDb("scott/tiger@ora")
> > # find a device by ip
> > interesting_device = nib.Device.lookup_by_ip("192.168.1.1")
>
> What's "nib" mean? And "NwInvDb"? I can imagine that the "Db" at the end
> stands for Database, but the rest is just word-salad. I can guess that
> NwInvDb is some sort of database connection. Am I close?
>

NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates the
database handle and makes it ready for use.

> In this example I access the concept Device.
> >
> > Should I make the Device class inherit from NwInvDb? Or should I keep
> > them separate?
>
> Why are you asking us? We don't know what functionality you expect NwInvDb
> and Device to have, what they represent, or whether a Device can be
> meaningfully considered an instance of a NwInvDb, whatever that is.
>
> But given my *guess* that NwInvDb represents a database connection, and
> that Device represents data fetched from that database, then no of course
> you should not inherit. Inheritance implies an "is-a" relationship. If
> you inherit from NwInvDb for Device, that implies:
>
> - interesting_device Is-A database;
>

which it is not.

- anywhere you can use a NwInvDb database object, you can use
>   a Device object.
>

which you can not.

And the same would apply to every other concept in the database.
>
> That does not sound like a clean and useful design to me.
>

Good. I think I agree with you so far. Maybe that's why I'm asking, because
I'm not perfectly sure which path to follow to achieve  what I want.

Yes, I need some sort of database connection instance, if it wasn't because
I later on will be needing to access both test and production database I
_could_ have made it global, even if we easily could agree that globals
suck most of the time!

The concept classes like the Device one, will be using the database
instance, I just don't know how to pass db into the concept class. - should
I do it explicit making constructors accept an argument? Like:

nib = NwInvDb("scott/tiger@ora")
dev = NwInvDb.Device(nib)
interesting_device = dev.lookup_by_ip("192.168.1.1")


-- 
/Morten %-)

[toc] | [prev] | [next] | [standalone]

#43591

[Multipart message — attachments visible in raw view] — view raw

> NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates the
database handle and makes it ready for use.

I am interested in opinions.  I for one dislike abbreviations on the theory
that programs are read more than they are written.  I would probably use
this variable name:

network_inventory_db_connection = ...

And yes, I'm aware that "db" is an abbreviation.  I believe I am following
a few Zen principles:

Beautiful is better than ugly.
Explicit is better than implicit.
Readability counts.
Special cases aren't special enough to break the rules, Although
practicality beats purity.

What would others use?

[toc] | [prev] | [next] | [standalone]

#43593

On 15/04/2013 02:38, Jason Friedman wrote:
>  > NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates
> the database handle and makes it ready for use.
>
> I am interested in opinions.  I for one dislike abbreviations on the
> theory that programs are read more than they are written.  I would
> probably use this variable name:
>
> network_inventory_db_connection = ...
>
> And yes, I'm aware that "db" is an abbreviation.  I believe I am
> following a few Zen principles:
>
> Beautiful is better than ugly.
> Explicit is better than implicit.
> Readability counts.
> Special cases aren't special enough to break the rules, Although practicality beats purity.
>
> What would others use?
>
"network" could be abbreviated to "net", "inventory" to "inv" (maybe OK
in this context; in another context it could an abbreviation for
"inverse"), and "connection" to "con" (maybe), giving "net_inv_db_con",
or "net_inv_db_connection".

The trick, of course, is to make it clear, but not annoyingly long.
Python itself has "def", "len", and "lstrip", not "define", "length"
and "left_strip".

[toc] | [prev] | [next] | [standalone]

#43598

On Mon, 15 Apr 2013 03:07:19 +0100, MRAB <python@mrabarnett.plus.com>
declaimed the following in gmane.comp.python.general:

> "network" could be abbreviated to "net", "inventory" to "inv" (maybe OK
> in this context; in another context it could an abbreviation for
> "inverse"), and "connection" to "con" (maybe), giving "net_inv_db_con",
> or "net_inv_db_connection".
>
	Of course, given both "net" and "con", it would be easy to read
"inv" as "inverse" -- if one interprets "net_db_con" to carry data
moving one direction, the inverse connection would be the return data
<G>

	This may be one of those situations wherein the first use of the
name carries an explanatory comment.
-- 
	Wulfraed                 Dennis Lee Bieber         AF6VN
        wlfraed@ix.netcom.com    HTTP://wlfraed.home.netcom.com/

[toc] | [prev] | [next] | [standalone]

#43608

Jason Friedman wrote:

>> NwInvDb = NetworkInventoryDatabase, yes you are correct, it creates the
> database handle and makes it ready for use.
> 
> I am interested in opinions.  I for one dislike abbreviations on the
> theory
> that programs are read more than they are written.  I would probably use
> this variable name:
> 
> network_inventory_db_connection = ...
> 
> And yes, I'm aware that "db" is an abbreviation.  I believe I am following
> a few Zen principles:
> 
> Beautiful is better than ugly.
> Explicit is better than implicit.
> Readability counts.
> Special cases aren't special enough to break the rules, Although
> practicality beats purity.
> 
> What would others use?

inventory_db

The rest should be clear from the context.

[toc] | [prev] | [next] | [standalone]

#43618

On 2013-04-15, Peter Otten <__peter__@web.de> wrote:
> Jason Friedman wrote:
>>> NwInvDb = NetworkInventoryDatabase, yes you are correct, it
>>> creates the database handle and makes it ready for use.
>> 
>> I am interested in opinions.  I for one dislike abbreviations
>> on the theory that programs are read more than they are
>> written.  I would probably use this variable name:
>> 
>> network_inventory_db_connection = ...
>> 
>> And yes, I'm aware that "db" is an abbreviation.  I believe I am following
>> a few Zen principles:
>> 
>> Beautiful is better than ugly.
>> Explicit is better than implicit.
>> Readability counts.
>> Special cases aren't special enough to break the rules, Although
>> practicality beats purity.
>> 
>> What would others use?
>
> inventory_db
>
> The rest should be clear from the context.

How long and descriptive a name is ought to depend on the
wideness of its visibility. n might be acceptable in a short
comprehension, while network_inventory_db_connection might be
apposite for a module-level name.

-- 
Neil Cerutti

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web