Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!xlned.com!feeder1.xlned.com!newsfeed.xs4all.nl!newsfeed1.news.xs4all.nl!xs4all!newsgate.cistron.nl!newsgate.news.xs4all.nl!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.011 X-Spam-Evidence: '*H*': 0.98; '*S*': 0.00; 'syntax': 0.04; 'json': 0.07; 'problem?': 0.07; 'attributes': 0.09; "django's": 0.09; 'high-profile': 0.09; 'iterate': 0.09; 'python': 0.11; 'def': 0.12; '"key"': 0.16; 'class)': 0.16; 'descriptor.': 0.16; 'inheritance': 0.16; 'metaclass': 0.16; 'metaclasses': 0.16; 'metaclasses.': 0.16; 'objects.': 0.16; 'timestamp': 0.16; 'trying': 0.19; 'user.': 0.19; '8bit%:5': 0.22; 'all:': 0.24; 'certainly': 0.24; 'subject:problem': 0.24; 'people,': 0.24; 'question': 0.24; 'define': 0.26; 'defined': 0.27; 'tim': 0.29; 'topic': 0.29; "doesn't": 0.30; '8bit%:3': 0.30; 'message- id:@mail.gmail.com': 0.30; '(which': 0.31; 'code': 0.31; 'description,': 0.31; 'table,': 0.31; 'class': 0.32; 'interface': 0.32; 'skip:_ 10': 0.34; 'skip:d 20': 0.34; 'subject:the': 0.34; 'could': 0.34; 'problem': 0.35; 'advice': 0.35; 'common': 0.35; 'something': 0.35; 'convert': 0.35; 'objects': 0.35; 'but': 0.35; 'received:google.com': 0.35; '(e.g.,': 0.36; 'representing': 0.36; 'entry': 0.36; 'method': 0.36; 'subject:?': 0.36; 'similar': 0.36; 'should': 0.36; 'detail': 0.37; 'expected': 0.38; 'represent': 0.38; 'skip:& 10': 0.38; 'thank': 0.38; 'problems': 0.38; 'solving': 0.38; 'to:addr:python-list': 0.38; '\xa0\xa0\xa0': 0.39; 'to:addr:python.org': 0.39; 'how': 0.40; 'company': 0.60; 'solve': 0.60; 'most': 0.60; 'situation': 0.65; 'series': 0.66; 'gain': 0.79; 'subject:this': 0.83; 'all!': 0.84; 'bells': 0.84; 'database*': 0.84; 'fields,': 0.84; 'ultimate': 0.93; 'tags,': 0.95 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=x53BawrjJw+SudJrc9f4AiZRAhkIuOhr801E/FqO2L4=; b=tgoluwqvG7+nmYLVEctU6KkQfSvXk2KbCS10xOdflqPZglk//qqGBG5O4ziJaFdJ8P t5tbxeT8/tYVjJWuj1ml4rlubNdcC1vWfidXh1+k+2pSUX5XIoAx3ZG6KUKcgtX5ZtIV 9m+yPwfbPh7YYSjvmsMownwaa96Hwst28L7khGtcZr5bSq4XekJ9Ub+Z2+7p2JkXoG8m RZrikjdlH050ZuDz8U+udFwYMGAR5aS5bKPu4H4IXG/l8HE7X91ejvRWvkd9xP3x1ExG U4hRMhljoiGrXtjMsxWvLaQQ0Bsq7gRabHSc09XdG7cxuCyhAavpB1mn8PWJmgs+cNKv d0iA== X-Received: by 10.42.228.68 with SMTP id jd4mr495163icb.44.1375904369155; Wed, 07 Aug 2013 12:39:29 -0700 (PDT) MIME-Version: 1.0 From: Matthew Lefavor Date: Wed, 7 Aug 2013 15:38:48 -0400 Subject: Is a Metaclass the appropriate way to solve this problem? To: Python Mailing List Content-Type: multipart/alternative; boundary=001a11c3a3042b243404e360b382 X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 101 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1375904372 news.xs4all.nl 15882 [2001:888:2000:d::a6]:60419 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:52146 --001a11c3a3042b243404e360b382 Content-Type: text/plain; charset=ISO-8859-1 All: Like most people, I find the whole metaclass topic pretty obscure, and I have avoided trying to use one for a while. I am also aware of Tim Peter's famous advice that if you have to ask whether you need a metaclass, then you almost certainly don't. But in this case I know I am solving a problem similar to problems that other high-profile Python modules (e.g., Django's Model class) have solved using metaclasses. My company is using a database whose interface is defined in a series of JSON objects. I am writing some interface code to the database and I am trying to hide the detail of the JSON implementation from the user. I want the user to be able to define a class representing a database entry for any arbitrary table, whose attributes represent database entities, like fields or tags, with syntax something like the following: class DataSet: data_set_id = DatabaseKeyField(int) description = DatabaseField(str) creation_date = DatabaseField(datetime.date) creation_timestamp = DatabaseField(datetime.datetime) def __init__(self, ds_id, description, timestamp): self.data_set_id = ds_id self.description = description self.creation_timestamp = timestamp self.creation_date = timestamp.date I know that to create the DatabaseField objects I should be using a descriptor. But I also want the DataSet to automatically gain methods that will convert it into the expected JSON syntax (e.g., a __specifier__ method that will create a JSON object with only "key" fields, and an __object__ method that will create a JSON object with all the fields and other bells and whistles.) My ultimate question then: How do I go about adding those kinds of methods (which iterate through all the attributes which are Database* descriptors)? I know that I could eschew metaclasses altogether and use a common super-class, but this doesn't feel like the right situation for inheritance to me. Is a metaclass going to be the cleanest and easiest-to-understand way to solve this problem? Thank you, all! -MCL --001a11c3a3042b243404e360b382 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
All:

Like most people, I find the whole= metaclass topic pretty obscure, and I have avoided trying to use one for a= while. I am also aware of Tim Peter's famous advice that if you have t= o ask whether you need a metaclass, then you almost certainly don't. Bu= t in this case I know I am solving a problem similar to problems that other= high-profile Python modules (e.g., Django's Model class) have solved u= sing metaclasses.

My company is using a database whose interface is defin= ed in a series of JSON objects. I am writing some interface code to the dat= abase and I am trying to hide the detail of the JSON implementation from th= e user.

I want the user to be able to define a class representi= ng a database entry for any arbitrary table, whose attributes represent dat= abase entities, like fields or tags, with syntax something like the followi= ng:

class DataSet:
=A0 =A0 data_set_id =3D Databa= seKeyField(int)
=A0 =A0 description =3D DatabaseField(str)
<= div>=A0 =A0 creation_date =3D DatabaseField(datetime.date)
=A0 = =A0 creation_timestamp =3D DatabaseField(datetime.datetime)
=A0 =A0=A0
=A0 =A0 def __init__(self, ds_id, description, ti= mestamp):
=A0 =A0 =A0 =A0 self.data_set_id =3D ds_id
= =A0 =A0 =A0 =A0 self.description =3D description
=A0 =A0 =A0 =A0 = self.creation_timestamp =3D timestamp
=A0 =A0 =A0 =A0 self.creation_date =3D timestamp.date

I know that to create the DatabaseField objects I should be using = a descriptor. But I also want the DataSet to automatically gain methods tha= t will convert it into the expected JSON syntax (e.g., a __specifier__ meth= od that will create a JSON object with only "key" fields, and an = __object__ method that will create a JSON object with all the fields and ot= her bells and whistles.)

My ultimate question then: How do I go about adding tho= se kinds of methods (which iterate through all the attributes which are Dat= abase* descriptors)? I know that I could eschew metaclasses altogether and = use a common super-class, but this doesn't feel like the right situatio= n for inheritance to me. Is a metaclass going to be the cleanest and easies= t-to-understand way to solve this problem?

Thank you, all!

-MCL
--001a11c3a3042b243404e360b382--